Re: HALOutputUnit (Pt 1)
Re: HALOutputUnit (Pt 1)
- Subject: Re: HALOutputUnit (Pt 1)
- From: Jeff Moore <email@hidden>
- Date: Mon, 12 Jan 2004 18:33:23 -0800
Yes this is true. The USB spec doesn't require that the input side of a
device be clocked the same as the output side. They can even be running
at different sample rates and still be adhering to the spec. From the
HAL's point of view, the two sides of the device represent two separate
clock sources. Therefore the HAL publishes them as separate devices
through the API.
On Jan 12, 2004, at 5:54 PM, Robert Grant wrote:
Thanks a lot Bill - that clarifies things tremendously. And I think I
now know why Audio In from the HALOutputUnit was not working for me a
while back - I'm using a USB Audio I/O device and I guess that shows
up as two separate Audio Devices?
Robert.
On Jan 9, 2004, at 7:05 PM, William Stewart wrote:
OK I'll see if I can summarise the main points (This is Part 1 - have
to split the post)
On 08/01/2004, at 6:15 PM, Robert Grant wrote:
What properties need to be set to make it happy? I imagine that once
it's configured it probably behaves in a similar manner to the
DefaultOutputUnit?
The only implementation difference between the HAL and Default units
is
that the default units track the "default" devices. Otherwise they are
identical (except that only the HAL unit type can do input).
So, the essential difference is that the HAL unit must be told which
device to use using the kAudioOutputUnitProperty_CurrentDevice
property.
I think the DefaultOutputUnit does some fancy footwork to convert the
canonical format to the device format - would a HALOutputUnit do this
by default or would we have to connect it to an Converter before
wiring it into a graph for example?
As explained in other mails, yes, the HAL unit contains a converter.
Essentially the main things to understand is this:
Element 0: - output if there is any
Element 1: - input if there is any - input must be explicitly enabled
with the kAudioOutputUnitProperty_EnableIO property
Graphically, you can visualise the signal flow like this:
"Render Callback" side (AU's input side)
Client (Device Input)
| |
0 | 1 |
AUHAUL
Unit
"AudioUnitRender" side (AU's output side)
0 | 1 |
| |
(Device Output) Client
The (Device) is bracketted, because the client never actually directly
interacts with this side of the AU.
So, to provide output to AUHAL, the client registers a render callback
on Input Element 0, and the AUHAL AU registers an I/O Proc with the
selected device and calls the client's render callback in the I/O Proc
Thread of that device.
To receive input, the client enables input on AUHAL, and then as
needed, calls the AUHAL's AudioUnitRender method on element 1
(essentially you're on the output side of the AU here), to get the
currrent input data.
In the case of a device where there is both input and output data (for
eg. Built In audio on most of Apple's machines), and having an AUHAL
unit looking at that device. The I/O Proc runs, calls your Render
Callback to provide data for output. Your Render callback can then
turn
around and call AudioUnitRender (elementID == 1) of the AUHAL unit for
the input data for that I/O cycle.
(A simple AUGraph of connections for simple software play-through for
this device would be an AUGraph of 1 audio unit - the AUHAL unit, with
one connection (from AUHAL output ==1 to the same AUHAL input == 0)
In the case of a device that doesn't have a in and out (for eg, USB)
the client can register a callback with the AUHAL unit
(kAudioOutputUnitProperty_SetInputCallback) - this then will call you
when the AUHAL unit has input data for you. Please note, due to some
bugs in CA-Panther this WASN'T working as shipped - however, with the
QT 6.5 update we fixed those (so this now works for Panther and Jaguar
systems)...
So, that's the basic I/O logic.
Formats.
The AUHAL units will always flatten any of the streams/interleaved
channels of a device into a single de-interleaved stream (on
either/both input and output sides). It uses an AudioConverter to do
this transformation. The AUHAL units will also use channel maps to
determine which channels to present to the user if there is not a
one-to-one correspondance between input and output formats.
For Device Output (AUHAL's Element 0), the device format is always
expressed in the output scope. This will always represents the total
number of channels the device is currently set too. It is always *not*
writable - if the format of the device needs to be changed, the user
will need to set that explicitly on the device. The sample rate of
that
format is the current sample rate of the device.
For Device Input (AUHAL's Element 1), the device format is always
expressed in the input scope and is not writable as described above.
The User can set the format it will either provide (for output) or
desires (for input). Thus, for doing device output, the client sets
the
format on the AUHAL's Input Element == 0. For device input, the client
sets the format on AUHAL's Output Element == 1.
AUHAL determines what kind of AudioConverter is required by comparing
the flattened device format and the client's format. Resetting either
a
device format or a client format will generally be a disruptive event,
requiring a new audio converter to be established.
A client can set *any* format provided the format has a simple
conversion process. Typically, this means that a client can specify
*any* variant of the PCM formats (for eg, a client could have the
AUHAL's converters do both a sample rate conversion and/or a float-int
conversion as desired).
The AUHAL unit bypasses the normal semantic of Initialization
requirements for format changes (we do this because the AUHAL - or its
derived units - have to respond both to external sample rate changes
on
the device, or even the removal of a hot-pluggable device (like a USB
device), but still keep on working).
Bill
-- mailto:email@hidden
tel: +1 408 974 4056
______________________________________________________________________
__
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
______________________________________________________________________
__
__
_______________________________________________
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.
_______________________________________________
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.
--
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.