Re: Bug in CoreAudio, Channel Names property?
Re: Bug in CoreAudio, Channel Names property?
- Subject: Re: Bug in CoreAudio, Channel Names property?
- From: Jeff Moore <email@hidden>
- Date: Fri, 1 Dec 2006 14:50:51 -0800
First off, I just ran a quick API test, and the code path for
kAudioDevicePropertyChannelName appears to work fine. I can ask for
the property and step through the code in gdb all the way through to
the driver. So, this doesn't seem like a bug in the HAL.
Since you don't bother to specify what you mean when you say: "If I
try to retrieve the property using kAudioDevicePropertyChannelName it
will not work", it's hard to say what is really going on here. It's
very likely that your test code has a problem.
That said, the C-string forms of string-valued properties in the HAL
are deprecated and should not be used where there is a CFString-based
alternative. The reason why is that C-strings don't support the
various text encodings you run into in languages like Japanese. In
fact, depending on what specifically the failure is, it could be that
the channel name string isn't translatable into a C-string. Again,
it's hard to say since you haven't told us what the actual failure is.
IMHO, the best thing to do is to change your code to use the
properties that return CFStrings rather than C-strings.
On Nov 30, 2006, at 9:11 PM, BlazeAudio Developer wrote:
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?
--
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