diff options
Diffstat (limited to 'pd/portaudio/pa_mac_core/notes.txt')
| -rw-r--r-- | pd/portaudio/pa_mac_core/notes.txt | 117 |
1 files changed, 114 insertions, 3 deletions
diff --git a/pd/portaudio/pa_mac_core/notes.txt b/pd/portaudio/pa_mac_core/notes.txt index c79b90e6..ad66f358 100644 --- a/pd/portaudio/pa_mac_core/notes.txt +++ b/pd/portaudio/pa_mac_core/notes.txt @@ -1,8 +1,23 @@ -Notes on Core Audio Implementation of PortAudio +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 -Document last updated March 20, 2002 +Last updated March 20, 2002 WHAT WORKS @@ -18,7 +33,7 @@ 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 -BuiltIn audio is typically one CoreAudio device. +Built-In audio is typically one CoreAudio device. Mono doesn't work. @@ -32,3 +47,99 @@ 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. |