Re: IOProc never called after AudioDeviceStart
Re: IOProc never called after AudioDeviceStart
- Subject: Re: IOProc never called after AudioDeviceStart
- From: Jeff Moore <email@hidden>
- Date: Thu, 30 Oct 2008 11:17:39 -0700
If you are getting a SIGUSR1 signal, it isn't coming from any audio
software I'm aware of. Our stuff doesn't use signals for anything.
The only way to avoid it is to figure out from where the signal is
being raised and then make it stop.
On Oct 30, 2008, at 11:03 AM, Mitch Jones wrote:
On Oct 29, 2008, at 8:06 PM, Jeff Moore wrote:
On Oct 29, 2008, at 6:40 PM, Mitch Jones wrote:
On Oct 27, 2008, at 11:51 AM, Jeff Moore wrote:
If you aren't seeing any errors, and you are 100% positive that
there is no race here, then perhaps there are some other things
at play here.
Does this happen with all audio devices? If not, which devices
does it happen to and which doesn't it happen to?
The audio devices I've tried are Built-In Line Output and Built-in
Output on the Mac Pro and Built-in output on the Macbook Pro.
Neither of which produced sound. These are the only output devices
I have.
OK, but it would be helpful to test with devices other than the
built-in device if you get a chance.
I borrowed a pair of usb headphones and an m-audio mobilepre.
Neither produced any sound. However, I've determined what is causing
the problem.
The CFRunloop in the HALRunLoop thread is signaling usr1 which is
being caught by our handler. Sound returns if I don't set the
SIGUSR1 mask. This isn't always happening, so the questions are:
Under what circumstances does SIGUSR1 get used during audio thread
startup? Since the signal appears to be coming from CFRunLoop I
realize this might not be a CoreAudio issue.
How can we avoid this?
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden