RE: IOProc never called after AudioDeviceStart
RE: IOProc never called after AudioDeviceStart
- Subject: RE: IOProc never called after AudioDeviceStart
- From: "Saad Nader" <email@hidden>
- Date: Wed, 29 Oct 2008 13:46:27 -0700
- Thread-topic: IOProc never called after AudioDeviceStart
I have a problem at the AudioConverter callback. It's not showing data
converted after the call to convert in my IOProc.
Thanks,
------------------
Saad Nader
Middlware Engineer
Powered By Gamespy
-----Original Message-----
From: coreaudio-api-bounces+snader=email@hidden
[mailto:coreaudio-api-bounces+snader=email@hidden] On
Behalf Of Jeff Moore
Sent: Monday, October 27, 2008 11:51 AM
To: CoreAudio API
Subject: Re: IOProc never called after AudioDeviceStart
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?
Have you sampled your process to see what all the threads are doing?
You could have something else going on that is interfering with the
HAL's ability to field notifications from the driver. This usually
would show up as the process having an IO thread that is stuck waiting
for a notification or waiting for the device's first time stamp.
On Oct 27, 2008, at 11:35 AM, Mitch Jones wrote:
> 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:
>>
com
>>
>> This email sent to email@hidden
>
> --
> Mitch Jones
> email@hidden
>
>
>
>
--
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:
m
This email sent to 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