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: Tue, 05 Dec 2006 09:57:08 +0530
Jeff,
Thank you for looking into this further. We will make sure that our code
and client app. code use CFString mechanism.
BTW, is this also the reason why "Audio & MIDI Setup" does
not show channel names in the Speaker Config. box?
Thanks.
Devendra.
At 01:28 AM 12/5/2006, Jeff Moore wrote:
Thanks for clarifying and
providing the code. I see the bug in the HAL
now. At any rate, the only work around is going to be to not use the C-
string forms of the property (which are deprecated anyway) and use
the
CFString forms.
On Dec 1, 2006, at 9:52 PM, BlazeAudio Developer wrote:
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.
--
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