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: Sun, 12 Dec 2004 11:45:40 +0100
- Resent-date: Mon, 13 Dec 2004 10:30:19 +0100
- Resent-from: Stéphane Letz <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: CoreAudio API <email@hidden>
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?
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.
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?
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)
[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]
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.
Thanks again.
Best Regards
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