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: Stéphane Letz <email@hidden>
- Date: Fri, 24 Oct 2008 10:46:11 +0200
Message: 2
Date: Wed, 22 Oct 2008 12:58:36 -0700
From: Jeff Moore <email@hidden>
Subject: Re: Problems implementing
kAudioDevicePropertyIOProcStreamUsage property in a user-land
CoreAudio device
To: CoreAudio API <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
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.
Well I am using the IOProcList in my device and let it handle the
IOProcStreamUsage state but I'm handling my own AudioBufferList for
input and output.
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.
This is exactly what I am doing : set the mData to NULL and even the
mDataByteSize to 0 (because otherwise one of the application I was
testing was crashing..), but this does not work.
I also tried to set the mNumberBuffers field to reflect the *actual*
number of used streams (instead of the max number of streams) but this
does not work also.
Then I tried again to set mData to NULL but NOT SET mDataByteSize to
0 and then it works !! (The thing is that I think setting
mDataByteSize to 0 was necessary for one application I was testing but
unfortunately don't remember exactly which one...)
So now I'm a bit confused: should mData be set to NULL *and*
mDataByteSize to 0 for a disabled stream?
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.
OK.
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