The <a class="el" href="classRtAudio.html#a9">RtAudio::getDeviceInfo()</a> function was modified to return a globally defined <a class="el" href="structRtAudioDeviceInfo.html">RtAudioDeviceInfo</a> 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 <a class="el" href="RtAudio_8h-source.html">RtAudio.h</a>. These changes were made for clarity and to better conform with standard C++ programming practices.<p>
The <a class="el" href="classRtError.html">RtError</a> class declaration and definition have been extracted to a separate file (<a class="el" href="RtError_8h-source.html">RtError.h</a>). This was done in preparation for a new release of the RtMidi class (planned for Summer 2004).<h2><a class="anchor" name="download">
Download</a></h2>
-Latest Release (1
4 October 2005): <a href="http://music.mcgill.ca/~gary/rtaudio/release/rtaudio-3.0.2.tar.gz">Version 3.0.2</a><h2><a class="anchor" name="start">
+Latest Release (1
8 November 2005): <a href="http://music.mcgill.ca/~gary/rtaudio/release/rtaudio-3.0.3.tar.gz">Version 3.0.3</a><h2><a class="anchor" name="start">
Getting Started</a></h2>
With version 3.0, it is now possible to compile multiple API support on a given platform and to specify an API choice during class instantiation. In the examples that follow, no API will be specified (in which case, <a class="el" href="classRtAudio.html">RtAudio</a> attempts to select the most "logical" available API).<p>
The first thing that must be done when using <a class="el" href="classRtAudio.html">RtAudio</a> 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. <a class="el" href="classRtAudio.html">RtAudio</a> 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:<p>
<span class="keyword">delete</span> audio;
}
</pre></div><p>
-Obviously, this example doesn't demonstrate any of the real functionality of <a class="el" href="classRtAudio.html">RtAudio</a>. However, all uses of <a class="el" href="classRtAudio.html">RtAudio</a> 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.<h2><a class="anchor" name="error">
+Obviously, this example doesn't demonstrate any of the real functionality of <a class="el" href="classRtAudio.html">RtAudio</a>. However, all uses of <a class="el" href="classRtAudio.html">RtAudio</a> 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.<h2><a class="anchor" name="error">
Error Handling</a></h2>
-<a class="el" href="classRtAudio.html">RtAudio</a> uses a C++ exception handler called <a class="el" href="classRtError.html">RtError</a>, which is declared and defined in <a class="el" href="RtError_8h-source.html">RtError.h</a>. The <a class="el" href="classRtError.html">RtError</a> class is quite simple but it does allow errors to be "caught" by <a class="el" href="classRtError.html#w11">RtError::Type</a>. Almost all <a class="el" href="classRtAudio.html">RtAudio</a> methods can "throw" an <a class="el" href="classRtError.html">RtError</a>, most typically if a driver error occurs or a stream function is called when no stream is open. There are a number of cases within <a class="el" href="classRtAudio.html">RtAudio</a> where warning messages may be displayed but an exception is not thrown. There is a protected <a class="el" href="classRtAudio.html">RtAudio</a> method, error(),
which can be modified to globally control how these messages are handled and reported. By default, error messages are not automatically displayed in <a class="el" href="classRtAudio.html">RtAudio</a> unless the preprocessor definition __RTAUDIO_DEBUG__ is defined. Messages associated with caught exceptions can be displayed with, for example, the <a class="el" href="classRtError.html#a2">RtError::printMessage()</a> function.<h2><a class="anchor" name="probing">
+<a class="el" href="classRtAudio.html">RtAudio</a> uses a C++ exception handler called <a class="el" href="classRtError.html">RtError</a>, which is declared and defined in <a class="el" href="RtError_8h-source.html">RtError.h</a>. The <a class="el" href="classRtError.html">RtError</a> class is quite simple but it does allow errors to be "caught" by <a class="el" href="classRtError.html#w11">RtError::Type</a>. Almost all <a class="el" href="classRtAudio.html">RtAudio</a> methods can "throw" an <a class="el" href="classRtError.html">RtError</a>, most typically if a driver error occurs or a stream function is called when no stream is open. There are a number of cases within <a class="el" href="classRtAudio.html">RtAudio</a> where warning messages may be displayed but an exception is not thrown. There is a protected <a class="el" href="classRtAudio.html">RtAudio</a> method, error(),
that can be modified to globally control how these messages are handled and reported. By default, error messages are not automatically displayed in <a class="el" href="classRtAudio.html">RtAudio</a> unless the preprocessor definition __RTAUDIO_DEBUG__ is defined. Messages associated with caught exceptions can be displayed with, for example, the <a class="el" href="classRtError.html#a2">RtError::printMessage()</a> function.<h2><a class="anchor" name="probing">
Probing Device Capabilities</a></h2>
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.<p>
<div class="fragment"><pre class="fragment"><span class="comment">// probe.cpp</span>
<span class="keyword">static</span> <span class="keyword">const</span> RtAudioFormat RTAUDIO_FLOAT32; <span class="comment">// 32-bit float normalized between +/- 1.0</span>
<span class="keyword">static</span> <span class="keyword">const</span> RtAudioFormat RTAUDIO_FLOAT64; <span class="comment">// 64-bit double normalized between +/- 1.0</span>
</pre></div><p>
-The <em>nativeFormats</em> member of the <a class="el" href="structRtAudioDeviceInfo.html">RtAudioDeviceInfo</a> structure is a bit mask of the above formats
which are natively supported by the device. However, <a class="el" href="classRtAudio.html">RtAudio</a> will automatically provide format conversion if a particular format is not natively supported. When the <em>probed</em> member of the <a class="el" href="structRtAudioDeviceInfo.html">RtAudioDeviceInfo</a> structure is false, the remaining structure members are undefined and the device is probably unuseable.<p>
+The <em>nativeFormats</em> member of the <a class="el" href="structRtAudioDeviceInfo.html">RtAudioDeviceInfo</a> structure is a bit mask of the above formats
that are natively supported by the device. However, <a class="el" href="classRtAudio.html">RtAudio</a> will automatically provide format conversion if a particular format is not natively supported. When the <em>probed</em> member of the <a class="el" href="structRtAudioDeviceInfo.html">RtAudioDeviceInfo</a> structure is false, the remaining structure members are undefined and the device is probably unuseable.<p>
While some audio devices may require a minimum channel value greater than one, <a class="el" href="classRtAudio.html">RtAudio</a> 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 <em>NOT</em> possible when the number of channels set by the user is greater than that supported by the device.<p>
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, <a class="el" href="classRtAudio.html">RtAudio</a> does not typically rely on the queried values when attempting to open a stream.<h2><a class="anchor" name="settings">
Device Settings</a></h2>
<span class="keywordflow">return</span> 0;
}
</pre></div><p>
-The <a class="el" href="classRtAudio.html#a4">RtAudio::openStream()</a> 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, <a class="el" href="classRtAudio.html">RtAudio</a> first attempts to open the default audio device with the given parameters. If that attempt fails, <a class="el" href="classRtAudio.html">RtAudio</a> searches through the remaining available devices in an effort to find a device
which will meet the given parameters. If all attempts are unsuccessful, an <a class="el" href="classRtError.html">RtError</a> is thrown. When a non-zero device value is specified, an attempt is made to open that device <em>ONLY</em> (device = 1 specifies the first identified device, as reported by <a class="el" href="classRtAudio.html#a9">RtAudio::getDeviceInfo()</a>).<p>
-<a class="el" href="classRtAudio.html">RtAudio</a> provides four signed integer and two floating point data formats
which can be specified using the RtAudioFormat parameter values mentioned earlier. If the opened device does not natively support the given format, <a class="el" href="classRtAudio.html">RtAudio</a> will automatically perform the necessary data format conversion.<p>
-The <em>bufferSize</em> parameter specifies the desired number of sample frames
which will be written to and/or read from a device per write/read operation. The <em>nBuffers</em> parameter is used in setting the underlying device buffer parameters. Both the <em>bufferSize</em> and <em>nBuffers</em> 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 <em>nBuffers</em> 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 <em>bufferSize</em> parameter is passed as a pointer and the actual value used by the stream is set during the device setup procedure. <em>bufferSize</em> values should be a power of two. Optimal and allowable buffer values tend to vary between systems and devices. Check the <a class="el" href="index.html#apinotes">API Notes</a> section for general guidelines.<p>
+The <a class="el" href="classRtAudio.html#a4">RtAudio::openStream()</a> 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, <a class="el" href="classRtAudio.html">RtAudio</a> first attempts to open the default audio device with the given parameters. If that attempt fails, <a class="el" href="classRtAudio.html">RtAudio</a> 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 <a class="el" href="classRtError.html">RtError</a> is thrown. When a non-zero device value is specified, an attempt is made to open that device <em>ONLY</em> (device = 1 specifies the first identified device, as reported by <a class="el" href="classRtAudio.html#a9">RtAudio::getDeviceInfo()</a>).<p>
+<a class="el" href="classRtAudio.html">RtAudio</a> 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, <a class="el" href="classRtAudio.html">RtAudio</a> will automatically perform the necessary data format conversion.<p>
+The <em>bufferSize</em> parameter specifies the desired number of sample frames
that will be written to and/or read from a device per write/read operation. The <em>nBuffers</em> parameter is used in setting the underlying device buffer parameters. Both the <em>bufferSize</em> and <em>nBuffers</em> 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 <em>nBuffers</em> 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 <em>bufferSize</em> parameter is passed as a pointer and the actual value used by the stream is set during the device setup procedure. <em>bufferSize</em> values should be a power of two. Optimal and allowable buffer values tend to vary between systems and devices. Check the <a class="el" href="index.html#apinotes">API Notes</a> section for general guidelines.<p>
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, <a class="el" href="classRtAudio.html">RtAudio</a> does not attempt to query a device's capabilities or use previously reported values when opening a device. Instead, <a class="el" href="classRtAudio.html">RtAudio</a> simply attempts to set the given parameters on a specified device and then checks whether the setup is successful or not.<h2><a class="anchor" name="playbackb">
Playback (blocking functionality)</a></h2>
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.<p>
<span class="keywordflow">goto</span> cleanup;
}
- <span class="comment">// An example loop which runs for 40000 sample frames</span>
+ <span class="comment">// An example loop that runs for 40000 sample frames</span>
count = 0;
<span class="keywordflow">while</span> (count < 40000) {
<span class="comment">// Generate your samples and fill the buffer with bufferSize sample frames of data</span>
Assuming the constructor is successful, it is necessary to get a pointer to the buffer, provided by <a class="el" href="classRtAudio.html">RtAudio</a>, for use in feeding data to/from the opened stream. Note that the user should <em>NOT</em> attempt to deallocate the stream buffer memory ... memory management for the stream buffer will be automatically controlled by <a class="el" href="classRtAudio.html">RtAudio</a>. After starting the stream with <a class="el" href="classRtAudio.html#a13">RtAudio::startStream()</a>, one simply fills that buffer, which is of length equal to the returned <em>bufferSize</em> value, with interleaved audio data (in the specified format) for playback. Finally, a call to the <a class="el" href="classRtAudio.html#a11">RtAudio::tickStream()</a> routine triggers a blocking write call for the stream.<p>
In general, one should call the <a class="el" href="classRtAudio.html#a14">RtAudio::stopStream()</a> and <a class="el" href="classRtAudio.html#a12">RtAudio::closeStream()</a> methods after finishing with a stream. However, both methods will implicitly be called during object destruction if necessary.<h2><a class="anchor" name="playbackc">
Playback (callback functionality)</a></h2>
-The primary difference in using <a class="el" href="classRtAudio.html">RtAudio</a> with callback functionality involves the creation of a user-defined callback function. Here is an example
which produces a sawtooth waveform for playback.<p>
+The primary difference in using <a class="el" href="classRtAudio.html">RtAudio</a> with callback functionality involves the creation of a user-defined callback function. Here is an example
that produces a sawtooth waveform for playback.<p>
<div class="fragment"><pre class="fragment"><span class="preprocessor">#include <iostream></span>
<span class="preprocessor">#include "RtAudio.h"</span>
<span class="keywordflow">return</span> 0;
}
</pre></div><p>
-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 <a class="el" href="classRtAudio.html#a6">RtAudio::setStreamCallback()</a>. When the underlying audio API uses blocking calls (OSS, ALSA, SGI, and Windows DirectSound), this method will spawn a new process (or thread)
which 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 <a class="el" href="classRtAudio.html#a13">RtAudio::startStream()</a> and <a class="el" href="classRtAudio.html#a14">RtAudio::stopStream()</a> methods). The last argument to <a class="el" href="classRtAudio.html#a6">RtAudio::setStreamCallback()</a> is a pointer to arbitrary data that you wish to access from within your callback function.<p>
+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 <a class="el" href="classRtAudio.html#a6">RtAudio::setStreamCallback()</a>. 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 <a class="el" href="classRtAudio.html#a13">RtAudio::startStream()</a> and <a class="el" href="classRtAudio.html#a14">RtAudio::stopStream()</a> methods). The last argument to <a class="el" href="classRtAudio.html#a6">RtAudio::setStreamCallback()</a> is a pointer to arbitrary data that you wish to access from within your callback function.<p>
In this example, we stop the stream with an explicit call to <a class="el" href="classRtAudio.html#a14">RtAudio::stopStream()</a>. When using callback functionality, it is also possible to stop a stream by returning a non-zero value from the callback function.<p>
Once set with <a class="el" href="classRtAudio.html#a6">RtAudio::setStreamCallback</a>, the callback process exists for the life of the stream (until the stream is closed with <a class="el" href="classRtAudio.html#a12">RtAudio::closeStream()</a> or the <a class="el" href="classRtAudio.html">RtAudio</a> instance is deleted). It is possible to disassociate a callback function and cancel its process for an open stream using the <a class="el" href="classRtAudio.html#a7">RtAudio::cancelStreamCallback()</a> method. The stream can then be used with blocking functionality or a new callback can be associated with it.<h2><a class="anchor" name="recording">
Recording</a></h2>
<span class="keywordflow">goto</span> cleanup;
}
- <span class="comment">// An example loop which runs for about 40000 sample frames</span>
+ <span class="comment">// An example loop that runs for about 40000 sample frames</span>
count = 0;
<span class="keywordflow">while</span> (count < 40000) {
<p>
The example compiler statements above could be used to compile the <code>probe.cpp</code> example file, assuming that <code>probe.cpp</code>, <code><a class="el" href="RtAudio_8h-source.html">RtAudio.h</a></code>, <code><a class="el" href="RtError_8h-source.html">RtError.h</a></code>, and <code>RtAudio.cpp</code> all exist in the same directory.<h2><a class="anchor" name="debug">
Debugging</a></h2>
-If you are having problems getting <a class="el" href="classRtAudio.html">RtAudio</a> to run on your system, try passing the preprocessor definition <code>__RTAUDIO_DEBUG__</code> to the compiler (or uncomment the definition at the bottom of <a class="el" href="RtAudio_8h-source.html">RtAudio.h</a>). A variety of warning messages will be displayed
which may help in determining the problem. Also try using the programs included in the <code>test</code> directory. The program <code>info</code> displays the queried capabilities of all hardware devices found.<h2><a class="anchor" name="apinotes">
+If you are having problems getting <a class="el" href="classRtAudio.html">RtAudio</a> to run on your system, try passing the preprocessor definition <code>__RTAUDIO_DEBUG__</code> to the compiler (or uncomment the definition at the bottom of <a class="el" href="RtAudio_8h-source.html">RtAudio.h</a>). A variety of warning messages will be displayed
that may help in determining the problem. Also try using the programs included in the <code>test</code> directory. The program <code>info</code> displays the queried capabilities of all hardware devices found.<h2><a class="anchor" name="apinotes">
API Notes</a></h2>
<a class="el" href="classRtAudio.html">RtAudio</a> is designed to provide a common API across the various supported operating systems and audio libraries. Despite that, some issues should be mentioned with regard to each.<h3><a class="anchor" name="linux">
Linux:</a></h3>
<a class="el" href="classRtAudio.html">RtAudio</a> for Linux was developed under Redhat distributions 7.0 - Fedora. Three different audio APIs are supported on Linux platforms: OSS, <a href="http://www.alsa-project.org/">ALSA</a>, and <a href="http://jackit.sourceforge.net/">Jack</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 (though the availability and quality of OSS drivers for new hardware is decreasing). The ALSA API, although relatively new, is now part of the Linux development kernel and offers significantly better functionality than the OSS API. <a class="el" href="classRtAudio.html">RtAudio</a> provides support for the 1.0 and higher versions of ALSA. Jack, which is still in development, is a low-latency audio server, written primarily for the GNU/Linux operating system. It can connect a number of different applications to an audio device, as well as allow them to share audio between themselves. Input/output latency on the order of 15 milliseconds can typically be achieved using any of the Linux APIs by fine-tuning the <a class="el" href="classRtAudio.html">RtAudio</a> 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.<p>
-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 <a class="el" href="classRtAudio.html">RtAudio</a> tests, it is recommended that the native ALSA implementation of <a class="el" href="classRtAudio.html">RtAudio</a> be used on systems
which have ALSA drivers installed.<p>
+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 <a class="el" href="classRtAudio.html">RtAudio</a> tests, it is recommended that the native ALSA implementation of <a class="el" href="classRtAudio.html">RtAudio</a> be used on systems
that have ALSA drivers installed.<p>
The ALSA implementation of <a class="el" href="classRtAudio.html">RtAudio</a> makes no use of the ALSA "plug" interface. All necessary data format conversions, channel compensation, de-interleaving, and byte-swapping is handled by internal <a class="el" href="classRtAudio.html">RtAudio</a> routines.<p>
The Jack API is based on a callback scheme. <a class="el" href="classRtAudio.html">RtAudio</a> 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 <a class="el" href="classRtAudio.html">RtAudio</a> instance can be connected to the Jack server. Because <a class="el" href="classRtAudio.html">RtAudio</a> does not provide a mechanism for allowing the user to specify particular channels (or ports) of a device, it simply opens the first <em>N</em> enumerated Jack ports for input/output.<h3><a class="anchor" name="macosx">
Macintosh OS X (CoreAudio):</a></h3>
Irix (SGI):</a></h3>
The Irix version of <a class="el" href="classRtAudio.html">RtAudio</a> was written and tested on an SGI Indy running Irix version 6.5.4 and the newer "al" audio library. <a class="el" href="classRtAudio.html">RtAudio</a> does not compile under Irix version 6.3, mainly because the C++ compiler is too old. Despite the relatively slow speed of the Indy, <a class="el" href="classRtAudio.html">RtAudio</a> was found to behave quite well and input/output latency was very good. No problems were found with respect to using the pthread library.<h3><a class="anchor" name="windowsds">
Windows (DirectSound):</a></h3>
-In order to compile <a class="el" href="classRtAudio.html">RtAudio</a> under Windows for the DirectSound API, 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. 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 crashes. <a class="el" href="classRtAudio.html">RtAudio</a> was originally developed with Visual C++ version 6.0.<h3><a class="anchor" name="windowsasio">
+In order to compile <a class="el" href="classRtAudio.html">RtAudio</a> under Windows for the DirectSound API, 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. Audio output latency with DirectSound can be reasonably good, especially since <a class="el" href="classRtAudio.html">RtAudio</a> version 3.0.2. Input audio latency still tends to be bad but better since version 3.0.2. <a class="el" href="classRtAudio.html">RtAudio</a> was originally developed with Visual C++ version 6.0 but has been tested with .NET.<p>
+The DirectSound version of <a class="el" href="classRtAudio.html">RtAudio</a> can be compiled with or without the UNICODE preprocessor definition.<h3><a class="anchor" name="windowsasio">
Windows (ASIO):</a></h3>
The Steinberg ASIO audio API is based on a callback scheme. In addition, the API allows only a single device driver to be loaded and accessed at a time. ASIO device drivers must be supplied by audio hardware manufacturers, though ASIO emulation is possible on top of systems with DirectSound drivers. The <em>numberOfBuffers</em> parameter to the <a class="el" href="classRtAudio.html#a4">RtAudio::openStream()</a> function has no affect in this implementation.<p>
-A number of ASIO source and header files are required for use with <a class="el" href="classRtAudio.html">RtAudio</a>. Specifically, an <a class="el" href="classRtAudio.html">RtAudio</a> project must include the following files: <code>asio.h,cpp; asiodrivers.h,cpp; asiolist.h,cpp; asiodrvr.h; asiosys.h; ginclude.h; iasiodrv.h</code>. The Visual C++ projects found in <code>/tests/Windows/</code> compile both ASIO and DirectSound support.<h2><a class="anchor" name="wishlist">
+A number of ASIO source and header files are required for use with <a class="el" href="classRtAudio.html">RtAudio</a>. Specifically, an <a class="el" href="classRtAudio.html">RtAudio</a> project must include the following files: <code>asio.h,cpp; asiodrivers.h,cpp; asiolist.h,cpp; asiodrvr.h; asiosys.h; ginclude.h; iasiodrv.h; iasiothiscallresolver.h,cpp</code>. The Visual C++ projects found in <code>/tests/Windows/</code> compile both ASIO and DirectSound support.<p>
+The Steinberg provided <code>asiolist</code> class does not compile when the preprocessor definition UNICODE is defined. Note that this could be an issue when using <a class="el" href="classRtAudio.html">RtAudio</a> with Qt, though Qt programs appear to compile without the UNICODE definition (try <code>DEFINES -= UNICODE</code> in your .pro file). <a class="el" href="classRtAudio.html">RtAudio</a> with ASIO support has been tested using the MinGW compiler under Windows XP, as well as in the Visual Studio environment.<h2><a class="anchor" name="wishlist">
Possible Future Changes</a></h2>
There are a few issues that still need to be addressed in future versions of <a class="el" href="classRtAudio.html">RtAudio</a>, including:<p>
<ul>
</ul>
<h2><a class="anchor" name="acknowledge">
Acknowledgements</a></h2>
-Thanks to Robin Davies for a number of bug fixes and improvements to the DirectSound and ASIO implementations in the 3.0.2 release!<p>
+Many thanks to the following people for providing bug fixes and improvements: <ul>
+<li>
+Robin Davies (Windows DS and ASIO) </li>
+<li>
+Ryan Williams (Windows non-MS compiler ASIO support) </li>
+<li>
+Ed Wildgoose (Linux ALSA and Jack) </li>
+</ul>
+<p>
The <a class="el" href="classRtAudio.html">RtAudio</a> 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.<p>
The early 2.0 version of <a class="el" href="classRtAudio.html">RtAudio</a> 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 <a class="el" href="classRtAudio.html">RtAudio</a> was finished while working as an assistant professor of <a href="http://www.music.mcgill.ca/musictech/">Music Technology</a> at <a href="http://www.mcgill.ca/">McGill University</a>. This work was supported in part by the United States Air Force Office of Scientific Research (grant #F49620-99-1-0293).<h2><a class="anchor" name="license">
License</a></h2>
projects / rtaudio.git / blobdiff