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: Sat, 02 Dec 2006 11:22:16 +0530
Jeff,
Thank you for looking into this!!
I'm sorry for not being more explicit about the results.
I'm going to paste the exact code, and the results I get in both cases.
Perhaps you can guide me as to where the problem lies in this test
code.
(I've removed the calls to AudioDeviceGetPropertyInfo here for
simplicity), and this extract is from a loop that I run for channel
numbers, forInput is set to NO:
------------
OSStatus retVal;
char channelName[1024];
NSString *pACFString = nil;
propsize = sizeof (channelName);
retVal = AudioDeviceGetProperty(pDevIDs[deviceIndex],
currentChannel+1, forInput,
kAudioDevicePropertyChannelName,
&propsize,
channelName);
printf ("Result of kAudioDevicePropertyChannelName = 0x%x\n",
retVal);
propsize = sizeof (pACFString);
retVal = AudioDeviceGetProperty(pDevIDs[deviceIndex],
currentChannel+1, forInput,
kAudioDevicePropertyChannelNameCFString,
&propsize,
&pACFString);
printf ("Result of kAudioDevicePropertyChannelNameCFString =
0x%x\n", retVal);
------------
And here is the output:
First for the "Built-In Output" device on an iMac(which does
not have channel names exposed):
------------------
Result of
kAudioDevicePropertyChannelName = 0x77686f3f
Result of kAudioDevicePropertyChannelNameCFString = 0x77686f3f
Result of kAudioDevicePropertyChannelName = 0x77686f3f
Result of kAudioDevicePropertyChannelNameCFString = 0x77686f3f
------------------
Next for our device, which does expose channel names:
------------------
Result of
kAudioDevicePropertyChannelName = 0x77686f3f
Result of kAudioDevicePropertyChannelNameCFString = 0x0
Result of kAudioDevicePropertyChannelName = 0x77686f3f
Result of kAudioDevicePropertyChannelNameCFString = 0x0
------------------
Where 0x77686f3f == kAudioHardwareUnknownPropertyError.
An for whether the names are translatable to C-String or not, our driver
is creating the dictionary objects using OSString::withCString, so I'm
assuming it should be translatable.
I agree with you that newer code should be using CFStrings. And with
Cocoa code, that's almost a must, with rest of the environment all using
NSStrings!
But, the question comes up with client applications, which expect both
forms of the property to work.
Once again, Thank you for your help in this matter.
Devendra.
At 04:20 AM 12/2/2006, Jeff Moore wrote:
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
_______________________________________________
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