Re: clarification on RME suggestions ...
Re: clarification on RME suggestions ...
- Subject: Re: clarification on RME suggestions ...
- From: Jeff Moore <email@hidden>
- Date: Fri, 21 Jun 2002 13:03:11 -0700
I think you are missing the point of what Bill was trying to say.
At the HAL level, everything is oriented toward exposing the hardware
as it is at the expense of being easy to program for. The reason why is
that we've found that this is the most efficient way to do it. The idea
is to minimize the time spent in the most critical part of the stack,
the driver's mix/clip operation.
This operation is critical not just because of the obvious reasons, but
also because it happens in the kernel driver's kernel trap where it is
absolutely critical that as little time be spent and as little memory
be touched as possible.
It turns out that at this level it is best if the driver didn't have to
do any extra work like interleaving or de-interleaving streams. These
are tasks that should be done outside of the kernel trap prior to
handing the data to the HAL where there aren't as many restrictions and
the time is less critical.
The end result is better performance for everyone. This is why we chose
to make app writers' lives more difficult by not forcing a uniform
stream layout on every device.
On Friday, June 21, 2002, at 12:29 PM, John Lazzaro wrote:
Bill Stewart writes:
Its an AudioBufferList where each buffer in the list represents
a mono channel. [...]
Thanks for the info ...
Not only do we expect to see drivers appearing in this manner, but we
would
actively encourage driver writers to publish their drivers in a
manner that
best represents the layout of the driver's memory itself.
Let's say you're an application, and your goal is, as the default,
send your audio output to what the user has denoted, on the OS level,
to be the default audio output. Step one is easy: look at
kAudioHardwarePropertyDefaultOutputDevice to find a device. But
after that, there seems to be a pretty big range of possibilities:
[1] Ideally, if a device has multiple logical I/O end-points, it
has exported multiple devices, one of which the user has chosen as
the kAudioHardwarePropertyDefaultOutputDevice. So, the AudioBufferList
either consists of a single interleaved stream, or a set of mono
streams in the standard ordering for stereo or 5.1. An application
can infer which one of these is true on the fly -- if the first
stream is a mono stream, it must be the second case, or the first
case with a mono audio output.
[2] Less ideally, a device has multiple logical I/O end-points, and
arranges them as a set of interleaved streams, or one flat set of
mono streams. The solution here would seem to be to assume the
device has put the current "default audio output" first, and then
do kAudioDevicePropertyDeviceName starting with the first stream,
and use a change of device name as the signal for the end of the
default logical I/O end-points. This algorithm has two assumptions:
the "default audio output" channels comes first, and the
kAudioDevicePropertyDeviceName changes for each logical I/O end-point.
But the only other solution I can see is to keep a database for each
kAudioDevicePropertyDeviceManufacturer/kAudioDevicePropertyDeviceName
pair, with the known current behavior of the device's driver ...
--
Jeff Moore
Core Audio
Apple
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.