Re: IOProc never called after AudioDeviceStart
Re: IOProc never called after AudioDeviceStart
- Subject: Re: IOProc never called after AudioDeviceStart
- From: Mitch Jones <email@hidden>
- Date: Mon, 27 Oct 2008 11:35:56 -0700
On Oct 27, 2008, at 10:48 AM, Jeff Moore wrote:
Are you checking for errors?
Absolutely. I omitted them for brevity. With the exception of setting
the kAudioDevicePropertyNominalSampleRate property, all of the
functions return kAudioHardwareNoError.
I'm also suspicious of the code that starts and then immediately
stops the IOProc while another thread is starting it. That sounds
like a perfect set-up for a race condition.
Besides, that voodoo of starting and immediately stopping "to deal
with crashes we've seen on MacPros during wake " is unnecessary. If
you have crashes, I'd investigate the reasons why because it makes
no sense to be doing that. There is no need for it and it is
probably setting up a race that is leaving the device stopped.
Unfortunately, I don't know the history of that particular problem.
However, I did disable it and the issue still persists. In this
particular case, the AudioDeviceStart(dev, ioProc) happens much later
than the voodoo bit.
In the current incarnation of the code, AudioDeviceStart is only
called once with the desired ioProc.
In fact, I've changed it so that AudioDeviceStart is called
immediately after AudioDeviceAddIOProc, so they are both being called
from the same thread and no other attempt is made to start the device
and the problem is still there.
On Oct 27, 2008, at 10:24 AM, Mitch Jones wrote:
I've inherited some code that makes use of basic CoreAudio routines
to setup a device and get it started to play sound. This has
generally been working fine.
However, I've got a case where the AudioDeviceIOProc passed to
AudioDeviceStart is never called. I know this because there's no
sound, no logging occurs from my callback, and as a last resort, I
tossed an abort() as the first thing in the callback, and the app
never quits.
Given the nature of the code, I can't post it verbatim, but I can
paraphrase it.
//this all happens on a secondary thread. everything returns noErr
as the result
AudioHardwareGetProperty(kAudioHardwarePropertyDefaultOutputDevice,
&theSize, &devID);
//in this case, this call fails because the requested sampleRate
isn't supported. However, disabling it doesn't change the behavior.
AudioDeviceSetProperty(devID, NULL, 0, false,
kAudioDevicePropertyNominalSampleRate, propSize, sampleRate);
AudioDeviceAddIOProc( devID, ioProc, userData );
//start and stop the device to deal with crashes we've seen on
MacPros during wake
AudioDeviceStart(devID, NULL);
AudioDeviceStop(devID, NULL);
...
//another thread then calls this
AudioDeviceStart(devID, ioProc);
At this point, I see the HAL thread running and that it appears to
be invoking the callback, at least based on its backtrace in thread
viewer, but I never see it enter the callback.
I thought it might be involved with the threads run loops as that's
something that isn't regularly run or even referenced from the
threads in question. That didn't seem to make any difference and in
fact, I created a small test app to see how CoreAudio responds when
being called from multiple threads without explicit run loop
execution and the ioproc was always called.
I've also tried the "throwing darts in the dark" approach by
disabling parts of the code, like AudioDeviceStart/Stop, without
any change.
I'm seeing this problem on both a MacPro and Macbook Pro running
10.5.5. The code is compiled targeted at the 10.4 sdk.
Any thoughts on what might be going wrong here would be really
appreciated.
--
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
--
Mitch Jones
email@hidden
_______________________________________________
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