Roc: A new network transport for PulseAudio and ALSA

Roc – Real-time streaming over the network

image
https://roc-project.github.io/

Introduction

Looks like Mikhail Baranov (https://www.tarabah.me/) and Victor Gaydov are building something reasonable here. Thanks and cheers!


via: Show HN: Working on a new network transport for PulseAudio and ALSA | Hacker News

Screenshots

Roc doing packet recovery on a noisy channel.

Synopsis

Author summary

Summary of technical details

Roc implements FECFRAME, which provides forward error correction codes (FEC) like Reed–Solomon and Low-density parity-check to applications in public and private IP networks in order to protect arbitrary packet flows over unreliable transports against packet loss and is primarily intended for realtime- or streaming-media.

Does that sound cool already? Roc did not stop at implementing the FEC Framework conceived by OpenFEC and turtles all the way down to RFC 3550, RFC 3551, RFC 6363, RFC 6865, RFC 6816 to provide forward error correction schemes as transports to the Real-time Transport Protocol (RTP) – it also closes the gap to PulseAudio and ALSA already.

Project and documentation

Features

Impressive. Via About project — Roc 0.1 documentation. See also the project roadmap.


The Roc toolkit consists of:

  • a C library ( docs );
  • a set of command-line tools ( docs );
  • a set of PulseAudio modules ( docs ).

Supported features:

  • real-time streaming with guaranteed latency;
  • serving multiple network ports and mixing multiple simultaneous sessions at the receiver;
  • converting between the sender and receiver clock domains ( docs );
  • converting between the network and sound-card sample rates;
  • restoring lost packets using Forward Erasure Correction codes ( docs );
  • interleaving packets to increase chances of successfull restoring;
  • detecting stream breakages.

Supported network protocols ( docs ):

  • RTP
  • FECFRAME (FEC Framework for RTP)

Supported audio encodings:

  • RTP AVP L16 (PCM 16-bit stereo)

Supported FEC schemes ( docs ):

  • Reed-Solomon (lower latency, lower rates)
  • LDPC-Staircase (higher latency, higher rates)

Supported resampler profiles:

  • low quality / high speed
  • medium quality / medium speed
  • high quality / low speed

Supported platforms ( docs ):

  • GNU/Linux (tested on x64_64 and ARM)
  • macOS

Background information and OpenFEC

TLDR;

Apply Reed–Solomon and low-density parity-check error correction codes to the Real-time Transport Protocol (RTP).

Introduction

The new transport seems to be based on Application-Level Forward Erasure Correction codes (AL-FEC, also called UL-FEC, for Upper-Layers FEC).

The following information is from the OpenFEC project, which obviously is aiming towards applying reasonable things from the Error correction code - Wikipedia domain to improve media transport over flaky networks. Besides researching it, they are trying to get their codes, associated protocols and applications standardized to enable interoperability.

Remark

The main activity of this WG related to research, standardization and reference implementations seems to have happened between 2000 and 2013.

FECs?

In a nutshell

The idea, in one line, is to add redundancy in order to be able to recover from erasures. Because of their position in the communication stack, these codes are implemented as software codecs, and they find many applications in robust transmission and distributed storage systems.

http://openfec.org/

AL-FEC in short

AL-FEC (A.K.A. UL-FEC) codes are critical to many applications. Their goal is to recover from symbol erasures (rather than errors): a symbol either arrives without any error or is altogether lost. This is why we say they work on a symbol erasure channel. Depending on the target use-case, a symbol can either be:

  • a bit (as with physical layer codes)
  • a byte (e.g. in the DVB MPE-FEC/MPE-IFEC MAC layer),
  • a packet payload that is several hundreds of byte long (e.g. a UDP datagram payload),
  • or a file chunk (e.g. with distributed storage applications).

The coding principles remain the same, even if codes are not used exactly in the same way.

Being implemented in higher layers (compared to physical layer codes), they benefit from many simplifications:

  • they are usually implemented in software codecs, using the host memory for symbol storage;
  • they often integrate the application constraints and the codes can often be produced dynamically, just on time, with the exact encoding block size and redundancy amount needed. Adding a large amount of redundant data is even meaningful with some use-cases.

OpenFEC.org – AL-FEC documents

Outlook in retrospect

Standardization activities

The people from OpenFEC are actively participating to IETF standardization activities for the codes as well as the associated protocols and applications.

Currently, there are two tracks where the efforts of this WG have been folded into:

  • Reliable Multicast Transport (RMT)
  • FEC Framework (FECFRAME) ¹

¹ This is a major asset since it warrants a high level of maturity to some code specifications, it enables interoperable implementations, and it specifies all the details for their use in actual use-cases (currently with both file distribution and real-time streaming applications).

When coming back and relating this to the maturing Roc implementation, we find the following status what Roc currently is implementing.

Bottom line

Some of us might remember error correcting codes from university, some others might actually be using them directly but many of us are mostly unaware about their implementations and what they provide to the robustness of our collective digital infrastructure all over the place.

While it is common practice to run machines on ECC memory - Wikipedia already ¹, we are happy to see how error correcting codes are being applied to improve the robustness of media transports over unreliable networks.


¹ You might also enjoy Re: Memory errors / ECC memory vs. cosmic rays which is somehow related and funny to read.

while still pretty amazing,

for PulseAudio and ALSA

…and not GStreamer:

Bindings

  • ☐ Bindings for other languages (maybe)
  • ☐ GStreamer modules (maybe)

…but let’s see how that project is going on!

1 Like

Victor Gaydov published a well-written article about his research into PulseAudio the other day which gives a good introduction to many details around it.

It has been written while PulseAudio 11.x was a thing. As we are having PulseAudio 12.x now, hopefully not many things have changed completely.


PulseAudio under the hood | Hacker News
PulseAudio Under the Hood (2017) | Hacker News

News

Version 0.1.2 of Roc was just released a few hours ago, enjoy the Changelog — Roc 0.1.2 documentation.