This one implements a tool (both CLI and GUI) for measuring audio latency and glitches.
The idea behind the tool is simple: you have an audio loopback that connects audio output to audio input; the tool writes impulses to the output, waits until the same impulses are received from the input, and measures the delay or other properties.
I’m using this tool at work for measuring latency of various audio software. Here is an example of a real-world usage, a test bench for measuring latency of audio streaming between two boards over Ethernet:
The project is written in modern C++ and has rather small code base. There are issues needing help related to project core (audio I/O, algorithms), command-line interface, and graphical interface (it uses Qt).
Real-time tests for Roc Toolkit
The project is in its infancy and is waiting for someone who will help it grow. Its goal is to implement real-time test suite for Roc Toolkit, a library for audio streaming.
Roc implements various features essential for real-time streaming: maintaining guaranteed latency, packet loss recovery, clock drift compensation, and others. You can find some interesting overview in my old post.
Roc already has unit and integration tests, but those tests, by design, have limitations:
- they are run frequently during development, so they should not take long
- they are run everywhere (on developer machine, on CI), so should not be sensitive to real-time (e.g. tests should pass even on loaded machine like CI VM worker)
- they are yes/no tests, i.e. should either succeed or fail
The idea of the new project is to develop a different kind of tests:
- running on real hardware on unloaded system
- running long if needed
- providing some metrics, not just success or failure
- testing various real-time aspects of the toolkit, for example latency, number of glitches, etc
Currently, the project has a build system, and a skeleton of one test that implement full loopback: writes audio stream to roc sender, obtains the stream from roc receiver, and runs a very basic check.
I’ve prepared a bunch of issues explaining details of futher tests that need to be developed. Current test skeleton is written in C++17 with the use of Google Test.
What is beginner-friendly?
By saying that, I basically mean two things:
- The code base is small. You can dive into it rather quickly.
- I’ll be happy to provide code review.
Both projects has tasks of different levels of difficulty.
To contribute, one still needs to have basic knowledge of modern C++ and be ready to dig into the code base and do some testing and experimenting :)