Re: Device Virtual Formats
Re: Device Virtual Formats
- Subject: Re: Device Virtual Formats
- From: Jeff Moore <email@hidden>
- Date: Sat, 09 Jan 2010 12:44:41 -0800
Unless you own hog mode on an AudioDevice, it will only do IO with Float32, linear PCM samples. The reason for this is the need to mix the audio from multiple processes together. Not to mention it is a more convenient format for most applications. Plus, by having this conversion done by the driver as the first/last thing done to the data (depending on whether it is input or output), it ensures that it happens at the most appropriate time.
If you do own hog mode on a device, you can use non-mixable formats like AC-3. You can also access the native sample formats for devices that support it. There aren't a whole lot of devices that support this given the general convenience and usefulness of floating point samples.
That said, using hog mode is very unfriendly to the rest of the system. It also has the great potential to confuse users in a multi-application environment. Consequently, it should only be used when strictly necessary. Accessing non-mixable formats is a good reason though.
However, you also want to use hog mode to prevent changes to the device state that you did not initiate. This won't work. The reason why is that the hardware can still change configuration on it's own. There's no way to prevent this from happening. For example, a device that is slaved to an external clock (e.g. a SPDIF input device) might change sample rate when the external clock changes sample rates. Some devices also have front panel controls that can be used to change the state of the device.
So, it's dangerous to assume that just because you own hog mode that an audio device won't ever change.
On Jan 9, 2010, at 9:31 AM, Stephen F. Booth wrote:
> I'm digging a bit deeper into Core Audio than I have before and I was
> hoping for some clarification on device virtual formats. I'm having
> some trouble wrapping my head around around them. I understand that a
> given piece of audio hardware (actually a particular stream on it) has
> specific formats it will support, and it is the driver's job to
> provide data in that format. I also believe that the driver may not
> receive input data in the same format as the output- and so must
> perform some sort of conversion in this case.
>
> The AudioHardware documentation says:
>
> AudioDevices contain instances of the AudioStream class. An
> AudioStream represents a single buffer of data for transferring across
> the user/kernel boundary. As such, AudioStreams are the gatekeepers of
> format information. Each has it's own format and list of available
> formats. AudioStreams can provide data in any format, including
> encoded formats and non-audio formats. If the format is a linear PCM
> format, the data will always be presented as 32 bit, native endian
> floating point. All conversions to and from the true physical format
> of the hardware is handled by the device's driver.
>
> Does saying that PCM data will always be presented as 32-bit float
> mean that even if I am handing an output AU 16-bit ints that they will
> be converted to 32-bit floats before being handed to the stream and
> subsequently the driver? If this is the case, where does the
> conversion occur?
>
> Asked another way, will an AudioStream ever support a PCM format other
> than 32-bit float? Or would the other formats be formats like AC3,
> DTS, etc?
--
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