Re: kAudioDevicePropertyBufferFrameSize notification in a driver
Re: kAudioDevicePropertyBufferFrameSize notification in a driver
- Subject: Re: kAudioDevicePropertyBufferFrameSize notification in a driver
- From: Stéphane Letz <email@hidden>
- Date: Fri, 10 Dec 2004 09:57:42 +0100
>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
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)
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?
[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]
Any idea?
Thanks
Stephane letz _______________________________________________
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