Re: Problems implementing kAudioDevicePropertyIOProcStreamUsage property in a user-land CoreAudio device
Re: Problems implementing kAudioDevicePropertyIOProcStreamUsage property in a user-land CoreAudio device
- Subject: Re: Problems implementing kAudioDevicePropertyIOProcStreamUsage property in a user-land CoreAudio device
- From: Jeff Moore <email@hidden>
- Date: Wed, 22 Oct 2008 12:58:36 -0700
On Oct 22, 2008, at 2:22 AM, Stéphane Letz wrote:
Our user-land CoreAudio device implements the
kAudioDevicePropertyIOProcStreamUsage property: it defines it as
"Settable" (implementing the IsPropertySettable method) then
implements the SetPropertyData method for
kAudioDevicePropertyIOProcStreamUsage.
Before we go too far into it, if you're not already using it, you
might want to look at the HP_IOProcList class in the HAL plug-in SDK.
That's where I handle my own implementation of this property.
We have some problems when our device is used by iTunes. Basically
as soon as our device allows more than 2 output channels, iTunes
restrict the use to 2 output channels using the
kAudioDevicePropertyIOProcStreamUsage property (and no input
channels), but then iTunes does not play correctly anymore (no sound
and time does not advance)
That's actually the general behavior of AUHAL. It will turn off any
streams it is not using. This is something we've been recommending to
apps to do for a long time in fact.
1) Our first implementation was to have a channels layout defined as
the *maximum* number of input/output our device could handle; thus
the AudioBufferList layout for input and output channels was
allocated accordingly and given as the parameters for the audio
IOCproc of our device. This does not work as explained.
It is not the case that the number of AudioBuffers in the
AudioBufferList changes because of the how
kAudioDevicePropertyIOProcStreamUsage is specified to you by the
application. Rather, the number of AudioBuffers in the AudioBufferList
is always equal to the number of streams on the device. If any of
those streams are disabled for a given IOProc, then the mData pointer
in the AudioBuffer that corresponds to that stream is supposed to be
set to NULL when calling that IOProc as opposed to just dropping the
AudioBuffer out altogether.
2) We then tried to have a channel layout that *exactly* match what
IOProcStreamUsage the application wants, that is we allocate
AudioBufferList layout for input and output to be exactly what the
kAudioDevicePropertyIOProcStreamUsage property has defined. This
does not work either.
Changing the device layout to match the stream usage is not the right
thing to do. The stream layout is not affected by the stream usage of
a given IOProc.
3) QuickTime Player is less sensitive: it works in 1) and 2) cases
They are a more complex user of AUHAL and probably are more ready to
handle whatever may come up. I'd say that is probably just luck and
doesn't indicate any misbehavior by the client application.
4) It we just desactivate the kAudioDevicePropertyIOProcStreamUsage
property implementation (not Settable" anymore and so on...) then
our device keeps the maximum input and output that have been defined
and iTunes the works correctly again, using the first 2 output
channels of the device
There is something that we don't do correctly in our implementation.
What can be the problem?
I think you may have misinterpreted the semantics of this property.
Are you using HP_IOProcList? If not you may at least want to read
through how it handles the buffers so you have a better idea of what
the behavior is supposed to look like.
--
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