roc-toolkit: real-time audio streaming with a latency budget

A C library plus command line tools

Roc is described in one line as a toolkit for real-time audio streaming over the network, and the summary section says the toolkit consists of a C library and a set of command-line tools.

That split is the shape of the project. The library is the part you embed, and the command line tools are the part you use to try it, to move audio between machines, and to diagnose a session. There is no application here, and no framework, and the toolkit is meant to sit underneath something else.

The feature list is the real specification, and each item answers a specific problem in streaming audio across a network.

Real-time streaming with guaranteed latency. Restoring lost packets using Forward Erasure Correction codes. Converting between the sender and receiver clock domains. CD-quality audio. Multiple profiles for different CPU and latency requirements. Portability. And relying on open, standard protocols.

Two of those deserve emphasis because they are what separate this from a UDP socket. The guaranteed latency is a property of the transport rather than an aspiration, which means the system is designed around a budget rather than around best effort. And the clock domain conversion exists because two machines that do not share a clock will drift, and a stream that drifts accumulates latency until it breaks.

The project is MPL-2.0 licensed, the default branch is master, the site is roc-streaming.org, and the last push was on 2026-08-24. The newest release is v0.4.0 from 2024-06-14, with v0.3.0 from 2023-11-22 and v0.2.6 from 2023-11-05 before it.

Forward error correction and the clock domain problem

The two features that do the actual engineering work in a networked audio system are the packet loss recovery and the clock handling, and Roc treats both as first class.

Packet loss on a real network is not exceptional, it is normal, and a naive sender retransmits. That is the wrong tool for real-time audio, because a retransmitted packet arrives after the deadline that made it worth sending. Forward Erasure Correction codes solve this differently. The sender adds parity, the receiver can reconstruct a lost packet from the parity without asking for it, and the reconstruction happens in time to be played. The cost is bandwidth, and the profile system is how you choose how much.

The clock domain conversion is the other half. The sender's idea of when a sample was produced and the receiver's idea of when it should be played are not the same clock, and the two drift. Left alone, the receiver's buffer either grows or shrinks, and a growing buffer is a growing latency. Roc converts between the two domains so the latency stays where the profile says it should be.

Put together, these two features are the reason the toolkit can promise a latency guarantee rather than an average. A guarantee needs both, since a system that recovers packets but drifts its clock will still violate its budget over a long session, and a system that holds its clock but stalls on a lost packet will violate it on every loss.

The rest of the list, CD-quality audio, portability, open standard protocols, is what makes the result usable outside a lab. The ecosystem is described in the README as numerous projects built on top of the toolkit: language bindings in Go and Java, sound server modules for PipeWire, PulseAudio and macOS CoreAudio, and end-user applications.

Profiles, the sound server modules and the bindings

The practical decisions a user of the toolkit makes are about deployment rather than about the API, and the README routes each of them to a documentation page.

Profiles are the first. The key feature is multiple profiles for different CPU and latency requirements, and the project keeps a roadmap and a project board, so the set of profiles and their trade-offs are documented rather than left implicit. In a real deployment this is the knob you turn: a profile that recovers more aggressively spends CPU and bandwidth, and a profile that protects the latency budget spends less.

The sound server modules are the second. Modules exist for PipeWire, PulseAudio and macOS CoreAudio, which means Roc can be inserted into an existing desktop audio pipeline as a source or a sink rather than owning the audio device. That is the difference between a tool you can try and a tool you can ship inside a product.

The language bindings are the third, Go and Java, and they are what makes the C library usable from an application rather than only from C. The end-user applications are the layer above that, and the README links them without listing them, which is the right level of detail for a toolkit README.

The documentation structure follows the same logic. There is a documentation site for the latest release, separate Doxygen-generated documentation for the internal modules, and separate pages for the overview and the feature list, so a user looking for what the toolkit can do and a developer looking for the internals are served different documents.

Building from source and the shape of the repository

The README does not give a build command, and the repository layout tells you how the project expects to be built.

The build file is SConstruct, which means the project uses SCons rather than CMake or a plain Makefile. Alongside it there is a src/ directory for the code, a 3rdparty/ directory for bundled third party components, a .gitmodules file, a scripts/ directory, and packaging directories for both debian/ and rpm/. There is also a shell.nix, which is a Nix shell definition for development, and a .clang-format file, which tells you the project formats its C and C++ with clang-format.

The presence of debian/ and rpm/ directories is a signal about the audience. A toolkit that ships packaging for both major Linux distributions expects to be integrated into a distribution's own audio stack, or to be run on embedded systems, which the README explicitly points at with pages for cross-compiling and for tested devices.

The continuous integration is documented on its own page, and the README carries build badges for both master and develop, which is the usual two branch arrangement for a project with a stable line and a development line.

For a first use, the path the README points to is the command line tools rather than the library. The tools are the quickest way to see a stream running between two machines, and once the transport and the profiles behave the way you expect, the library is the part you embed.

Maintenance, licensing and the community around it

The maintenance record has two halves and they point in different directions.

The last push was on 2026-08-24, so the code is being worked on, and the repository has both a master and a develop branch with continuous integration on each. The published releases are older, with v0.4.0 from 2024-06-14 the newest, v0.3.0 from 2023-11-22 and v0.2.6 from 2023-11-05. The version history, the changelog and the development workflow each have their own documentation page, so the release record is not only in the tags.

For a project with a mature ecosystem around it, that gap matters, because the bindings and the sound server modules are versioned against a toolkit release, and a mismatch there is a real integration cost rather than a theoretical one.

The licensing page is linked separately, and the repository carries a LICENSE file, with the licence identified in the project metadata as MPL-2.0. The details of which files carry which terms, which is the kind of thing the linked licensing page exists to explain, are not spelled out in the README itself.

The project is run by volunteers in their free time, and the README says so directly, with a donation page and a GitHub Sponsors link. The community channels are a forum, a mailing list and a Matrix chat room, and contributions in any form are welcome, with the contribution guidelines and a label for tasks needing help.

Editorial conclusion

Adopt roc-toolkit if you are building something that moves audio across a network under a latency budget, and you want the packet loss recovery, the clock resynchronisation and the transport handling already solved rather than written from scratch. Do not adopt it for offline file transfer, for a one off local playout, or if you need a codec suite or a container format, since the toolkit is a streaming engine rather than a media toolchain. Verify first which profile fits your CPU and latency targets, that the sound server module you need exists for your platform, and that the release you pick, v0.4.0 from 2024-06-14 is the one the surrounding ecosystem expects.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. roc-streaming/roc-toolkit on GitHub