1 /*! \mainpage The RtAudio Tutorial
\r
3 <BODY BGCOLOR="white">
\r
19 \section intro Introduction
\r
21 RtAudio is a C++ class which provides a common API (Application Programming Interface) for realtime audio input/output across Linux (native ALSA and OSS), SGI, and Windows operating systems. RtAudio significantly simplifies the process of interacting with computer audio hardware. It was designed with the following goals:
\r
24 <LI>object oriented C++ design</LI>
\r
25 <LI>simple, common API across all supported platforms</LI>
\r
26 <LI>single independent header and source file for easy inclusion in programming projects (no libraries!)</LI>
\r
27 <LI>blocking functionality</LI>
\r
28 <LI>callback functionality</LI>
\r
29 <LI>extensive audio device parameter control</LI>
\r
30 <LI>audio device capability probing</LI>
\r
31 <LI>automatic internal conversion for data format, channel number compensation, de-interleaving, and byte-swapping</LI>
\r
32 <LI>control over multiple audio streams and devices with a single instance</LI>
\r
35 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. Multiple streams can run at the same time and, when allowed by the underlying audio API, a single device can serve multiple streams.
\r
37 The RtAudio API provides both blocking (synchronous) and callback (asyncronous) 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.
\r
39 \section start Getting Started
\r
41 The first thing that must be done when using RtAudio is to create an instance of the class. The default constructor RtAudio::RtAudio() 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:
\r
45 #include "RtAudio.h"
\r
51 // Default RtAudio constructor
\r
53 audio = new RtAudio();
\r
55 catch (RtError &error) {
\r
56 // Handle the exception here
\r
64 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 which can throw a C++ exception be called within a try/catch block.
\r
67 \section error Error Handling
\r
69 RtAudio uses a C++ exception handler called RtError, which is declared and defined within the RtAudio class files. The RtError class is quite simple but it does allow errors to be "caught" by RtError::TYPE. Almost all RtAudio methods can "throw" an RtError, most typically if an invalid stream identifier is supplied to a method or a driver error occurs. There are a number of cases within RtAudio where warning messages may be displayed but an exception is not thrown. There is a private RtAudio method, error(), which can be modified to globally control how these messages are handled and reported.
\r
72 \section probing Probing Device Capabilities
\r
74 A programmer may wish to query the available audio device capabilities before deciding which to use. The following example outlines how this can be done.
\r
81 #include "RtAudio.h"
\r
87 // Default RtAudio constructor
\r
89 audio = new RtAudio();
\r
91 catch (RtError &error) {
\r
92 error.printMessage();
\r
96 // Determine the number of devices available
\r
97 int devices = audio->getDeviceCount();
\r
99 // Scan through devices for various capabilities
\r
100 RtAudio::RTAUDIO_DEVICE info;
\r
101 for (int i=0; i<devices; i++) {
\r
104 audio->getDeviceInfo(i, &info);
\r
106 catch (RtError &error) {
\r
107 error.printMessage();
\r
111 // Print, for example, the maximum number of output channels for each device
\r
112 cout << "device = " << i;
\r
113 cout << ": maximum output channels = " << info.maxOutputChannels << "\n";
\r
123 The RTAUDIO_DEVICE structure is defined in RtAudio.h and provides a variety of information useful in assessing the capabilities of a device:
\r
128 DEVICE_ID id[2]; // No value reported by getDeviceInfo().
\r
129 bool probed; // true if the device probe was successful.
\r
130 int maxOutputChannels;
\r
131 int maxInputChannels;
\r
132 int maxDuplexChannels;
\r
133 int minOutputChannels;
\r
134 int minInputChannels;
\r
135 int minDuplexChannels;
\r
136 bool hasDuplexSupport; // true if duplex supported
\r
137 int nSampleRates; // Number of discrete rates, or -1 if range supported.
\r
138 double sampleRates[MAX_SAMPLE_RATES]; // Supported sample rates, or {min, max} if range.
\r
139 RTAUDIO_FORMAT nativeFormats;
\r
143 The following data formats are defined and fully supported by RtAudio:
\r
146 typedef unsigned long RTAUDIO_FORMAT;
\r
147 static const RTAUDIO_FORMAT RTAUDIO_SINT8; // Signed 8-bit integer
\r
148 static const RTAUDIO_FORMAT RTAUDIO_SINT16; // Signed 16-bit integer
\r
149 static const RTAUDIO_FORMAT RTAUDIO_SINT24; // Signed 24-bit integer
\r
150 static const RTAUDIO_FORMAT RTAUDIO_SINT32; // Signed 32-bit integer
\r
151 static const RTAUDIO_FORMAT RTAUDIO_FLOAT32; // 32-bit float
\r
152 static const RTAUDIO_FORMAT RTAUDIO_FLOAT64; // 64-bit double
\r
155 The <I>nativeFormats</I> member of the RtAudio::RTAUDIO_DEVICE structure is a bit mask of the above formats which are natively supported by the device. However, RtAudio will automatically provide format conversion if a particular format is not natively supported. When the <I>probed</I> member of the RTAUDIO_DEVICE structure is false, the remaining structure members are likely unknown and the device is probably unuseable.
\r
157 In general, the user need not be concerned with the minimum channel values reported in the RTAUDIO_DEVICE structure. While some audio devices may require a minimum channel value > 1, 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 <I>NOT</I> possible when the number of channels set by the user is greater than that supported by the device.
\r
159 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.
\r
162 \section settings Device Settings
\r
164 The next step in using RtAudio is to open a stream with a particular set of device settings.
\r
168 #include "RtAudio.h"
\r
173 int sample_rate = 44100;
\r
174 int buffer_size = 256; // 256 sample frames
\r
175 int n_buffers = 4; // number of internal buffers used by device
\r
176 int device = 0; // 0 indicates the default or first available device
\r
177 int stream; // our stream identifier
\r
180 // Instantiate RtAudio and open a stream within a try/catch block
\r
182 audio = new RtAudio();
\r
183 stream = audio->openStream(device, channels, 0, 0, RtAudio::RTAUDIO_FLOAT32,
\r
184 sample_rate, &buffer_size, n_buffers);
\r
186 catch (RtError &error) {
\r
187 error.printMessage();
\r
188 exit(EXIT_FAILURE);
\r
198 The RtAudio::openStream() method attempts to open a stream with a specified set of parameter values. When successful, a stream identifier is returned. In this case, we attempt to open a playback stream on device 0 with two channels, 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, an attempt is made to find a device or set of devices which 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.
\r
200 RtAudio provides four signed integer and two floating point data formats which can be specified using the RtAudio::RTAUDIO_FORMAT parameter values mentioned earlier. If the opened device does not natively support the given format, RtAudio will automatically perform the necessary data format conversion.
\r
202 The <I>bufferSize</I> parameter specifies the desired number of sample frames which will be written to and/or read from a device per write/read operation. The <I>nBuffers</I> parameter is used in setting the underlying device buffer parameters. Both the <I>bufferSize</I> and <I>nBuffers</I> parameters can be used to control stream latency though there is no guarantee that the passed values will be those used by a device. 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 <I>bufferSize</I> parameter is passed as a pointer and the actual value used by the stream is set during the device setup procedure. <I>bufferSize</I> values should be a power of two. Optimal and allowable buffer values tend to vary between systems and devices. Check the \ref osnotes section for general guidelines.
\r
204 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.
\r
207 \section playbackb Playback (blocking functionality)
\r
209 Once the device is open for playback, there are only a few final steps necessary for realtime audio output. We'll first provide an example (blocking functionality) and then discuss the details.
\r
214 #include "RtAudio.h"
\r
220 int sample_rate = 44100;
\r
221 int buffer_size = 256; // 256 sample frames
\r
222 int n_buffers = 4; // number of internal buffers used by device
\r
224 int device = 0; // 0 indicates the default or first available device
\r
225 int stream; // our stream identifier
\r
228 // Open a stream during RtAudio instantiation
\r
230 audio = new RtAudio(&stream, device, channels, 0, 0, RtAudio::RTAUDIO_FLOAT32,
\r
231 sample_rate, &buffer_size, n_buffers);
\r
233 catch (RtError &error) {
\r
234 error.printMessage();
\r
235 exit(EXIT_FAILURE);
\r
239 // Get a pointer to the stream buffer
\r
240 buffer = (float *) audio->getStreamBuffer(stream);
\r
242 // Start the stream
\r
243 audio->startStream(stream);
\r
245 catch (RtError &error) {
\r
246 error.printMessage();
\r
250 // An example loop which runs for about 40000 sample frames
\r
252 while (count < 40000) {
\r
253 // Generate your samples and fill the buffer with buffer_size sample frames of data
\r
256 // Trigger the output of the data buffer
\r
258 audio->tickStream(stream);
\r
260 catch (RtError &error) {
\r
261 error.printMessage();
\r
265 count += buffer_size;
\r
269 // Stop and close the stream
\r
270 audio->stopStream(stream);
\r
271 audio->closeStream(stream);
\r
273 catch (RtError &error) {
\r
274 error.printMessage();
\r
284 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. The integer identifier of the opened stream is returned via the <I>stream</I> pointer value. An attempt is made to open the stream with the specified <I>bufferSize</I> 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.
\r
286 Because RtAudio can be used to simultaneously control more than a single stream, it is necessary that the stream identifier be provided to nearly all public methods. 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 <I>NOT</I> 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 <I>bufferSize</I> 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.
\r
288 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.
\r
291 \section playbackc Playback (callback functionality)
\r
293 The primary difference in using RtAudio with callback functionality involves the creation of a user-defined callback function. Here is an example which produces a sawtooth waveform for playback.
\r
297 #include <iostream>
\r
298 #include "RtAudio.h"
\r
300 // Two-channel sawtooth wave generator.
\r
301 int sawtooth(char *buffer, int buffer_size, void *data)
\r
304 double *my_buffer = (double *) buffer;
\r
305 double *my_data = (double *) data;
\r
307 // Write interleaved audio data.
\r
308 for (i=0; i<buffer_size; i++) {
\r
309 for (j=0; j<2; j++) {
\r
310 *my_buffer++ = my_data[j];
\r
312 my_data[j] += 0.005 * (j+1+(j*0.1));
\r
313 if (my_data[j] >= 1.0) my_data[j] -= 2.0;
\r
323 int sample_rate = 44100;
\r
324 int buffer_size = 256; // 256 sample frames
\r
325 int n_buffers = 4; // number of internal buffers used by device
\r
326 int device = 0; // 0 indicates the default or first available device
\r
327 int stream; // our stream identifier
\r
332 // Open a stream during RtAudio instantiation
\r
334 audio = new RtAudio(&stream, device, channels, 0, 0, RtAudio::RTAUDIO_FLOAT64,
\r
335 sample_rate, &buffer_size, n_buffers);
\r
337 catch (RtError &error) {
\r
338 error.printMessage();
\r
339 exit(EXIT_FAILURE);
\r
343 // Set the stream callback function
\r
344 audio->setStreamCallback(stream, &sawtooth, (void *)data);
\r
346 // Start the stream
\r
347 audio->startStream(stream);
\r
349 catch (RtError &error) {
\r
350 error.printMessage();
\r
354 cout << "\nPlaying ... press <enter> to quit.\n";
\r
358 // Stop and close the stream
\r
359 audio->stopStream(stream);
\r
360 audio->closeStream(stream);
\r
362 catch (RtError &error) {
\r
363 error.printMessage();
\r
373 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(). This method will spawn a new process (or thread) which automatically calls the callback function when more data is needed. 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.
\r
375 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.
\r
377 Once set with RtAudio::setStreamCallback, the callback process will continue to run 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.
\r
380 \section recording Recording
\r
382 Using RtAudio for audio input is almost identical to the way it is used for playback. Here's the blocking playback example rewritten for recording:
\r
387 #include "RtAudio.h"
\r
393 int sample_rate = 44100;
\r
394 int buffer_size = 256; // 256 sample frames
\r
395 int n_buffers = 4; // number of internal buffers used by device
\r
397 int device = 0; // 0 indicates the default or first available device
\r
398 int stream; // our stream identifier
\r
401 // Instantiate RtAudio and open a stream.
\r
403 audio = new RtAudio(&stream, 0, 0, device, channels,
\r
404 RtAudio::RTAUDIO_FLOAT32, sample_rate, &buffer_size, n_buffers);
\r
406 catch (RtError &error) {
\r
407 error.printMessage();
\r
408 exit(EXIT_FAILURE);
\r
412 // Get a pointer to the stream buffer
\r
413 buffer = (float *) audio->getStreamBuffer(stream);
\r
415 // Start the stream
\r
416 audio->startStream(stream);
\r
418 catch (RtError &error) {
\r
419 error.printMessage();
\r
423 // An example loop which runs for about 40000 sample frames
\r
425 while (count < 40000) {
\r
427 // Read a buffer of data
\r
429 audio->tickStream(stream);
\r
431 catch (RtError &error) {
\r
432 error.printMessage();
\r
436 // Process the input samples (buffer_size sample frames) that were read
\r
439 count += buffer_size;
\r
444 audio->stopStream(stream);
\r
446 catch (RtError &error) {
\r
447 error.printMessage();
\r
457 In this example, the stream was opened for recording with a non-zero <I>inputChannels</I> 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.
\r
460 \section duplex Duplex Mode
\r
462 Finally, it is easy to use RtAudio for simultaneous audio input/output, or duplex operation. In this example, we use a callback function and pass our recorded data directly through for playback.
\r
467 #include <iostream>
\r
468 #include "RtAudio.h"
\r
470 // Pass-through function.
\r
471 int pass(char *buffer, int buffer_size, void *)
\r
473 // Surprise!! We do nothing to pass the data through.
\r
480 int sample_rate = 44100;
\r
481 int buffer_size = 256; // 256 sample frames
\r
482 int n_buffers = 4; // number of internal buffers used by device
\r
483 int device = 0; // 0 indicates the default or first available device
\r
484 int stream; // our stream identifier
\r
489 // Open a stream during RtAudio instantiation
\r
491 audio = new RtAudio(&stream, device, channels, device, channels, RtAudio::RTAUDIO_FLOAT64,
\r
492 sample_rate, &buffer_size, n_buffers);
\r
494 catch (RtError &error) {
\r
495 error.printMessage();
\r
496 exit(EXIT_FAILURE);
\r
500 // Set the stream callback function
\r
501 audio->setStreamCallback(stream, &pass, NULL);
\r
503 // Start the stream
\r
504 audio->startStream(stream);
\r
506 catch (RtError &error) {
\r
507 error.printMessage();
\r
511 cout << "\nRunning duplex ... press <enter> to quit.\n";
\r
515 // Stop and close the stream
\r
516 audio->stopStream(stream);
\r
517 audio->closeStream(stream);
\r
519 catch (RtError &error) {
\r
520 error.printMessage();
\r
530 When an RtAudio stream is running in duplex mode (nonzero input <I>AND</I> 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.
\r
532 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 played out during the next round of audio processing.
\r
534 Note that duplex operation can also be achieved by opening one output stream and one input stream 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. 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.
\r
537 \section methods Summary of Methods
\r
539 The following is short summary of public methods (not including constructors and the destructor) provided by RtAudio:
\r
542 <LI>RtAudio::openStream(): opens a stream with the specified parameters.</LI>
\r
543 <LI>RtAudio::setStreamCallback(): sets a user-defined callback function for a given stream.</LI>
\r
544 <LI>RtAudio::cancelStreamCallback(): cancels a callback process and function for a given stream.</LI>
\r
545 <LI>RtAudio::getDeviceCount(): returns the number of audio devices available.</LI>
\r
546 <LI>RtAudio::getDeviceInfo(): fills a user-supplied RTAUDIO_DEVICE structure for a specified device.</LI>
\r
547 <LI>RtAudio::getStreamBuffer(): returns a pointer to the stream buffer.</LI>
\r
548 <LI>RtAudio::tickStream(): triggers processing of input/output data for a stream (blocking).</LI>
\r
549 <LI>RtAudio::closeStream(): closes the specified stream (implicitly called during object destruction). Once a stream is closed, the stream identifier is invalid and should not be used in calling any other RtAudio methods.</LI>
\r
550 <LI>RtAudio::startStream(): (re)starts the specified stream, typically after it has been stopped with either stopStream() or abortStream() or after first opening the stream.</LI>
\r
551 <LI>RtAudio::stopStream(): stops the specified stream, allowing any remaining samples in the queue to be played out and/or read in. This does not implicitly call RtAudio::closeStream().</LI>
\r
552 <LI>RtAudio::abortStream(): stops the specified stream, discarding any remaining samples in the queue. This does not implicitly call closeStream().</LI>
\r
553 <LI>RtAudio::streamWillBlock(): queries a stream to determine whether a call to the <I>tickStream()</I> method will block. A return value of 0 indicates that the stream will NOT block. A positive return value indicates the number of sample frames that cannot yet be processed without blocking.</LI>
\r
557 \section compiling Compiling
\r
559 In order to compile RtAudio for a specific OS and audio API, it is necessary to supply the appropriate preprocessor definition and library within the compiler statement:
\r
562 <TABLE BORDER=2 COLS=5 WIDTH="100%">
\r
563 <TR BGCOLOR="beige">
\r
564 <TD WIDTH="5%"><B>OS:</B></TD>
\r
565 <TD WIDTH="5%"><B>Audio API:</B></TD>
\r
566 <TD WIDTH="5%"><B>Preprocessor Definition:</B></TD>
\r
567 <TD WIDTH="5%"><B>Library:</B></TD>
\r
568 <TD><B>Example Compiler Statement:</B></TD>
\r
573 <TD>__LINUX_ALSA__</TD>
\r
574 <TD><TT>libasound, libpthread</TT></TD>
\r
575 <TD><TT>g++ -Wall -D__LINUX_ALSA__ -o probe probe.cpp RtAudio.cpp -lasound -lpthread</TT></TD>
\r
580 <TD>__LINUX_OSS__</TD>
\r
581 <TD><TT>libpthread</TT></TD>
\r
582 <TD><TT>g++ -Wall -D__LINUX_OSS__ -o probe probe.cpp RtAudio.cpp -lpthread</TT></TD>
\r
587 <TD>__IRIX_AL__</TD>
\r
588 <TD><TT>libaudio, libpthread</TT></TD>
\r
589 <TD><TT>CC -Wall -D__IRIX_AL__ -o probe probe.cpp RtAudio.cpp -laudio -lpthread</TT></TD>
\r
593 <TD>Direct Sound</TD>
\r
594 <TD>__WINDOWS_DS__</TD>
\r
595 <TD><TT>dsound.lib (ver. 5.0 or higher), multithreaded</TT></TD>
\r
596 <TD><I>compiler specific</I></TD>
\r
601 The example compiler statements above could be used to compile the <TT>probe.cpp</TT> example file, assuming that <TT>probe.cpp</TT>, <TT>RtAudio.h</TT>, and <TT>RtAudio.cpp</TT> all exist in the same directory.
\r
603 \section osnotes OS Notes
\r
605 RtAudio is designed to provide a common API across the various supported operating systems and audio libraries. Despite that, however, some issues need to be mentioned with regard to each.
\r
607 \subsection linux Linux:
\r
609 RtAudio for Linux was developed under Redhat distributions 7.0 - 7.2. Two different audio APIs are supported on Linux platforms: OSS and <A href="http://www.alsa-project.org/">ALSA</A>. The OSS API has existed for at least 6 years and the Linux kernel is distributed with free versions of OSS audio drivers. Therefore, a generic Linux system is most likely to have OSS support. The ALSA API, although relatively new, is now part of the Linux development kernel and offers significantly better functionality than the OSS API. RtAudio provides support for the 0.9 and higher versions of ALSA. Input/output latency on the order of 15 milliseconds can typically be achieved under both OSS or ALSA by fine-tuning the RtAudio buffer parameters (without kernel modifications). Latencies on the order of 5 milliseconds or less can be achieved using a low-latency kernel patch and increasing FIFO scheduling priority. The pthread library, which is used for callback functionality, is a standard component of all Linux distributions.
\r
611 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 which have ALSA drivers installed.
\r
613 The ALSA implementation of RtAudio makes no use of the ALSA "plug" interface. All necessary data format conversions, channel compensation, deinterleaving, and byte-swapping is handled by internal RtAudio routines.
\r
615 \subsection irix Irix (SGI):
\r
617 The Irix version of RtAudio was written and tested on an SGI Indy running Irix version 6.5.4 and the newer "al" audio library. RtAudio does not compile under Irix version 6.3, mainly because the C++ compiler is too old. Despite the relatively slow speed of the Indy, RtAudio was found to behave quite well and input/output latency was very good. No problems were found with respect to using the pthread library.
\r
619 \subsection windows Windows:
\r
621 RtAudio under Windows is written using the DirectSound API. In order to compile RtAudio under Windows, you must have the header and source files for DirectSound version 5.0 or higher. As far as I know, there is no DirectSoundCapture support for Windows NT (in which case, you cannot use RtAudio). Audio output latency with DirectSound can be reasonably good (on the order of 20 milliseconds). On the other hand, input audio latency tends to be terrible (100 milliseconds or more). Further, DirectSound drivers tend to crash easily when experimenting with buffer parameters. On my system, I found it necessary to use values around nBuffers = 8 and bufferSize = 512 to avoid crashing my system. RtAudio was developed with Visual C++ version 6.0. I was forced in several instances to modify code in order to get it to compile under the non-standard version of C++ that Microsoft so unprofessionally implemented. We can only hope that the developers of Visual C++ 7.0 will have time to read the C++ standard.
\r
624 \section acknowledge Acknowledgements
\r
626 The RtAudio API incorporates many of the concepts developed in the <A href="http://www.portaudio.com/">PortAudio</A> project by Phil Burk and Ross Bencina. Early development also incorporated ideas from Bill Schottstaedt's <A href="http://www-ccrma.stanford.edu/software/snd/sndlib/">sndlib</A>. The CCRMA <A href="http://www-ccrma.stanford.edu/groups/soundwire/">SoundWire group</A> provided valuable feedback during the API proposal stages.
\r
628 RtAudio was slowly developed over the course of many months while in residence at the <A href="http://www.iua.upf.es/">Institut Universitari de L'Audiovisual (IUA)</A> in Barcelona, Spain, the <A href="http://www.acoustics.hut.fi/">Laboratory of Acoustics and Audio Signal Processing</A> at the Helsinki University of Technology, Finland, and the <A href="http://www-ccrma.stanford.edu/">Center for Computer Research in Music and Acoustics (CCRMA)</A> at <A href="http://www.stanford.edu/">Stanford University</A>. This work was supported in part by the United States Air Force Office of Scientific Research (grant \#F49620-99-1-0293).
\r