Re: Can't have AudioServer properly get the list of available formats
Re: Can't have AudioServer properly get the list of available formats
- Subject: Re: Can't have AudioServer properly get the list of available formats
- From: Jeff Moore <email@hidden>
- Date: Tue, 12 Mar 2013 13:07:24 -0700
On Mar 12, 2013, at 12:58 PM, Eric Gorouben <email@hidden> wrote:
> Sorry again, Jeff, as I said, I sent my initial request too quickly, before I noticed this [1] instead of [2], and adding a format manually worked fine.
Ok. That's good I guess, although if you are adding a new sample rate, you need to be sure that kAudioDevicePropertyAvailableNominalSampleRates covers all the rates available in the format list.
> My problem is to port our previous stream formats listing (that used to be more complicated but worked with the HAL plugin mechanism).
> The first important point is that " physical format list be the same as the virtual format list". That's something I was not sure about.
> What if you have several physical formats (like "line input" for example, that shows 1 virtual format and 3 physical formats)?
That's fine. The physical formats are all that should be listed. The HAL handles deriving the virtual format list from the physical format list on its own (this is reflected by the fact that the HAL doesn't ever ask your plug-in for the virtual format list). That's why the comment is in the SA_Device about the two lists being identical.
> I'll get a listing of the formats my driver sends to the audio server, and if I don't find any oddity, I'll come back to you.
>
> Thanks you!
> Eric
> Le 12 mars 2013 à 20:39, Jeff Moore <email@hidden> a écrit :
>
>> The only rules for the physical format list are that the formats all be legal and that the physical format list be the same as the virtual format list. The HAL doesn't really care what the actual details of the formats are.
>>
>> FWIW, I was able to add a third format to the format lists that SA_Device implements without much trouble. Note that there are some details you might have missed when you tried it. For example, in the implementation of GetPropertyData for kAudioStreamPropertyAvailablePhysicalFormats, you need to make sure that the variable theNumberItemsToFetch is clamped at 3 and not 2. Also, you need to update the implementation of kAudioDevicePropertyAvailableNominalSampleRates to also supply 3 values (44.1k, 48k, 88.2k) rather than just 2 values.
>>
>> At any rate, one thing you haven't mentioned yet is exactly how things are going wrong for apps. For example, what physical formats does HALLab show for the streams on your device compared to what they should be showing?
>>
>> --
>>
>> Jeff Moore
>> Core Audio
>> Apple
>>
>>
>>
>> On Mar 12, 2013, at 12:05 PM, Eric Gorouben <email@hidden> wrote:
>>
>>> Of course, I've hit "send" too quickly for this mail... sorry about that.
>>> However, my question would be: are there specific rules for the stream formats, compared to a HAL plugin?
>>> I can't get my formats to get displayed and I don't find the reason.
>>>
>>> Thanks
>>> Eric
>>> Le 12 mars 2013 à 19:44, Eric Gorouben <email@hidden> a écrit :
>>>
>>>> Hi,
>>>>
>>>> I'm implementing the kAudioStreamPropertyAvailablePhysicalFormats and kAudioStreamPropertyAvailableVirtualFormats properties. For some reason, this doesn't seem to work.
>>>> As an experiment, I modified my source to use the SA_Plugin values (the 2 44.1 & 48k formats). No problem.
>>>> I then modified it to have 3 formats (i.e. change the data size, and add a third format with a 88200 Hz sample rate
>>>> if(theNumberItemsToFetch > 2)
>>>> {
>>>> ((AudioStreamRangedDescription*)outData)[1].mFormat.mSampleRate = 88200.0;
>>>> ((AudioStreamRangedDescription*)outData)[1].mFormat.mFormatID = kAudioFormatLinearPCM;
>>>> ((AudioStreamRangedDescription*)outData)[1].mFormat.mFormatFlags = kAudioFormatFlagIsSignedInteger | kAudioFormatFlagsNativeEndian | kAudioFormatFlagIsPacked;
>>>> ((AudioStreamRangedDescription*)outData)[1].mFormat.mBytesPerPacket = 4;
>>>> ((AudioStreamRangedDescription*)outData)[1].mFormat.mFramesPerPacket = 1;
>>>> ((AudioStreamRangedDescription*)outData)[1].mFormat.mBytesPerFrame = 4;
>>>> ((AudioStreamRangedDescription*)outData)[1].mFormat.mChannelsPerFrame = 2;
>>>> ((AudioStreamRangedDescription*)outData)[1].mFormat.mBitsPerChannel = 16;
>>>> ((AudioStreamRangedDescription*)outData)[1].mSampleRateRange.mMinimum = 88200.0;
>>>> ((AudioStreamRangedDescription*)outData)[1].mSampleRateRange.mMaximum = 88200.0;
>>>> }
>>>>
>>>> ).
>>>> I get completely wrong results and AudioServer seems lost and gives the applications inconsistent values.
>>>> I'm stuck on this problem. What did I miss?
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
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