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: Mon, 13 Dec 2004 12:28:48 -0800
On Dec 12, 2004, at 2:45 AM, Stéphane LETZ wrote:
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.
Yes, but is the driver sure that when the
AudioHardwareDevicePropertyChanged(...
kAudioDevicePropertyBufferFrameSize) calls returns, applications
listeners have be called?
Since the whole point of calling AudioHardwareDevicePropertyChanged is
to make the HAL to call any registered listeners, yes.
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.
So you mean 4 AudioHardwareDevicePropertyChanged have to be called? OK.
Yes.
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.
I don't understand here: do you mean the thread used by *applications*
when using SetProperty? Can you explain it more?
That's exactly what I mean.
When an app calls AudioDeviceSetProperty() to change the IO buffer size
on an IOAudio device, unless the call is being made from the actual IO
thread, the entire operation happens on the thread on which the
AudioDeviceSetProperty() call was made and completes in it's entirety
before AudioDeviceSetProperty() even returns. If the call is made on
the IO thread, it returns immediately and the HAL defers performing the
operation until after it has finished calling all the IOProcs for the
current cycle.
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.
Yes.... At some point while writting our driver, I was thinking that a
kind of *generic* AudioHarwarePluIn.h API driver (that would
correctly implement the main features of a driver) would be
interesting to develop so that later on all specific drivers would
share a common "semantically" correct base.
Is is something Apple would be interesting to support ? (as an open
source project for example)
Having an SDK for user-land drivers along the same lines as what we
have for AudioUnits is an interesting direction to investigate for the
future.
--
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