doc/doxygen/tutorial.txt

   1 /*! \mainpage The RtAudio Tutorial
   2
   3 <BODY BGCOLOR="white">
   4
   5 <CENTER>\ref intro &nbsp;&nbsp; \ref changes &nbsp;&nbsp;\ref download &nbsp;&nbsp; \ref start &nbsp;&nbsp; \ref error &nbsp;&nbsp; \ref probing &nbsp;&nbsp; \ref settings &nbsp;&nbsp; \ref playbackb &nbsp;&nbsp; \ref playbackc &nbsp;&nbsp; \ref recording &nbsp;&nbsp; \ref duplex &nbsp;&nbsp; \ref multi &nbsp;&nbsp; \ref methods &nbsp;&nbsp; \ref compiling &nbsp;&nbsp; \ref debug &nbsp;&nbsp; \ref apinotes &nbsp;&nbsp; \ref acknowledge &nbsp;&nbsp; \ref license</CENTER>
   6
   7 \section intro Introduction
   8
   9 RtAudio is a set of C++ classes which provide a common API (Application Programming Interface) for realtime audio input/output across Linux (native ALSA, JACK, and OSS), Macintosh OS X, SGI, and Windows (DirectSound and ASIO) operating systems.  RtAudio significantly simplifies the process of interacting with computer audio hardware.  It was designed with the following goals:
  10
  11 <UL>
  12   <LI>object oriented C++ design</LI>
  13   <LI>simple, common API across all supported platforms</LI>
  14   <LI>only two header files and one source file for easy inclusion in programming projects</LI>
  15   <LI>allow simultaneous multi-api support</LI>
  16   <LI>blocking functionality</LI>
  17   <LI>callback functionality</LI>
  18   <LI>extensive audio device parameter control</LI>
  19   <LI>audio device capability probing</LI>
  20   <LI>automatic internal conversion for data format, channel number compensation, de-interleaving, and byte-swapping</LI>
  21 </UL>
  22
  23 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 \ref apinotes section for information specific to each of the supported audio APIs.
  24
  25 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.
  26
  27 \section changes What's New (Version 3.0)
  28
  29 RtAudio now allows simultaneous multi-api support.  For example, you can compile RtAudio to provide both DirectSound and ASIO support on Windows platforms or ALSA, JACK, and OSS support on Linux platforms.  This was accomplished by creating an abstract base class, RtApi, with subclasses for each supported API (RtApiAlsa, RtApiJack, RtApiOss, RtApiDs, RtApiAsio, RtApiCore, and RtApiAl).  The class RtAudio is now a "controller" which creates an instance of an RtApi subclass based on the user's API choice via an optional RtAudio::RtAudioApi instantiation argument.  If no API is specified, RtAudio attempts to make a "logical" API selection.
  30
  31 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.
  32
  33 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).
  34
  35 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.
  36
  37 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).
  38
  39 \section download Download
  40
  41 Latest Release (22 March 2004): <A href="http://music.mcgill.ca/~gary/rtaudio/release/rtaudio-3.0.1.tar.gz">Version 3.0.1 (200 kB tar/gzipped)</A>
  42
  43 \section start Getting Started
  44
  45 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, RtAudio attempts to select the most "logical" available API).
  46
  47 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:
  48
  49 \code
  50
  51 #include "RtAudio.h"
  52
  53 int main()
  54 {
  55   RtAudio *audio;
  56
  57   // Default RtAudio constructor
  58   try {
  59     audio = new RtAudio();
  60   }
  61   catch (RtError &error) {
  62     // Handle the exception here
  63     error.printMessage();
  64   }
  65
  66   // Clean up
  67   delete audio;
  68 }
  69 \endcode
  70
  71 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.
  72
  73
  74 \section error Error Handling
  75
  76 RtAudio uses a C++ exception handler called RtError, which is declared and defined in RtError.h.  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 a driver error occurs or a stream function is called when no stream is open.  There are a number of cases within RtAudio where warning messages may be displayed but an exception is not thrown.  There is a protected RtAudio 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 RtAudio unless the preprocessor definition __RTAUDIO_DEBUG__ is defined.  Messages associated with caught exceptions can be displayed with, for example, the RtError::printMessage() function.
  77
  78
  79 \section probing Probing Device Capabilities
  80
  81 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.
  82
  83 \code
  84
  85 // probe.cpp
  86
  87 #include <iostream>
  88 #include "RtAudio.h"
  89
  90 int main()
  91 {
  92   RtAudio *audio;
  93
  94   // Default RtAudio constructor
  95   try {
  96     audio = new RtAudio();
  97   }
  98   catch (RtError &error) {
  99     error.printMessage();
 100     exit(EXIT_FAILURE);
 101   }
 102
 103   // Determine the number of devices available
 104   int devices = audio->getDeviceCount();
 105
 106   // Scan through devices for various capabilities
 107   RtAudioDeviceInfo info;
 108   for (int i=1; i<=devices; i++) {
 109
 110     try {
 111       info = audio->getDeviceInfo(i);
 112     }
 113     catch (RtError &error) {
 114       error.printMessage();
 115       break;
 116     }
 117
 118     // Print, for example, the maximum number of output channels for each device
 119     std::cout << "device = " << i;
 120     std::cout << ": maximum output channels = " << info.outputChannels << "\n";
 121   }
 122
 123   // Clean up
 124   delete audio;
 125
 126   return 0;
 127 }
 128 \endcode
 129
 130 The RtAudioDeviceInfo structure is defined in RtAudio.h and provides a variety of information useful in assessing the capabilities of a device:
 131
 132 \code
 133   typedef struct RtAudioDeviceInfo{
 134     std::string name;             // Character string device identifier.
 135     bool probed;                  // true if the device capabilities were successfully probed.
 136     int outputChannels;           // Maximum output channels supported by device.
 137     int inputChannels;            // Maximum input channels supported by device.
 138     int duplexChannels;           // Maximum simultaneous input/output channels supported by device.
 139     bool isDefault;               // true if this is the default output or input device.
 140     std::vector<int> sampleRates; // Supported sample rates.
 141     RtAudioFormat nativeFormats;  // Bit mask of supported data formats.
 142   };
 143 \endcode
 144
 145 The following data formats are defined and fully supported by RtAudio:
 146
 147 \code
 148   typedef unsigned long RtAudioFormat;
 149   static const RtAudioFormat  RTAUDIO_SINT8;   // Signed 8-bit integer
 150   static const RtAudioFormat  RTAUDIO_SINT16;  // Signed 16-bit integer
 151   static const RtAudioFormat  RTAUDIO_SINT24;  // Signed 24-bit integer (upper 3 bytes of 32-bit signed integer.)
 152   static const RtAudioFormat  RTAUDIO_SINT32;  // Signed 32-bit integer
 153   static const RtAudioFormat  RTAUDIO_FLOAT32; // 32-bit float normalized between +/- 1.0
 154   static const RtAudioFormat  RTAUDIO_FLOAT64; // 64-bit double normalized between +/- 1.0
 155 \endcode
 156
 157 The <I>nativeFormats</I> member of the RtAudioDeviceInfo 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 RtAudioDeviceInfo structure is false, the remaining structure members are undefined and the device is probably unuseable.
 158
 159 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 <I>NOT</I> possible when the number of channels set by the user is greater than that supported by the device.
 160
 161 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.
 162
 163
 164 \section settings Device Settings
 165
 166 The next step in using RtAudio is to open a stream with particular device and parameter settings.
 167
 168 \code
 169
 170 #include "RtAudio.h"
 171
 172 int main()
 173 {
 174   int channels = 2;
 175   int sampleRate = 44100;
 176   int bufferSize = 256;  // 256 sample frames
 177   int nBuffers = 4;      // number of internal buffers used by device
 178   int device = 0;        // 0 indicates the default or first available device
 179   RtAudio *audio;
 180
 181   // Instantiate RtAudio and open a stream within a try/catch block
 182   try {
 183     audio = new RtAudio();
 184   }
 185   catch (RtError &error) {
 186     error.printMessage();
 187     exit(EXIT_FAILURE);
 188   }
 189
 190   try {
 191     audio->openStream(device, channels, 0, 0, RTAUDIO_FLOAT32,
 192                       sampleRate, &bufferSize, nBuffers);
 193   }
 194   catch (RtError &error) {
 195     error.printMessage();
 196     // Perhaps try other parameters?
 197   }
 198
 199   // Clean up
 200   delete audio;
 201
 202   return 0;
 203 }
 204 \endcode
 205
 206 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 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 \e ONLY (device = 1 specifies the first identified device, as reported by RtAudio::getDeviceInfo()).
 207
 208 RtAudio 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, RtAudio will automatically perform the necessary data format conversion.
 209
 210 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 (the <I>nBuffers</I> 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 <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 apinotes section for general guidelines.
 211
 212 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.
 213
 214
 215 \section playbackb Playback (blocking functionality)
 216
 217 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.
 218
 219 \code
 220 // playback.cpp
 221
 222 #include "RtAudio.h"
 223
 224 int main()
 225 {
 226   int count;
 227   int channels = 2;
 228   int sampleRate = 44100;
 229   int bufferSize = 256;  // 256 sample frames
 230   int nBuffers = 4;      // number of internal buffers used by device
 231   float *buffer;
 232   int device = 0;        // 0 indicates the default or first available device
 233   RtAudio *audio;
 234
 235   // Open a stream during RtAudio instantiation
 236   try {
 237     audio = new RtAudio(device, channels, 0, 0, RTAUDIO_FLOAT32,
 238                         sampleRate, &bufferSize, nBuffers);
 239   }
 240   catch (RtError &error) {
 241     error.printMessage();
 242     exit(EXIT_FAILURE);
 243   }
 244
 245   try {
 246     // Get a pointer to the stream buffer
 247     buffer = (float *) audio->getStreamBuffer();
 248
 249     // Start the stream
 250     audio->startStream();
 251   }
 252   catch (RtError &error) {
 253     error.printMessage();
 254     goto cleanup;
 255   }
 256
 257   // An example loop which runs for 40000 sample frames
 258   count = 0;
 259   while (count < 40000) {
 260     // Generate your samples and fill the buffer with bufferSize sample frames of data
 261     ...
 262
 263     // Trigger the output of the data buffer
 264     try {
 265       audio->tickStream();
 266     }
 267     catch (RtError &error) {
 268       error.printMessage();
 269       goto cleanup;
 270     }
 271
 272     count += bufferSize;
 273   }
 274
 275   try {
 276     // Stop and close the stream
 277     audio->stopStream();
 278     audio->closeStream();
 279   }
 280   catch (RtError &error) {
 281     error.printMessage();
 282   }
 283
 284  cleanup:
 285   delete audio;
 286
 287   return 0;
 288 }
 289 \endcode
 290
 291 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 <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.
 292
 293 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.
 294
 295 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.
 296
 297
 298 \section playbackc Playback (callback functionality)
 299
 300 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.
 301
 302 \code
 303
 304 #include <iostream>
 305 #include "RtAudio.h"
 306
 307 // Two-channel sawtooth wave generator.
 308 int sawtooth(char *buffer, int bufferSize, void *data)
 309 {
 310   int i, j;
 311   double *my_buffer = (double *) buffer;
 312   double *my_data = (double *) data;
 313
 314   // Write interleaved audio data.
 315   for (i=0; i<bufferSize; i++) {
 316     for (j=0; j<2; j++) {
 317       *my_buffer++ = my_data[j];
 318
 319       my_data[j] += 0.005 * (j+1+(j*0.1));
 320       if (my_data[j] >= 1.0) my_data[j] -= 2.0;
 321     }
 322   }
 323
 324   return 0;
 325 }
 326
 327 int main()
 328 {
 329   int channels = 2;
 330   int sampleRate = 44100;
 331   int bufferSize = 256;  // 256 sample frames
 332   int nBuffers = 4;      // number of internal buffers used by device
 333   int device = 0;        // 0 indicates the default or first available device
 334   double data[2];
 335   char input;
 336   RtAudio *audio;
 337
 338   // Open a stream during RtAudio instantiation
 339   try {
 340     audio = new RtAudio(device, channels, 0, 0, RTAUDIO_FLOAT64,
 341                         sampleRate, &bufferSize, nBuffers);
 342   }
 343   catch (RtError &error) {
 344     error.printMessage();
 345     exit(EXIT_FAILURE);
 346   }
 347
 348   try {
 349     // Set the stream callback function
 350     audio->setStreamCallback(&sawtooth, (void *)data);
 351
 352     // Start the stream
 353     audio->startStream();
 354   }
 355   catch (RtError &error) {
 356     error.printMessage();
 357     goto cleanup;
 358   }
 359
 360   std::cout << "\nPlaying ... press <enter> to quit.\n";
 361   std::cin.get(input);
 362
 363   try {
 364     // Stop and close the stream
 365     audio->stopStream();
 366     audio->closeStream();
 367   }
 368   catch (RtError &error) {
 369     error.printMessage();
 370   }
 371
 372  cleanup:
 373   delete audio;
 374
 375   return 0;
 376 }
 377 \endcode
 378
 379 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) 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 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.
 380
 381 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.
 382
 383 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.
 384
 385
 386 \section recording Recording
 387
 388 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:
 389
 390 \code
 391 // record.cpp
 392
 393 #include "RtAudio.h"
 394
 395 int main()
 396 {
 397   int count;
 398   int channels = 2;
 399   int sampleRate = 44100;
 400   int bufferSize = 256;  // 256 sample frames
 401   int nBuffers = 4;      // number of internal buffers used by device
 402   float *buffer;
 403   int device = 0;        // 0 indicates the default or first available device
 404   RtAudio *audio;
 405
 406   // Instantiate RtAudio and open a stream.
 407   try {
 408     audio = new RtAudio(&stream, 0, 0, device, channels,
 409                         RTAUDIO_FLOAT32, sampleRate, &bufferSize, nBuffers);
 410   }
 411   catch (RtError &error) {
 412     error.printMessage();
 413     exit(EXIT_FAILURE);
 414   }
 415
 416   try {
 417     // Get a pointer to the stream buffer
 418     buffer = (float *) audio->getStreamBuffer();
 419
 420     // Start the stream
 421     audio->startStream();
 422   }
 423   catch (RtError &error) {
 424     error.printMessage();
 425     goto cleanup;
 426   }
 427
 428   // An example loop which runs for about 40000 sample frames
 429   count = 0;
 430   while (count < 40000) {
 431
 432     // Read a buffer of data
 433     try {
 434       audio->tickStream();
 435     }
 436     catch (RtError &error) {
 437       error.printMessage();
 438       goto cleanup;
 439     }
 440
 441     // Process the input samples (bufferSize sample frames) that were read
 442     ...
 443
 444     count += bufferSize;
 445   }
 446
 447   try {
 448     // Stop the stream
 449     audio->stopStream();
 450   }
 451   catch (RtError &error) {
 452     error.printMessage();
 453   }
 454
 455  cleanup:
 456   delete audio;
 457
 458   return 0;
 459 }
 460 \endcode
 461
 462 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.
 463
 464
 465 \section duplex Duplex Mode
 466
 467 Finally, it is easy to use RtAudio for simultaneous audio input/output, or duplex operation.  In this example, we use a callback function and simply scale the input data before sending it back to the output.
 468
 469 \code
 470 // duplex.cpp
 471
 472 #include <iostream>
 473 #include "RtAudio.h"
 474
 475 // Pass-through function.
 476 int scale(char *buffer, int bufferSize, void *)
 477 {
 478   // Note: do nothing here for pass through.
 479   double *my_buffer = (double *) buffer;
 480
 481   // Scale input data for output.
 482   for (int i=0; i<bufferSize; i++) {
 483     // Do for two channels.
 484     *my_buffer++ *= 0.5;
 485     *my_buffer++ *= 0.5;
 486   }
 487
 488   return 0;
 489 }
 490
 491 int main()
 492 {
 493   int channels = 2;
 494   int sampleRate = 44100;
 495   int bufferSize = 256;  // 256 sample frames
 496   int nBuffers = 4;      // number of internal buffers used by device
 497   int device = 0;        // 0 indicates the default or first available device
 498   char input;
 499   RtAudio *audio;
 500
 501   // Open a stream during RtAudio instantiation
 502   try {
 503     audio = new RtAudio(device, channels, device, channels, RTAUDIO_FLOAT64,
 504                         sampleRate, &bufferSize, nBuffers);
 505   }
 506   catch (RtError &error) {
 507     error.printMessage();
 508     exit(EXIT_FAILURE);
 509   }
 510
 511   try {
 512     // Set the stream callback function
 513     audio->setStreamCallback(&scale, NULL);
 514
 515     // Start the stream
 516     audio->startStream();
 517   }
 518   catch (RtError &error) {
 519     error.printMessage();
 520     goto cleanup;
 521   }
 522
 523   std::cout << "\nRunning duplex ... press <enter> to quit.\n";
 524   std::cin.get(input);
 525
 526   try {
 527     // Stop and close the stream
 528     audio->stopStream();
 529     audio->closeStream();
 530   }
 531   catch (RtError &error) {
 532     error.printMessage();
 533   }
 534
 535  cleanup:
 536   delete audio;
 537
 538   return 0;
 539 }
 540 \endcode
 541
 542 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.
 543
 544 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.
 545
 546 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 <I>explicitly</I> control the calling order of the callback functions.
 547
 548
 549 \section multi Using Simultaneous Multiple APIs
 550
 551 Because support for each audio API is encapsulated in a specific RtApi subclass, it is possible to compile and instantiate multiple API-specific subclasses on a given operating system.  For example, one can compile both the RtApiDs and RtApiAsio classes on Windows operating systems by providing the appropriate preprocessor definitions, include files, and libraries for each.  In a run-time situation, one might first attempt to determine whether any ASIO device drivers exist.  This can be done by specifying the api argument RtAudio::WINDOWS_ASIO when attempting to create an instance of RtAudio.  If an RtError is thrown (indicating no available drivers), then an instance of RtAudio with the api argument RtAudio::WINDOWS_DS can be created.  Alternately, if no api argument is specified, RtAudio will first look for ASIO drivers and then DirectSound drivers (on Linux systems, the default API search order is Jack, Alsa, and finally OSS).  In theory, it should also be possible to have separate instances of RtAudio open at the same time with different underlying audio API support, though this has not been tested.  It is difficult to know how well different audio APIs can simultaneously coexist on a given operating system.  In particular, it is most unlikely that the same device could be simultaneously controlled with two different audio APIs.
 552
 553
 554 \section methods Summary of Methods
 555
 556 The following is a short summary of public methods (not including constructors and the destructor) provided by RtAudio:
 557
 558 <UL>
 559 <LI>RtAudio::openStream(): opens a stream with the specified parameters.</LI>
 560 <LI>RtAudio::setStreamCallback(): sets a user-defined callback function for the stream.</LI>
 561 <LI>RtAudio::cancelStreamCallback(): cancels a callback process and function for the stream.</LI>
 562 <LI>RtAudio::getDeviceCount(): returns the number of audio devices available.</LI>
 563 <LI>RtAudio::getDeviceInfo(): returns an RtAudioDeviceInfo structure for a specified device.</LI>
 564 <LI>RtAudio::getStreamBuffer(): returns a pointer to the stream buffer.</LI>
 565 <LI>RtAudio::tickStream(): triggers processing of input/output data for the stream (blocking).</LI>
 566 <LI>RtAudio::closeStream(): closes the stream (implicitly called during object destruction).</LI>
 567 <LI>RtAudio::startStream(): (re)starts the stream, typically after it has been stopped with either stopStream() or abortStream() or after first opening the stream.</LI>
 568 <LI>RtAudio::stopStream(): stops the stream, allowing any remaining samples in the queue to be played out and/or read in.  This does not implicitly call RtAudio::closeStream().</LI>
 569 <LI>RtAudio::abortStream(): stops the stream, discarding any remaining samples in the queue.  This does not implicitly call closeStream().</LI>
 570 </UL>
 571
 572
 573 \section compiling Compiling
 574
 575 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:
 576 <P>
 577
 578 <TABLE BORDER=2 COLS=5 WIDTH="100%">
 579 <TR BGCOLOR="beige">
 580   <TD WIDTH="5%"><B>OS:</B></TD>
 581   <TD WIDTH="5%"><B>Audio API:</B></TD>
 582   <TD WIDTH="5%"><B>C++ Class:</B></TD>
 583   <TD WIDTH="5%"><B>Preprocessor Definition:</B></TD>
 584   <TD WIDTH="5%"><B>Library or Framework:</B></TD>
 585   <TD><B>Example Compiler Statement:</B></TD>
 586 </TR>
 587 <TR>
 588   <TD>Linux</TD>
 589   <TD>ALSA</TD>
 590   <TD>RtApiAlsa</TD>
 591   <TD>__LINUX_ALSA__</TD>
 592   <TD><TT>asound, pthread</TT></TD>
 593   <TD><TT>g++ -Wall -D__LINUX_ALSA__ -o probe probe.cpp RtAudio.cpp -lasound -lpthread</TT></TD>
 594 </TR>
 595 <TR>
 596   <TD>Linux</TD>
 597   <TD>Jack Audio Server</TD>
 598   <TD>RtApiJack</TD>
 599   <TD>__LINUX_JACK__</TD>
 600   <TD><TT>jack, pthread</TT></TD>
 601   <TD><TT>g++ -Wall -D__LINUX_JACK__ -o probe probe.cpp RtAudio.cpp `pkg-config --cflags --libs jack` -lpthread</TT></TD>
 602 </TR>
 603 <TR>
 604   <TD>Linux</TD>
 605   <TD>OSS</TD>
 606   <TD>RtApiOss</TD>
 607   <TD>__LINUX_OSS__</TD>
 608   <TD><TT>pthread</TT></TD>
 609   <TD><TT>g++ -Wall -D__LINUX_OSS__ -o probe probe.cpp RtAudio.cpp -lpthread</TT></TD>
 610 </TR>
 611 <TR>
 612   <TD>Macintosh OS X</TD>
 613   <TD>CoreAudio</TD>
 614   <TD>RtApiCore</TD>
 615   <TD>__MACOSX_CORE__</TD>
 616   <TD><TT>pthread, stdc++, CoreAudio</TT></TD>
 617   <TD><TT>g++ -Wall -D__MACOSX_CORE__ -o probe probe.cpp RtAudio.cpp -framework CoreAudio -lpthread</TT></TD>
 618 </TR>
 619 <TR>
 620   <TD>Irix</TD>
 621   <TD>AL</TD>
 622   <TD>RtApiAl</TD>
 623   <TD>__IRIX_AL__</TD>
 624   <TD><TT>audio, pthread</TT></TD>
 625   <TD><TT>CC -Wall -D__IRIX_AL__ -o probe probe.cpp RtAudio.cpp -laudio -lpthread</TT></TD>
 626 </TR>
 627 <TR>
 628   <TD>Windows</TD>
 629   <TD>Direct Sound</TD>
 630   <TD>RtApiDs</TD>
 631   <TD>__WINDOWS_DS__</TD>
 632   <TD><TT>dsound.lib (ver. 5.0 or higher), multithreaded</TT></TD>
 633   <TD><I>compiler specific</I></TD>
 634 </TR>
 635 <TR>
 636   <TD>Windows</TD>
 637   <TD>ASIO</TD>
 638   <TD>RtApiAsio</TD>
 639   <TD>__WINDOWS_ASIO__</TD>
 640   <TD><I>various ASIO header and source files</I></TD>
 641   <TD><I>compiler specific</I></TD>
 642 </TR>
 643 </TABLE>
 644 <P>
 645
 646 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>, <tt>RtError.h</tt>, and <TT>RtAudio.cpp</TT> all exist in the same directory.
 647
 648 \section debug Debugging
 649
 650 If you are having problems getting RtAudio to run on your system, try passing the preprocessor definition <TT>__RTAUDIO_DEBUG__</TT> to the compiler (or uncomment the definition at the bottom of RtAudio.h).  A variety of warning messages will be displayed which may help in determining the problem.  Also try using the programs included in the <tt>test</tt> directory.  The program <tt>info</tt> displays the queried capabilities of all hardware devices found.
 651
 652 \section apinotes API Notes
 653
 654 RtAudio 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.
 655
 656 \subsection linux Linux:
 657
 658 RtAudio 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.  RtAudio 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 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.
 659
 660 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.
 661
 662 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.
 663
 664 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 <I>N</I> enumerated Jack ports for input/output.
 665
 666 \subsection macosx Macintosh OS X (CoreAudio):
 667
 668 The Apple CoreAudio API is based on a callback scheme.  RtAudio provides blocking functionality, in addition to callback functionality, within the context of that behavior.  CoreAudio is designed to use a separate callback procedure for each of its audio devices.  A single RtAudio duplex stream using two different devices is supported, though it cannot be guaranteed to always behave correctly because we cannot synchronize these two callbacks.  This same functionality might be achieved with better synchrony by creating separate instances of RtAudio for each device and making use of RtAudio blocking calls (i.e. RtAudio::tickStream()).  The <I>numberOfBuffers</I> parameter to the RtAudio::openStream() function has no affect in this implementation.
 669
 670 It is not possible to have multiple instances of RtAudio accessing the same CoreAudio device.
 671
 672 \subsection irix Irix (SGI):
 673
 674 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.
 675
 676 \subsection windowsds Windows (DirectSound):
 677
 678 In order to compile RtAudio 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.  RtAudio was originally developed with Visual C++ version 6.0.
 679
 680 \subsection windowsasio Windows (ASIO):
 681
 682 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 <I>numberOfBuffers</I> parameter to the RtAudio::openStream() function has no affect in this implementation.
 683
 684 A number of ASIO source and header files are required for use with RtAudio.  Specifically, an RtAudio project must include the following files: <TT>asio.h,cpp; asiodrivers.h,cpp; asiolist.h,cpp; asiodrvr.h; asiosys.h; ginclude.h; iasiodrv.h</TT>.  The Visual C++ projects found in <TT>/tests/Windows/</TT> compile both ASIO and DirectSound support.
 685
 686
 687 \section acknowledge Acknowledgements
 688
 689 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.
 690
 691 The early 2.0 version of 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 and the <A href="http://www.acoustics.hut.fi/">Laboratory of Acoustics and Audio Signal Processing</A> at the Helsinki University of Technology, Finland.  Much subsequent development happened while working at 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>.  The most recent version of RtAudio 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).
 692
 693 \section license License
 694
 695     RtAudio: a realtime audio i/o C++ classes<BR>
 696     Copyright (c) 2001-2004 Gary P. Scavone
 697
 698     Permission is hereby granted, free of charge, to any person
 699     obtaining a copy of this software and associated documentation files
 700     (the "Software"), to deal in the Software without restriction,
 701     including without limitation the rights to use, copy, modify, merge,
 702     publish, distribute, sublicense, and/or sell copies of the Software,
 703     and to permit persons to whom the Software is furnished to do so,
 704     subject to the following conditions:
 705
 706     The above copyright notice and this permission notice shall be
 707     included in all copies or substantial portions of the Software.
 708
 709     Any person wishing to distribute modifications to the Software is
 710     requested to send the modifications to the original developer so that
 711     they can be incorporated into the canonical version.
 712
 713     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 714     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 715     MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
 716     IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR
 717     ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
 718     CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
 719     WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 720
 721 */