145 lines
5.9 KiB
Text
145 lines
5.9 KiB
Text
Notes on status of CoreAudio Implementation of PortAudio
|
|
|
|
Document Last Updated December 9, 2005
|
|
|
|
There are currently two implementations of PortAudio for Mac Core Audio.
|
|
|
|
The original is in pa_mac_core_old.c, and the newer, default implementation
|
|
is in pa_mac_core.c.
|
|
Only pa_mac_core.c is currently developed and supported as it uses apple's
|
|
current core audio technology. To select use the old implementation, replace
|
|
pa_mac_core.c with pa_mac_core_old.c (eg. "cp pa_mac_core_auhal.c
|
|
pa_mac_core.c"), then run configure and make as usual.
|
|
|
|
----------------------------------------
|
|
|
|
Notes on Original implementation:
|
|
|
|
by Phil Burk and Darren Gibbs
|
|
|
|
Last updated March 20, 2002
|
|
|
|
WHAT WORKS
|
|
|
|
Output with very low latency, <10 msec.
|
|
Half duplex input or output.
|
|
Full duplex on the same CoreAudio device.
|
|
The paFLoat32, paInt16, paInt8, paUInt8 sample formats.
|
|
Pa_GetCPULoad()
|
|
Pa_StreamTime()
|
|
|
|
KNOWN BUGS OR LIMITATIONS
|
|
|
|
We do not yet support simultaneous input and output on different
|
|
devices. Note that some CoreAudio devices like the Roland UH30 look
|
|
like one device but are actually two different CoreAudio devices. The
|
|
Built-In audio is typically one CoreAudio device.
|
|
|
|
Mono doesn't work.
|
|
|
|
DEVICE MAPPING
|
|
|
|
CoreAudio devices can support both input and output. But the sample
|
|
rates supported may be different. So we have map one or two PortAudio
|
|
device to each CoreAudio device depending on whether it supports
|
|
input, output or both.
|
|
|
|
When we query devices, we first get a list of CoreAudio devices. Then
|
|
we scan the list and add a PortAudio device for each CoreAudio device
|
|
that supports input. Then we make a scan for output devices.
|
|
|
|
-------------------------------------------
|
|
|
|
Notes on Newer/Default AUHAL implementation:
|
|
|
|
by Bjorn Roche
|
|
|
|
Last Updated December 9, 2005
|
|
|
|
Principle of Operation:
|
|
|
|
This implementation uses AUHAL for audio I/O. To some extent, it also
|
|
operates at the "HAL" Layer, though this behavior can be limited by
|
|
platform specific flags (see pa_mac_core.h for details). The default
|
|
settings should be reasonable: they don't change the SR of the device and
|
|
don't cause interruptions if other devices are using the device.
|
|
|
|
Major Software Elements Used: Apple's HAL AUs provide output SR
|
|
conversion transparently, however, only on output, so this
|
|
implementation uses AudioConverters to convert the sample rate on input.
|
|
A PortAudio ring buffer is used to buffer input when sample rate
|
|
conversion is required or when separate audio units are used for duplex
|
|
IO. Finally, a PortAudio buffer processor is used to convert formats and
|
|
provide additional buffers if needed. Internally, interleaved floating
|
|
point data streams are used exclusively - the audio unit converts from
|
|
the audio hardware's native format to interleaved float PCM and
|
|
PortAudio's Buffer processor is used for conversion to user formats.
|
|
|
|
Simplex Input: Simplex input uses a single callback. If sample rate
|
|
conversion is required, a ring buffer and AudioConverter are used as
|
|
well.
|
|
|
|
Simplex output: Simplex output uses a single callback. No ring buffer or
|
|
audio converter is used because AUHAL does its own output SR conversion.
|
|
|
|
Duplex, one device (no SR conversion): When one device is used, a single
|
|
callback is used. This achieves very low latency.
|
|
|
|
Duplex, separate devices or SR conversion: When SR conversion is
|
|
required, data must be buffered before it is converted and data is not
|
|
always available at the same times on input and output, so SR conversion
|
|
requires the same treatment as separate devices. The input callback
|
|
reads data and puts it in the ring buffer. The output callback reads the
|
|
data off the ring buffer, into an audio converter and finally to the
|
|
buffer processor.
|
|
|
|
Platform Specific Options:
|
|
|
|
By using the flags in pa_mac_core.h, the user may specify several options.
|
|
For example, the user can specify the sample-rate conversion quality, and
|
|
the extent to which PA will attempt to "play nice" and to what extent it
|
|
will interrupt other apps to improve performance. For example, if 44100 Hz
|
|
sample rate is requested but the device is set at 48000 Hz, PA can either
|
|
change the device for optimal playback ("Pro" mode), which may interrupt
|
|
other programs playing back audio, or simple use a sample-rate coversion,
|
|
which allows for friendlier sharing of the device ("Play Nice" mode).
|
|
|
|
|
|
Known issues:
|
|
|
|
- Latency: Latency settings are ignored in most cases. Exceptions are when
|
|
doing I/O between different devices and as a hint for selecting a realtively
|
|
low or relatively high latency in conjunction with
|
|
paHostFramesPerBufferUnspecified. Latency settings are always automatically
|
|
bound to "safe" values, however, so setting extreme values here should not be
|
|
an issue.
|
|
|
|
- Buffer Size: paHostFramesPerBufferUnspecified and specific host buffer sizes
|
|
are supported. paHostFramesPerBufferUnspecified works best in "pro" mode,
|
|
where the buffer size and sample rate of the audio device is most likely
|
|
to match the expected values.
|
|
|
|
- Timing info. It reports on stream time, but I'm probably doing something
|
|
wrong since patest_sine_time often reports negative latency numbers.
|
|
|
|
- xrun detection: The only xrun detection performed is when reading
|
|
and writing the ring buffer. There is probably more that can be done.
|
|
|
|
- abort/stop issues: stopping a stream is always a complete operation,
|
|
but latency should be low enough to make the lack of a separate abort
|
|
unnecessary. Apple clarifies its AudioOutputUnitStop() call here:
|
|
http://lists.apple.com/archives/coreaudio-api/2005/Dec/msg00055.html
|
|
|
|
- blocking interface: Not implemented.
|
|
|
|
- multichannel: It has been tested successfully on multichannel hardware
|
|
from MOTU: traveler and 896HD.
|
|
|
|
- sample rate conversion quality: By default, SR conversion is the maximum
|
|
available. This can be tweaked using flags pa_mac_core.h. Note that the AU
|
|
render quyality property is used to set the sample rat conversion quality
|
|
as "documented" here:
|
|
http://lists.apple.com/archives/coreaudio-api/2004/Jan/msg00141.html
|
|
|
|
- x86: I haven't tested it on an x86 Mac myself, but users have reported
|
|
being able to comiple and run it.
|