Maintained by Gary P. Scavone, gary@music.mcgill.ca
RtAudio incorporates the concept of audio streams, which represent audio output (playback) and/or input (recording). Available audio devices and their capabilities can be enumerated and then specified when opening a stream. Where applicable, multiple API support can be compiled and a particular API specified when creating an RtAudio instance. See the API Notes section for information specific to each of the supported audio APIs.
The RtAudio API provides both blocking (synchronous) and callback (asynchronous) functionality. Callbacks are typically used in conjunction with graphical user interfaces (GUI). Blocking functionality is often necessary for explicit control of multiple input/output stream synchronization or when audio must be synchronized with other system events.
Support for the JACK low-latency audio server has been added with this version of RtAudio. It is necessary to have the JACK server running before creating an instance of RtAudio.
Several API changes have been made in version 3.0 of RtAudio in an effort to provide more consistent behavior across all supported audio APIs. The most significant of these changes is that multiple stream support from a single RtAudio instance has been discontinued. As a result, stream identifier input arguments are no longer required. Also, the RtAudio::streamWillBlock() function was poorly supported by most APIs and has been deprecated (though the function still exists in those subclasses of RtApi that do allow it to be implemented).
The RtAudio::getDeviceInfo() function was modified to return a globally defined RtAudioDeviceInfo structure. This structure is a simplified version of the previous RTAUDIO_DEVICE structure. In addition, the RTAUDIO_FORMAT structure was renamed RtAudioFormat and defined globally within RtAudio.h. These changes were made for clarity and to better conform with standard C++ programming practices.
The RtError class declaration and definition have been extracted to a separate file (RtError.h). This was done in preparation for a new release of the RtMidi class (planned for Summer 2004).
The first thing that must be done when using RtAudio is to create an instance of the class. The default constructor scans the underlying audio system to verify that at least one device is available. RtAudio often uses C++ exceptions to report errors, necessitating try/catch blocks around most member functions. The following code example demonstrates default object construction and destruction:
#include "RtAudio.h" int main() { RtAudio *audio = 0; // Default RtAudio constructor try { audio = new RtAudio(); } catch (RtError &error) { // Handle the exception here error.printMessage(); } // Clean up delete audio; }
Obviously, this example doesn't demonstrate any of the real functionality of RtAudio. However, all uses of RtAudio must begin with a constructor (either default or overloaded varieties) and must end with class destruction. Further, it is necessary that all class methods that can throw a C++ exception be called within a try/catch block.
// probe.cpp #include <iostream> #include "RtAudio.h" int main() { RtAudio *audio = 0; // Default RtAudio constructor try { audio = new RtAudio(); } catch (RtError &error) { error.printMessage(); exit(EXIT_FAILURE); } // Determine the number of devices available int devices = audio->getDeviceCount(); // Scan through devices for various capabilities RtAudioDeviceInfo info; for (int i=1; i<=devices; i++) { try { info = audio->getDeviceInfo(i); } catch (RtError &error) { error.printMessage(); break; } // Print, for example, the maximum number of output channels for each device std::cout << "device = " << i; std::cout << ": maximum output channels = " << info.outputChannels << "\n"; } // Clean up delete audio; return 0; }
The RtAudioDeviceInfo structure is defined in RtAudio.h and provides a variety of information useful in assessing the capabilities of a device:
typedef struct RtAudioDeviceInfo{ std::string name; // Character string device identifier. bool probed; // true if the device capabilities were successfully probed. int outputChannels; // Maximum output channels supported by device. int inputChannels; // Maximum input channels supported by device. int duplexChannels; // Maximum simultaneous input/output channels supported by device. bool isDefault; // true if this is the default output or input device. std::vector<int> sampleRates; // Supported sample rates. RtAudioFormat nativeFormats; // Bit mask of supported data formats. };
The following data formats are defined and fully supported by RtAudio:
typedef unsigned long RtAudioFormat; static const RtAudioFormat RTAUDIO_SINT8; // Signed 8-bit integer static const RtAudioFormat RTAUDIO_SINT16; // Signed 16-bit integer static const RtAudioFormat RTAUDIO_SINT24; // Signed 24-bit integer (upper 3 bytes of 32-bit signed integer.) static const RtAudioFormat RTAUDIO_SINT32; // Signed 32-bit integer static const RtAudioFormat RTAUDIO_FLOAT32; // 32-bit float normalized between +/- 1.0 static const RtAudioFormat RTAUDIO_FLOAT64; // 64-bit double normalized between +/- 1.0
The nativeFormats member of the RtAudioDeviceInfo structure is a bit mask of the above formats that are natively supported by the device. However, RtAudio will automatically provide format conversion if a particular format is not natively supported. When the probed member of the RtAudioDeviceInfo structure is false, the remaining structure members are undefined and the device is probably unuseable.
While some audio devices may require a minimum channel value greater than one, RtAudio will provide automatic channel number compensation when the number of channels set by the user is less than that required by the device. Channel compensation is NOT possible when the number of channels set by the user is greater than that supported by the device.
It should be noted that the capabilities reported by a device driver or underlying audio API are not always accurate and/or may be dependent on a combination of device settings. For this reason, RtAudio does not typically rely on the queried values when attempting to open a stream.
#include "RtAudio.h" int main() { int channels = 2; int sampleRate = 44100; int bufferSize = 256; // 256 sample frames int nBuffers = 4; // number of internal buffers used by device int device = 0; // 0 indicates the default or first available device RtAudio *audio = 0; // Instantiate RtAudio and open a stream within a try/catch block try { audio = new RtAudio(); } catch (RtError &error) { error.printMessage(); exit(EXIT_FAILURE); } try { audio->openStream(device, channels, 0, 0, RTAUDIO_FLOAT32, sampleRate, &bufferSize, nBuffers); } catch (RtError &error) { error.printMessage(); // Perhaps try other parameters? } // Clean up delete audio; return 0; }
The RtAudio::openStream() method attempts to open a stream with a specified set of parameter values. In this case, we attempt to open a two channel playback stream with the default output device, 32-bit floating point data, a sample rate of 44100 Hz, a frame rate of 256 sample frames per read/write, and 4 internal device buffers. When device = 0, RtAudio first attempts to open the default audio device with the given parameters. If that attempt fails, RtAudio searches through the remaining available devices in an effort to find a device that will meet the given parameters. If all attempts are unsuccessful, an RtError is thrown. When a non-zero device value is specified, an attempt is made to open that device ONLY (device = 1 specifies the first identified device, as reported by RtAudio::getDeviceInfo()).
RtAudio provides four signed integer and two floating point data formats that can be specified using the RtAudioFormat parameter values mentioned earlier. If the opened device does not natively support the given format, RtAudio will automatically perform the necessary data format conversion.
The bufferSize parameter specifies the desired number of sample frames that will be written to and/or read from a device per write/read operation. The nBuffers parameter is used in setting the underlying device buffer parameters. Both the bufferSize and nBuffers parameters can be used to control stream latency though there is no guarantee that the passed values will be those used by a device (the nBuffers parameter is ignored when using the OS X CoreAudio, Linux Jack, and the Windows ASIO APIs). In general, lower values for both parameters will produce less latency but perhaps less robust performance. Both parameters can be specified with values of zero, in which case the smallest allowable values will be used. The bufferSize parameter is passed as a pointer and the actual value used by the stream is set during the device setup procedure. bufferSize values should be a power of two. Optimal and allowable buffer values tend to vary between systems and devices. Check the API Notes section for general guidelines.
As noted earlier, the device capabilities reported by a driver or underlying audio API are not always accurate and/or may be dependent on a combination of device settings. Because of this, RtAudio does not attempt to query a device's capabilities or use previously reported values when opening a device. Instead, RtAudio simply attempts to set the given parameters on a specified device and then checks whether the setup is successful or not.
// playback.cpp #include "RtAudio.h" int main() { int count; int channels = 2; int sampleRate = 44100; int bufferSize = 256; // 256 sample frames int nBuffers = 4; // number of internal buffers used by device float *buffer; int device = 0; // 0 indicates the default or first available device RtAudio *audio = 0; // Open a stream during RtAudio instantiation try { audio = new RtAudio(device, channels, 0, 0, RTAUDIO_FLOAT32, sampleRate, &bufferSize, nBuffers); } catch (RtError &error) { error.printMessage(); exit(EXIT_FAILURE); } try { // Get a pointer to the stream buffer buffer = (float *) audio->getStreamBuffer(); // Start the stream audio->startStream(); } catch (RtError &error) { error.printMessage(); goto cleanup; } // An example loop that runs for 40000 sample frames count = 0; while (count < 40000) { // Generate your samples and fill the buffer with bufferSize sample frames of data ... // Trigger the output of the data buffer try { audio->tickStream(); } catch (RtError &error) { error.printMessage(); goto cleanup; } count += bufferSize; } try { // Stop and close the stream audio->stopStream(); audio->closeStream(); } catch (RtError &error) { error.printMessage(); } cleanup: delete audio; return 0; }
The first thing to notice in this example is that we attempt to open a stream during class instantiation with an overloaded constructor. This constructor simply combines the functionality of the default constructor, used earlier, and the RtAudio::openStream() method. Again, we have specified a device value of 0, indicating that the default or first available device meeting the given parameters should be used. An attempt is made to open the stream with the specified bufferSize value. However, it is possible that the device will not accept this value, in which case the closest allowable size is used and returned via the pointer value. The constructor can fail if no available devices are found, or a memory allocation or device driver error occurs. Note that you should not call the RtAudio destructor if an exception is thrown during instantiation.
Assuming the constructor is successful, it is necessary to get a pointer to the buffer, provided by RtAudio, for use in feeding data to/from the opened stream. Note that the user should NOT attempt to deallocate the stream buffer memory ... memory management for the stream buffer will be automatically controlled by RtAudio. After starting the stream with RtAudio::startStream(), one simply fills that buffer, which is of length equal to the returned bufferSize value, with interleaved audio data (in the specified format) for playback. Finally, a call to the RtAudio::tickStream() routine triggers a blocking write call for the stream.
In general, one should call the RtAudio::stopStream() and RtAudio::closeStream() methods after finishing with a stream. However, both methods will implicitly be called during object destruction if necessary.
#include <iostream> #include "RtAudio.h" // Two-channel sawtooth wave generator. int sawtooth(char *buffer, int bufferSize, void *data) { int i, j; double *my_buffer = (double *) buffer; double *my_data = (double *) data; // Write interleaved audio data. for (i=0; i<bufferSize; i++) { for (j=0; j<2; j++) { *my_buffer++ = my_data[j]; my_data[j] += 0.005 * (j+1+(j*0.1)); if (my_data[j] >= 1.0) my_data[j] -= 2.0; } } return 0; } int main() { int channels = 2; int sampleRate = 44100; int bufferSize = 256; // 256 sample frames int nBuffers = 4; // number of internal buffers used by device int device = 0; // 0 indicates the default or first available device double data[2]; char input; RtAudio *audio = 0; // Open a stream during RtAudio instantiation try { audio = new RtAudio(device, channels, 0, 0, RTAUDIO_FLOAT64, sampleRate, &bufferSize, nBuffers); } catch (RtError &error) { error.printMessage(); exit(EXIT_FAILURE); } try { // Set the stream callback function audio->setStreamCallback(&sawtooth, (void *)data); // Start the stream audio->startStream(); } catch (RtError &error) { error.printMessage(); goto cleanup; } std::cout << "\nPlaying ... press <enter> to quit.\n"; std::cin.get(input); try { // Stop and close the stream audio->stopStream(); audio->closeStream(); } catch (RtError &error) { error.printMessage(); } cleanup: delete audio; return 0; }
After opening the device in exactly the same way as the previous example (except with a data format change), we must set our callback function for the stream using RtAudio::setStreamCallback(). When the underlying audio API uses blocking calls (OSS, ALSA, SGI, and Windows DirectSound), this method will spawn a new process (or thread) that automatically calls the callback function when more data is needed. Callback-based audio APIs (OS X CoreAudio Linux Jack, and ASIO) implement their own event notification schemes. Note that the callback function is called only when the stream is "running" (between calls to the RtAudio::startStream() and RtAudio::stopStream() methods). The last argument to RtAudio::setStreamCallback() is a pointer to arbitrary data that you wish to access from within your callback function.
In this example, we stop the stream with an explicit call to RtAudio::stopStream(). When using callback functionality, it is also possible to stop a stream by returning a non-zero value from the callback function.
Once set with RtAudio::setStreamCallback, the callback process exists for the life of the stream (until the stream is closed with RtAudio::closeStream() or the RtAudio instance is deleted). It is possible to disassociate a callback function and cancel its process for an open stream using the RtAudio::cancelStreamCallback() method. The stream can then be used with blocking functionality or a new callback can be associated with it.
// record.cpp #include "RtAudio.h" int main() { int count; int channels = 2; int sampleRate = 44100; int bufferSize = 256; // 256 sample frames int nBuffers = 4; // number of internal buffers used by device float *buffer; int device = 0; // 0 indicates the default or first available device RtAudio *audio = 0; // Instantiate RtAudio and open a stream. try { audio = new RtAudio(&stream, 0, 0, device, channels, RTAUDIO_FLOAT32, sampleRate, &bufferSize, nBuffers); } catch (RtError &error) { error.printMessage(); exit(EXIT_FAILURE); } try { // Get a pointer to the stream buffer buffer = (float *) audio->getStreamBuffer(); // Start the stream audio->startStream(); } catch (RtError &error) { error.printMessage(); goto cleanup; } // An example loop that runs for about 40000 sample frames count = 0; while (count < 40000) { // Read a buffer of data try { audio->tickStream(); } catch (RtError &error) { error.printMessage(); goto cleanup; } // Process the input samples (bufferSize sample frames) that were read ... count += bufferSize; } try { // Stop the stream audio->stopStream(); } catch (RtError &error) { error.printMessage(); } cleanup: delete audio; return 0; }
In this example, the stream was opened for recording with a non-zero inputChannels value. The only other difference between this example and that for playback involves the order of data processing in the loop, where it is necessary to first read a buffer of input data before manipulating it.
// duplex.cpp #include <iostream> #include "RtAudio.h" // Pass-through function. int scale(char *buffer, int bufferSize, void *) { // Note: do nothing here for pass through. double *my_buffer = (double *) buffer; // Scale input data for output. for (int i=0; i<bufferSize; i++) { // Do for two channels. *my_buffer++ *= 0.5; *my_buffer++ *= 0.5; } return 0; } int main() { int channels = 2; int sampleRate = 44100; int bufferSize = 256; // 256 sample frames int nBuffers = 4; // number of internal buffers used by device int device = 0; // 0 indicates the default or first available device char input; RtAudio *audio = 0; // Open a stream during RtAudio instantiation try { audio = new RtAudio(device, channels, device, channels, RTAUDIO_FLOAT64, sampleRate, &bufferSize, nBuffers); } catch (RtError &error) { error.printMessage(); exit(EXIT_FAILURE); } try { // Set the stream callback function audio->setStreamCallback(&scale, NULL); // Start the stream audio->startStream(); } catch (RtError &error) { error.printMessage(); goto cleanup; } std::cout << "\nRunning duplex ... press <enter> to quit.\n"; std::cin.get(input); try { // Stop and close the stream audio->stopStream(); audio->closeStream(); } catch (RtError &error) { error.printMessage(); } cleanup: delete audio; return 0; }
When an RtAudio stream is running in duplex mode (nonzero input AND output channels), the audio write (playback) operation always occurs before the audio read (record) operation. This sequence allows the use of a single buffer to store both output and input data.
As we see with this example, the write-read sequence of operations does not preclude the use of RtAudio in situations where input data is first processed and then output through a duplex stream. When the stream buffer is first allocated, it is initialized with zeros, which produces no audible result when output to the device. In this example, anything recorded by the audio stream input will be scaled and played out during the next round of audio processing.
Note that duplex operation can also be achieved by opening one output stream instance and one input stream instance using the same or different devices. However, there may be timing problems when attempting to use two different devices, due to possible device clock variations, unless a common external "sync" is provided. This becomes even more difficult to achieve using two separate callback streams because it is not possible to explicitly control the calling order of the callback functions.
| OS: | Audio API: | C++ Class: | Preprocessor Definition: | Library or Framework: | Example Compiler Statement: |
| Linux | ALSA | RtApiAlsa | __LINUX_ALSA__ | asound, pthread | g++ -Wall -D__LINUX_ALSA__ -o probe probe.cpp RtAudio.cpp -lasound -lpthread |
| Linux | Jack Audio Server | RtApiJack | __LINUX_JACK__ | jack, pthread | g++ -Wall -D__LINUX_JACK__ -o probe probe.cpp RtAudio.cpp `pkg-config --cflags --libs jack` -lpthread |
| Linux | OSS | RtApiOss | __LINUX_OSS__ | pthread | g++ -Wall -D__LINUX_OSS__ -o probe probe.cpp RtAudio.cpp -lpthread |
| Macintosh OS X | CoreAudio | RtApiCore | __MACOSX_CORE__ | pthread, stdc++, CoreAudio | g++ -Wall -D__MACOSX_CORE__ -o probe probe.cpp RtAudio.cpp -framework CoreAudio -lpthread |
| Irix | AL | RtApiAl | __IRIX_AL__ | audio, pthread | CC -Wall -D__IRIX_AL__ -o probe probe.cpp RtAudio.cpp -laudio -lpthread |
| Windows | Direct Sound | RtApiDs | __WINDOWS_DS__ | dsound.lib (ver. 5.0 or higher), multithreaded | compiler specific |
| Windows | ASIO | RtApiAsio | __WINDOWS_ASIO__ | various ASIO header and source files | compiler specific |
The example compiler statements above could be used to compile the probe.cpp example file, assuming that probe.cpp, RtAudio.h, RtError.h, and RtAudio.cpp all exist in the same directory.
__RTAUDIO_DEBUG__ to the compiler (or uncomment the definition at the bottom of RtAudio.h). A variety of warning messages will be displayed that may help in determining the problem. Also try using the programs included in the test directory. The program info displays the queried capabilities of all hardware devices found.The ALSA library includes OSS emulation support. That means that you can run programs compiled for the OSS API even when using the ALSA drivers and library. It should be noted however that OSS emulation under ALSA is not perfect. Specifically, channel number queries seem to consistently produce invalid results. While OSS emulation is successful for the majority of RtAudio tests, it is recommended that the native ALSA implementation of RtAudio be used on systems that have ALSA drivers installed.
The ALSA implementation of RtAudio makes no use of the ALSA "plug" interface. All necessary data format conversions, channel compensation, de-interleaving, and byte-swapping is handled by internal RtAudio routines.
The Jack API is based on a callback scheme. RtAudio provides blocking functionality, in addition to callback functionality, within the context of that behavior. It should be noted, however, that the best performance is achieved when using RtAudio's callback functionality with the Jack API. At the moment, only one RtAudio instance can be connected to the Jack server. Because RtAudio does not provide a mechanism for allowing the user to specify particular channels (or ports) of a device, it simply opens the first N enumerated Jack ports for input/output.
It is not possible to have multiple instances of RtAudio accessing the same CoreAudio device.
The DirectSound version of RtAudio can be compiled with or without the UNICODE preprocessor definition.
A number of ASIO source and header files are required for use with RtAudio. Specifically, an RtAudio project must include the following files: asio.h,cpp; asiodrivers.h,cpp; asiolist.h,cpp; asiodrvr.h; asiosys.h; ginclude.h; iasiodrv.h; iasiothiscallresolver.h,cpp. The Visual C++ projects found in /tests/Windows/ compile both ASIO and DirectSound support.
The Steinberg provided asiolist class does not compile when the preprocessor definition UNICODE is defined. Note that this could be an issue when using RtAudio with Qt, though Qt programs appear to compile without the UNICODE definition (try DEFINES -= UNICODE in your .pro file). RtAudio with ASIO support has been tested using the MinGW compiler under Windows XP, as well as in the Visual Studio environment.
The RtAudio API incorporates many of the concepts developed in the PortAudio project by Phil Burk and Ross Bencina. Early development also incorporated ideas from Bill Schottstaedt's sndlib. The CCRMA SoundWire group provided valuable feedback during the API proposal stages.
The early 2.0 version of RtAudio was slowly developed over the course of many months while in residence at the Institut Universitari de L'Audiovisual (IUA) in Barcelona, Spain and the Laboratory of Acoustics and Audio Signal Processing at the Helsinki University of Technology, Finland. Much subsequent development happened while working at the Center for Computer Research in Music and Acoustics (CCRMA) at Stanford University. The most recent version of RtAudio was finished while working as an assistant professor of Music Technology at McGill University. This work was supported in part by the United States Air Force Office of Scientific Research (grant #F49620-99-1-0293).
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Any person wishing to distribute modifications to the Software is requested to send the modifications to the original developer so that they can be incorporated into the canonical version.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
©2001-2005 Gary P. Scavone, McGill University. All Rights Reserved. Maintained by Gary P. Scavone, gary@music.mcgill.ca |