# RtAudio: a common C++ API for realtime audio I/O

> RtAudio gives C++ applications one API for realtime audio input and output across major desktop audio backends. It suits projects that need backend selection, device probing, dynamic device connection, and conversion work without maintaining separate platform implementations.

**thestk/rtaudio** — A set of C++ classes that provide a common API for realtime audio input/output across Linux (native ALSA, JACK, PulseAudio and OSS), Macintosh OS X (CoreAudio and JACK), and Windows (DirectSound, ASIO, and WASAPI) operating systems.

- Repository: https://github.com/thestk/rtaudio
- Stars: 1,774 · Forks: 369
- Language: C++
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/thestk-rtaudio

## Why RtAudio is useful for portable C++ audio

RtAudio solves a specific portability problem. A C++ program that opens a microphone, renders playback, or moves audio between hardware can otherwise need separate integration work for each operating system and audio service. The project provides a common API for realtime audio input and output, while retaining platform-specific APIs where that distinction is necessary.

The documented backends include native ALSA, JACK, PulseAudio, and OSS on Linux; CoreAudio and JACK on Macintosh OS X; and DirectSound, ASIO, and WASAPI on Windows. By default, all detected APIs are enabled. This matters because the application can choose an API when creating an `RtAudio` instance, rather than treating the platform as an all-or-nothing environment. A project can therefore support more than one route to audio on systems where those APIs are present.

The intended audience is C++ developers building applications or components that need direct control over realtime streams. RtAudio is not a high-level media framework. It does not present a playlist, a timeline, or a complete recording application in the README. It sits closer to the device and callback layer, which makes it suitable for music software, signal-processing tools, and other programs that need to manage audio streams themselves.

## Streams, callbacks, and conversion inside RtAudio

RtAudio models an audio stream as either output, input, or both. Applications can enumerate available devices and inspect their capabilities, then select a device and open a stream with parameters appropriate to that hardware. The API is designed to let the application discover what is available instead of assuming that every machine has the same input or output configuration.

The library also describes support for dynamic connection of devices and extensive audio device parameter control. Those are meaningful features for realtime applications, where device availability and supported formats can vary between machines. The README does not document the full callback signature or a complete application example, so the precise callback lifecycle should be taken from `doc/html/index.html` and the examples under `tests/` rather than inferred from this overview.

RtAudio performs internal conversion for data format, channel count compensation, interleaving and deinterleaving, and byte swapping where applicable. This does not mean that every application can ignore channel layout. The project's own FAQ says that a one-channel stream is not automatically expanded to stereo. If an application needs monophonic data sent to both channels of a stereo output, it should open a two-channel stream and copy the sample to both channels in its audio stream callback. That limitation is useful to know because automatic channel conversion can change the behavior expected by code written for a particular device configuration.

## Building RtAudio with CMake, Meson, or autotools

The repository documents several build systems. CMake is a direct choice when the application already keeps out-of-source build directories. The documented sequence creates a `build` directory, enters it, runs the repository's CMake script, and then builds the project.

```bash
mkdir build; cd build; ../cmake; make
```

After a successful build, the reader should have the build artifacts produced by the repository's CMake configuration. The README directs users to `install.txt` for selecting an audio backend API. That file is the relevant place to check because the default enables all APIs detected during configuration. The README also says that the autotools route is recommended for packaging.

For a Git checkout, the documented autotools sequence is:

```bash
./autogen.sh; make
```

For a tarball release, it is:

```bash
./configure; make
```

Meson is also supported:

```bash
meson build; cd build; ninja
```

The repository includes `CMakeLists.txt`, `Makefile.am`, `configure.ac`, and `meson.build`, so the build choice is visible in the source tree rather than being limited to one package recipe. The vcpkg route is documented as `./bootstrap-vcpkg.sh; ./vcpkg integrate install; ./vcpkg install rtaudio`. The README does not give a platform-specific package installation command or a concrete first callback program, so those details should come from `install.txt`, `doc/html/index.html`, and `tests/`.

## Adding RtAudio to a C++ project

RtAudio is deliberately packaged for direct inclusion. The README describes it as a single `.cpp` file and `.h` file, with those files also being the source and header needed for compilation. This can be convenient for a small C++ application that wants the library in its own repository rather than relying on a system package.

The practical first use is to configure the build with the desired backend flags, add the RtAudio source and header to the application build, and then use the documentation to enumerate devices before opening a stream. The repository contains `rtaudio_c.cpp` and `rtaudio_c.h` as well, indicating an additional C interface, but the README's overview focuses on the C++ classes and does not provide instructions for using that interface. It also documents an optional module enabled with `RTAUDIO_BUILD_MODULES` and imported with `import rt.audio;`. Namespace exposure can be controlled with `RTAUDIO_USE_NAMESPACE`, according to the README.

The first implementation decision is therefore backend scope. Enabling all detected APIs can simplify portability, but it also means the build and deployment need to account for the headers, libraries, services, or drivers required by those APIs. A developer who wants direct ALSA access on Linux should consult `install.txt` before building rather than assuming that the default configuration matches the desired backend.

## Limits of the common abstraction

The main limitation is that a common API cannot remove every backend difference. RtAudio exposes device capabilities and backend selection, but applications still need to interpret those capabilities correctly. A stream configured for one channel will not necessarily produce the duplicated stereo behavior that a user expects. The README addresses this as an explicit design choice because one-channel output can be intentional.

Another limitation is visible in the licensing record. The repository's license field is classified as Other, and the README says the license is similar to the MIT License while directing readers to `LICENSE`. That is enough to identify the licensing document, but not enough to make a legal determination about redistribution or integration in a particular product. The license file itself should be reviewed before shipping a commercial or closed-source application.

The project is also a low-level C++ library, not a complete audio application framework. If the required product features include automatic recording management, effects hosting, file-based editing, transport control, or a managed package environment, those responsibilities remain outside what this README describes. The alternative approach may be to use a higher-level audio framework or platform-specific audio code, accepting a narrower portability target in exchange for a broader feature set.

## RtAudio versus platform-specific audio integrations

RtAudio differs from writing direct integrations for ALSA, CoreAudio, WASAPI, or ASIO because it places those implementations behind one C++ API. The application can use the same core stream concept while selecting or compiling for supported APIs. Device enumeration, capability probing, and internal format or channel handling are part of the abstraction described by the project.

A platform-specific implementation can expose details that the common interface does not foreground. That may be preferable when an application depends on one audio stack's advanced features or needs to control a particular driver closely. The trade-off is portability: separate code paths increase maintenance and make behavior more likely to diverge across operating systems.

Another practical alternative is a higher-level audio library that sits above RtAudio or uses a different abstraction entirely. Such a library may reduce callback and device-management code, but it can also add assumptions about buffers, formats, or event handling. RtAudio is the better fit when direct stream control and a small C++ integration surface matter more than a complete application framework. The repository's `tests/` directory is the relevant place to inspect the intended examples before choosing between those designs.

## Maintenance and release considerations

The repository is not archived, and its last push was on 2026-10-16. The listed releases include 6.0.1 from 2023-08-01, 6.0.0 from 2023-07-21, and 5.2.0 from 2021-11-16. That information shows the available release history, but the README does not document a support policy, compatibility matrix, or upgrade procedure for older applications.

Because the project is a native C++ library, adoption also brings native build considerations. A team must account for the target compiler, C++ toolchain, audio backend dependencies, and platform headers. The repository supports several build systems, which helps match different packaging environments, but that variety does not remove the need to test the resulting binary on each supported operating system.

The custom license classification should be handled as an adoption gate. The README's statement that the license is similar to the MIT License is not a substitute for reading `LICENSE`. Likewise, the release list does not by itself confirm compatibility with a particular application framework or driver version. The concrete upgrade information available here is the release history and build options; any migration notes beyond those require checking the repository's documentation.

## Conclusion

RtAudio is a good fit for C++ applications that need one realtime audio interface across Linux, macOS, and Windows, especially when device discovery and backend conversion matter. It is less suitable for a project that needs a high-level playback library, a complete audio workstation, or a maintained Python audio stack. Before adoption, verify the backend selected on each target system, the device parameters required by the application, and the custom licensing terms in `LICENSE`.

## FAQ

### Which audio backends does RtAudio support?

On Linux, the README lists ALSA, JACK, PulseAudio, and OSS. On Macintosh OS X it lists CoreAudio and JACK, while Windows support includes DirectSound, ASIO, and WASAPI. The default build enables all detected APIs.

### How do I build RtAudio with CMake?

The README documents `mkdir build; cd build; ../cmake; make` as the CMake build sequence. It also points to `install.txt` for selecting audio backend APIs.

### Why does one-channel RtAudio output not duplicate audio to both stereo channels?

RtAudio does not automatically turn one-channel output into stereo because one-channel behavior can be intentional. For duplicated stereo output, open a two-channel stream and copy the sample to both channels in the audio stream callback.

## Sources

- [Issues](https://github.com/thestk/rtaudio/issues)
- [README](https://github.com/thestk/rtaudio/blob/master/README.md)
- [Releases](https://github.com/thestk/rtaudio/releases)
- [thestk/rtaudio on GitHub](https://github.com/thestk/rtaudio)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/thestk-rtaudio