Re: AudioHardwarePlugIn and kAudioDevicePropertyDataSourceNameForID
Re: AudioHardwarePlugIn and kAudioDevicePropertyDataSourceNameForID
- Subject: Re: AudioHardwarePlugIn and kAudioDevicePropertyDataSourceNameForID
- From: Dirk Musfeldt <email@hidden>
- Date: Mon, 08 Nov 2004 15:02:52 +0100
I changed HALLab's CAAudioHardwareDevice::CopyDataSourceNameForID to use
kAudioDevicePropertyDataSourceNameForID instead of
kAudioDevicePropertyDataSourceNameForIDCFString. It worked fine.
{
char theAnswer[256];
AudioValueTranslation theTranslation = { &inID, sizeof(UInt32),
&theAnswer, sizeof(theAnswer) };
UInt32 theSize = sizeof(AudioValueTranslation);
GetPropertyData(0, inSection, kAudioDevicePropertyDataSourceNameForID,
theSize, &theTranslation);
return CFStringCreateWithCString(kCFAllocatorDefault,
theAnswer,
kCFStringEncodingMacRoman);
}
So what? Is there any chance to work around this code in SoundManager?
> Hmm. I don't see anything obviously wrong with your code. It checks the
> size and then casts the data pointer to an AudioValueTranslation*, much
> the
> same as my code does. But, I'm also looking at the code in the Sound
> Manager's code and if it fails to get a response for the 'scnr'
> property, it falls back to using
> kAudioDevicePropertyDataSourceNameForID. It looks to me like it is
> properly filling out the translation structure properly. It is a
> mystery.
>
> It wouldn't hurt to go into HALLab and adjust that code to call
> kAudioDevicePropertyDataSourceNameForID, just to see what happens when
> it is called with arguments you can verify as being good.
>
> On Nov 5, 2004, at 5:36 AM, Dirk Musfeldt wrote:
>
>> Maybe the other devices are answering the private request for property
>> 'scnr' or 'namr' and mine is not? And thus the code executed is
>> different
>> for my plug-in than for the other inputs?
>>
>>
>>
>>
>>> Yes, it works for other inputs. But I can't see my error:
>>>
>>> OSStatus MyDeviceGetProperty(AudioHardwarePlugInRef inSelf,
>>> AudioDeviceID inDevice,
>>> UInt32 inChannel,
>>> Boolean isInput,
>>> AudioDevicePropertyID inPropertyID,
>>> UInt32* ioPropertyDataSize,
>>> void* outPropertyData)
>>> {
>>> OSStatus err = kAudioHardwareNoError;
>>>
>>> switch (inPropertyID) {
>>> case kAudioDevicePropertyDataSourceNameForID:
>>> {
>>> if (*ioPropertyDataSize < sizeof (AudioValueTranslation)){
>>> err = kAudioHardwareBadPropertySizeError;
>>> }else{
>>> AudioValueTranslation* trl =
>>> (AudioValueTranslation*)outPropertyData;
>>> printf("DeviceGetProperty:
>>> kAudioDevicePropertyDataSourceNameForID: \n ioPropertyDataSize %ld \n
>>> mInputData %p \n mInputDataSize %ld \n mOutputData %p \n
>>> mOutputDataSize
>>> %ld\n",
>>> *ioPropertyDataSize,
>>> trl->mInputData,
>>> trl->mInputDataSize,
>>> trl->mOutputData,
>>> trl->mOutputDataSize);
>>>
>>> if (trl->mInputData
>>> && *(UInt32*)trl->mInputData == kMyInputID)
>>> {
>>> char* data = (char*) trl->mOutputData;
>>> if (data) {
>>> strlcpy(data,m_nameString,trl->mOutputDataSize);
>>>
>>> } else {
>>> printf("DeviceGetProperty : no buffer
>>> %p\n",data);
>>> err = kAudioHardwareIllegalOperationError;
>>> }
>>> trl->mOutputDataSize =
>>> min(strlen(m_nameString
>>> )+1,trl->mOutputDataSize);
>>>
>>> } else if (NULL == trl->mInputData ) {
>>> printf("DeviceGetProperty : no input %p\n",
>>> trl->mInputData);
>>> err = kAudioHardwareIllegalOperationError;
>>>
>>> } else {
>>> printf("DeviceGetProperty : wrong input %ld\n",
>>> *(UInt32*)trl->mInputData);
>>> err = kAudioHardwareUnspecifiedError;
>>> }
>>> *ioPropertyDataSize = sizeof(AudioValueTranslation);
>>> }
>>> break;
>>> }
>>> }
>>>
>>> return err;
>>> }
>>>
>>>
>>> The fun thing is that quite similar code for
>>> kAudioDevicePropertyDataSourceNameForIDCFString works fine when
>>> triggered in
>>> HALLab.
>>>
>>>
>>>
>>>
>>>
>>>> That certainly doesn't look right. There isn't any translation data.
>>>>
>>>> Does it work correctly for the built-in hardware? If it does, it most
>>>> likely means you are accidently munging the translation data
>>>> somewhere
>>>> in the
>>>> dispatching code.
>>>>
>>>> If it doesn't, it likely means the bug is on the
>>>> QuickTime/SoundManager
>>>> side.
>>>>
>>>> On Nov 4, 2004, at 2:39 AM, Dirk Musfeldt wrote:
>>>>
>>>>
>>>>
>>>>> Is it possible that QuickTime or the SoundManager layer is doing
>>>>> this
>>>>> wrong?
>>>>>
>>>>> If I use HackTV with my plug-in and open the Sounbd settings I get
>>>>> this:
>>>>>
>>>>> DeviceGetProperty: kAudioDevicePropertyDataSourceNameForID:
>>>>> ioPropertyDataSize 16
>>>>> mInputData 0x0
>>>>> mInputDataSize 0
>>>>> mOutputData 0x0
>>>>> mOutputDataSize 0
>>>>>
>>>>> But I could see other input names so there must be a way to signal
>>>>> this.
>>>>> What am I doing wrong?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> If the mOutputData field is NULL or the mOutputDataSize field is
>>>>>> 0, it
>>>>>> is an error by the caller of AudioDeviceGetProperty() and you
>>>>>> should
>>>>>> return kAudioHardwareIllegalOperationError.
>>>>>>
>>>>>> If mOutputData is not NULL but mOutputDataSize is smaller than the
>>>>>> string you want to return, you should truncate the string to fit in
>>>>>> the
>>>>>> provided buffer.
>>>>>>
>>>>>> On Nov 3, 2004, at 5:18 AM, Dirk Musfeldt wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I'm doing an AudioHardwarePlugIn and have troubles to get my
>>>>>>> reaction
>>>>>>> on
>>>>>>> kAudioDevicePropertyDataSourceNameForID right.
>>>>>>>
>>>>>>> I get an AudioValueTranslation record and want to copy my C string
>>>>>>> into the
>>>>>>> buffer provided with the mOutputData field.
>>>>>>>
>>>>>>> strcpy((char*)translation->mOutputData,nameString);
>>>>>>>
>>>>>>> But what if mOutputData and mOutputData Size are null? Do I have
>>>>>>> to
>>>>>>> malloc a
>>>>>>> buffer myself?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Dirk
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>> Coreaudio-api mailing list (email@hidden)
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>> 40apple.com
>>>>>>>
>>>>>>> This email sent to email@hidden
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> Dirk
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Coreaudio-api mailing list (email@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> 40apple.com
>>>>>
>>>>> This email sent to email@hidden
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> Mit freundlichen Grüßen
>>>
>>> Dirk Musfeldt
>>> Meilenstein Mac OS Software
>>>
>>> Neue Strasse 5
>>> D-31582 Nienburg
>>> Tel: +49 (0) 5021 91 24 44
>>> Fax: +49 (0) 5021 91 24 45
>>> <http://www.meilenstein.de/>
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Coreaudio-api mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>> 40meilenstein.
>>> de
>>>
>>> This email sent to email@hidden
>>>
>>>
>>
>>
>> Dirk Musfeldt
>>
>>
>> _______________________________________________
>> 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
>>
>
>
>
>
> --
>
> 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:
> de
>
> This email sent to email@hidden
>
Regards
Dirk
_______________________________________________
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