From c1b10d55375dd8ecdf7b223d1f12541983422764 Mon Sep 17 00:00:00 2001 From: Miller Puckette Date: Sat, 18 Aug 2007 23:32:44 +0000 Subject: Download and adjust sources for new portaudio, portmidi. Add experimental callback scheduling. svn path=/trunk/; revision=8657 --- pd/portaudio/pa_mac_core/notes.txt | 145 ------------------------------------- 1 file changed, 145 deletions(-) delete mode 100644 pd/portaudio/pa_mac_core/notes.txt (limited to 'pd/portaudio/pa_mac_core/notes.txt') 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. -- cgit v1.2.1