Question about kAudioDevicePropertyStreamFormatMatch in a user space driver
Question about kAudioDevicePropertyStreamFormatMatch in a user space driver
- Subject: Question about kAudioDevicePropertyStreamFormatMatch in a user space driver
- From: Stéphane Letz <email@hidden>
- Date: Tue, 28 Jun 2005 10:26:05 +0200
When implementing the kAudioDevicePropertyStreamFormatMatch
property in our user space driver on Panther, after reading the
kAudioDevicePropertyStreamFormatMatch description in AudioHardware.h :
kAudioDevicePropertyStreamFormatMatch = 'sfmm',
// An AudioStreamBasicDescription is passed in which is
modified
// to describe the closest match to the given format that is
// supported by the device. AudioStreamBasicDescription
fields set
// to 0 should be ignored in the query and the device is
free to
// substitute any value it sees fit. Note that the device
may
// return a result that differs dramatically from the
requested
// format. All matching is at the device's ultimate
discretion.
I was thinking that the driver was supposed to fill the
AudioStreamBasicDescription fields *only* if there were equal to 0,
something like :
if (desc->mSampleRate == 0)
desc->mSampleRate = DricerSampleRate;
if (desc->mFormatID == 0)
desc->mFormatID =
kIOAudioStreamSampleFormatLinearPCM;
......
But this interpretation seems incorrect because we see applications
that behave badly with our driver but correctly with the Built-in
audio driver.
On Tiger the description for kAudioDevicePropertyStreamFormatMatch
property is now :
@constant kAudioDevicePropertyStreamFormatMatch
An AudioStreamBasicDescription is passed in
and the AudioStream will modify
it to describe the best match, in the
AudioDevice's opinion, for the given
format.
(kAudioStreamPropertyAvailableVirtualFormats: The proper and most
robust way
to find a format that the AudioStream can
support is to get the list of
available formats and look through that
rather than using this property.)
Thus there is no more reference t this 0 value for the fields.
By removing the desc->mSampleRate == 0 kind of test in the
implementation, the application that was not working works correctly
now. But is it correct for our driver (that actually only support
*one* format) to just write back its own format in the
AudioStreamBasicDescription structure without any more test?
Thanks
Stephane letz
_______________________________________________
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