RE: Bug in CoreAudio, Channel Names property?
RE: Bug in CoreAudio, Channel Names property?
- Subject: RE: Bug in CoreAudio, Channel Names property?
- From: BlazeAudio Developer <email@hidden>
- Date: Fri, 01 Dec 2006 10:41:07 +0530
Hi Alex,
Thank you for the example about the HAL plugin code paths.
No, I've never implemented an AudioHAL plugin.
However, in this case, we're also the 3rd party - meaning we're also
doing the driver.
First of all, for the example that you have given -
kAudioDevicePropertyDeviceName and
kAudioDevicePropertyDeviceNameCFString
the driver creates a single
entry in the IORegistry (IOAudioDeviceName) - of type OSString (akin to
the CFString). However, the CoreAudio layer automatically uses this same
entry for both the properties - doing the translation as
required.
So, I think it's reasonable to expect that the CoreAudio layers would do
the same for the channel names, as they do for the device names.
Specifically, the driver exposes the channel names by creating/attaching
a dictionary on the IOAudioEngine object(in the IORegistry). The keys to
the dictionary refer to the input/output channel numbers as
"InputChannel%u" and "OutputChannel%u". The
corresponding values are the actual channel names(Provided as OSString
objects).
First of all, I couldn't find any documentation on how the values for the
object of a dictionary can be provided as a C-String, rather than an
OSString? Is it possible?
Also, it seems that some layer of CoreAudio, at some point translates
from the 'name' or 'lnam" to looking for the dictionary in the
IOAudioEngine object. And I feel that it is in this layer where the
problem (or the solution) lies:
a. Either we(driver writers) know what type of object be created to
support
kAudioDevicePropertyChannelName
.
b. Or the part in CoreAudio which handles the property be fixed to use
the existing OSString objects from the dictionary to provide a
C-string(or UTF8). In fact, this is already being done for other
properties such as
kAudioDevicePropertyDeviceName and
kAudioDevicePropertyDeviceNameCFString
.
A request to apple folks on the list: A Driver with a working
example for channel names that can be accessed using the
kAudioDevicePropertyChannelName
would be really helpful. Perhaps by adding some things to
the reflector sample or the phantom audio sample.
Thanks.
Devendra.
At 12:09 AM 11/29/2006, Alex Sheh wrote:
You might
conceptually consider them one "property", but they are
actually 2 different properties. If you've ever implemented an
Audio HALplugin, you'll know that there are 2 code paths that the 3rd
party writes - one that returns a CFString and the other a
C-string. Notice that kAudioDevicePropertyDeviceName and
kAudioDevicePropertyDeviceNameCFString are 2 *distinct*
AudioDevicePropertyIDs ('name', 'lnam'), NOT a single
AudioDevicePropertyID with a separate return type flag. If anything
you would want to contact the 3rd party and see whether they are indeed
missing the C-string implementation, as well as double check your own
code. Note that CFStrings are better for localization so it's not
inconceivable that the C-strings were missed or even purposely
omitted.
http://developer.apple.com/documentation/MusicAudio/Reference/CACoreAudioReference/AudioHardwarePlugIn/Classes/AudioHardwarePlugInInterface/index.html
From:
coreaudio-api-bounces+asheh=email@hidden
[
mailto:coreaudio-api-bounces+asheh=email@hidden]
On Behalf Of BlazeAudio Developer
Sent: Monday, November 27, 2006 9:45 PM
To: email@hidden
Subject: RE: Bug in CoreAudio, Channel Names property?
Hi Alex,
You are right, providing names is optional. I'm not concerned about
drivers that do not implement these properties.
Please read my note carefully.
What I'm talking about is the situation in which the driver *does*
implement the property, yet CoreAudio does not let an application access
it using one of the documented mechanisms.
BTW, the driver does not implement two properties - it's the same
property, which can be accessed in two ways. Either by retrieving pointer
to a CFString object or by retrieving a null terminated string.
Now, In cases where the driver *does* provide the property, CoreAudio
allows retrieving it as a CFString, but not as a null terminated string.
And that's what I consider a bug in CoreAudio.
Thanks.
Devendra.
At 11:47 PM 11/27/2006, Alex Sheh wrote:
Hi Devendra,
3rd party CoreAudio drivers are not required to implement either of the
below properties, and many do not - it's not a CoreAudio bug, rather a
driver deficiency. AFAIK, it is something that you can't rely on
being implemented when you query the driver.
- Alex
From:
coreaudio-api-bounces+asheh=email@hidden [
mailto:coreaudio-api-bounces+asheh=email@hidden]
On Behalf Of BlazeAudio Developer
Sent: Saturday, November 25, 2006 3:02 AM
To: email@hidden
Subject: Bug in CoreAudio, Channel Names property?
Hi,
I have run across a situation which might be a bug in the CoreAudio
(framework?).
This has to do with the audio device property for channel names.
If I try to retrieve the property using
kAudioDevicePropertyChannelName
it will not work.
However, if I use
kAudioDevicePropertyChannelNameCFString, it works
just fine!
Should I file a bug report, or am I missing something here?
Thanks.
Devendra.
_______________________________________________
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