[LAD] Simple sound server design

Olivier Guilyardi list at samalyse.com
Mon Dec 27 11:23:00 UTC 2010

Hello everyone,

I am trying to understand how a simple sound server could be implemented. I will
not necessarily develop this, but I'm trying to clarify my ideas.

As in JACK, it would allow clients to register, and their process callback to be
called with input and output buffers of a fixed size. The server would then mix
all output data provided by clients and pass the result to the audio hardware.
It would also read audio input from the hardware and dispatch it to the clients.

There wouldn't be any ports, routing, etc.. as provided by JACK. The main
purpose of a such server would be to allow several applications to record and
play audio, without them acquiring exclusive access the audio hardware. In this
regard it's similar to PulseAudio and many others.

The server itself could have a realtime thread for accessing audio. Therefore,
for a proof of concept, it could be developed on top of JACK. However, none of
the client could run in realtime: this is a given of my problem. The clients
would be standard applications, with very limited privileges. They wouldn't be
able to increase their own thread priorities at all. Each client would run as an
separated process.

The only solution that came to my mind so far is to have the clients communicate
with the server through shared memory. For each client, a shared memory region
would be allocated, consisting of one lock-free ringbuffer for input, another
for output, as well as a shared semaphore for server-to-client signaling.

At each cycle, the server would read and write audio data from/to the
ringbuffers of each registered clients, and then call sem_post() on all shared

A client side library would handle all client registering details, as well as
thread creation. It would then sem_wait(), and when awaken, read from the input
ringbuffer, call the client process callback with I/O buffers, and write to the
output ringbuffer.

Does this design sound good to you? Do you think it could achieve reliable I/O,
and reasonable latency? Keeping latency as low as possible, what do you advise
for the size of the ringbuffers?


More information about the Linux-audio-dev mailing list