Re: kAudioDevicePropertyBufferFrameSize notification in a driver
Re: kAudioDevicePropertyBufferFrameSize notification in a driver
- Subject: Re: kAudioDevicePropertyBufferFrameSize notification in a driver
- From: Jeff Moore <email@hidden>
- Date: Fri, 10 Dec 2004 12:26:19 -0800
On Dec 10, 2004, at 12:57 AM, Stéphane Letz wrote:
>Usually, changing the IO buffer size involves reallocating the IO buffers. So, if you aren't careful about when and how >you do the reallocation with respect to any other threads that access the buffers, I'd imagine you are setting yourself >up for lots of crashes when one of those other threads pre-empts the thread doing the reallocation at precisely the wrong >time (which Murphy's Law of Pre-emption says will always happen eventually).
>In the IOAudio support, I have any changes that affect what the IO thread is doing synchronize with the IO thread before >making the change. The sorts of things that this comes up with include changing the IO buffer size, adding/removing >IOProcs, and starting/stopping IOProcs. I'm also very careful to do the right thing when these sorts of changes are made >on the IO thread itself.
Thanks. But still not completely clear for me...
Basically my driver:
- stops IO process
- calls BufferSize
- start IO process
Probably not the most efficient way to do it, but it should work.
The IOAudio support uses the synchronization mechanism I mentioned to do this work in between IO cycles.
And the BufferSize function does the following:
BufferSize(....)
{
<update internal driver state>
AudioHardwareDevicePropertyChanged(fPlugInRef,
fDeviceID,
0,
0,
kAudioDevicePropertyBufferFrameSize);
}
But I still get crash. For the driver point of view, how can the driver be sure that applications have completely handled the kAudioDevicePropertyBufferFrameSize notification *before* it can safely re-start the IO process again? (since the AudioHardwareDevicePropertyChanged call appears "asynchronous" for the driver)
You can assume that they've handled it when their listener returns.
One thing you are missing is that a change to kAudioDevicePropertyBufferFrameSize usually also implies a change to kAudioDevicePropertyBufferSize too. You are also be forgetting to send the notification to both the input and output sides.
What is not clear also is how the kAudioDevicePropertyBufferFrameSize notification has to be handled at the application point of view.
For the application, the kAudioDevicePropertyBufferFrameSize notification is handled in another thread than the IO thread, right? What the application is supposed to do?
It depends on the application. It's been my experience that most apps do whatever work they have to do when their listener proc gets called. Normally, the HAL's IOAudio support will send these notifications from the same thread the SetProperty call was made on, rather than the IO thread. It could be that you are doing something different which is throwing off the apps that are crashing.
Note that this would not be a problem with the app. Your plug-in is expected to emulate the semantics of the rest of the HAL. It's part of the reason writing these plug-ins is so hard.
[By tracing the application calls to the driver, it appears that some of them (like QuickTime player) can "safely" handle a different buffer size (the application actually does not ask the driver for the new buffersize) and other like iTunes ask for the new buffersize.
But both of them still crash after some buffer size changes]
<x-tad-smaller>Some apps will know the buffer size based on the AudioBufferList you pass to them in their IOProc. They just do the math on the mDataByteSize member of the AudioBuffer to get the number of frames. Other apps will ask about it. They are all correct and need to be supported.
-- </x-tad-smaller>
<x-tad-smaller>Jeff Moore</x-tad-smaller>
<x-tad-smaller>Core Audio</x-tad-smaller>
<x-tad-smaller>Apple
</x-tad-smaller>
_______________________________________________
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