aboutsummaryrefslogtreecommitdiff
path: root/pd/portaudio/pa_mac_core/notes.txt
diff options
context:
space:
mode:
Diffstat (limited to 'pd/portaudio/pa_mac_core/notes.txt')
-rw-r--r--pd/portaudio/pa_mac_core/notes.txt145
1 files changed, 0 insertions, 145 deletions
diff --git a/pd/portaudio/pa_mac_core/notes.txt b/pd/portaudio/pa_mac_core/notes.txt
deleted file mode 100644
index ad66f358..00000000
--- a/pd/portaudio/pa_mac_core/notes.txt
+++ /dev/null
@@ -1,145 +0,0 @@
-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.