Re: Question about kAudioDevicePropertyStreamFormatMatch in a user space driver
Re: Question about kAudioDevicePropertyStreamFormatMatch in a user space driver
- Subject: Re: Question about kAudioDevicePropertyStreamFormatMatch in a user space driver
- From: Jeff Moore <email@hidden>
- Date: Tue, 28 Jun 2005 11:06:32 -0700
The point of kAudioDevicePropertyStreamFormatMatch was to provide
some kind of loose format discovery mechanism. It never really worked
too well, which is why other, more robust mechanisms have been
provided. The idea was that the app provides a possibly not-fully-
qualified ASBD that described the format they were looking for and
the HAL/driver would return a fully qualified ASBD that was the
closest the device in question can come to the requested format.
In the case of your device that only supports one format, then your
driver should always return that format. It's always the best
possible match.
On Jun 28, 2005, at 1:26 AM, Stéphane Letz wrote:
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
--
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