SNDIOD(8)

🎧 SNDIOD(8) — System Manager's Manual 🎧

okay bestie, gather round, because we are talking about sndiod from the System Manager's Manual, and she is that girl. this is the audio/MIDI server situation and honestly? she's the backbone of your whole sound setup. no cap. 💅

---

✨ NAME ✨

sndiod — audio/MIDI server 🎀

like, the literal audio and MIDI server. she does both. main character energy fr fr. 🦋

---

✨ SYNOPSIS ✨

lowkey the whole vibe in one code block, bestie. every flag, every argument, exactly as written:

sndiod [-d] [-a flag] [-b nframes] [-C min:max] [-c min:max] [-e enc]
       [-F device] [-f device] [-j flag] [-L addr] [-m mode] [-Q port]
       [-q port] [-r rate] [-s name] [-t mode] [-U unit] [-v volume]
       [-w flag] [-z nframes]

so yeah. that's a lot of little knobs and dials and honestly the way she just lines them all up like that? obsessed. 😭✨

here's the quick rundown of what each of those lil cuties is doing up there, so you're not just staring at brackets like 🙈:

• -d — a lone flag, no argument, just vibing by itself 🌸
• -a flag — takes a flag argument
• -b nframes — takes an nframes value
• -C min:max — takes a min:max range, colon and all, don't lose the colon bestie 💀
• -c min:max — same deal, another min:max range
• -e enc — takes an enc argument
• -F device — takes a device (capital F, do NOT confuse her with lowercase f, they are different girls) 👑
• -f device — also takes a device, lowercase f this time
• -j flag — takes a flag
• -L addr — takes an addr (capital L, again, distinct from lowercase l energy, but there's no lowercase l here so we're safe 😌)
• -m mode — takes a mode
• -Q port — takes a port (capital Q, she's loud)
• -q port — takes a port (lowercase q, she's chill) 🍓
• -r rate — takes a rate
• -s name — takes a name
• -t mode — takes a mode
• -U unit — takes a unit
• -v volume — takes a volume
• -w flag — takes a flag
• -z nframes — takes an nframes value

bestie PSA: that's all just the synopsis, okay? we are literally at the very top of the page. the actual tea about what every single one of these does is coming. don't skip ahead. 🫶

---

that's the header + NAME + SYNOPSIS handled. more of her is coming, so stay tuned, we are NOT done. 💖

✨ DESCRIPTION ✨

Okay bestie, so the sndiod daemon is literally the middle layer between your audio or MIDI programs and the actual hardware 💖. It does all the audio processing necessary so that any program can work on any supported hardware. Iconic behaviour, no cap.

By default, sndiod only accepts connections from programs running on the same system. And here's the cute part: it only wakes up and initializes when programs are actually using its services, so the rest of the time it consumes a negligible amount of system resources 🦋. Systems with no audio hardware at all can still use sndiod to keep hot-pluggable devices usable by default at virtually no cost. Slay.

Here's how it operates, bestie: it exposes at least one sub-device that any number of audio programs can connect to and use as if it was real audio hardware 👑

• During playback, sndiod receives audio data concurrently from all programs, mixes it, and sends the result to the hardware device 🌈.
• Similarly, during recording, it duplicates the audio data recorded from the device and sends it to all programs 💜.

And because the audio data literally flows through the sndiod process, it gets to process audio data on the fly:

• Change the sound encoding to overcome incompatibilities between software and hardware 🎀.
• Route the sound from one channel to another, join stereo or split mono 🦋.
• Control the per-application playback volume as well as the master volume 💅.
• Monitor the sound being played, allowing one program to record what other programs play 👀.

Processing is configured on a per sub-device basis, meaning the sound of all programs connected to the same sub-device gets processed according to the same configuration. Multiple sub-devices can be defined, letting multiple configurations coexist 🫶. The user picks which configuration a given program uses by selecting the sub-device that program uses.

sndiod also exposes MIDI thru boxes (hubs), letting programs send MIDI messages to each other or to hardware MIDI ports in a uniform way 🎹✨.

And finally, sndiod exposes a control MIDI port usable for:

• Volume control 🔊.
• Common clock source for audio and MIDI programs ⏰.
• Start, stop and relocate groups of audio programs 🎛️.

---

💖 The options, one by one (yes, all of them)

The options are as follows:

• -a flag — controls whether sndiod opens the audio device or the MIDI port only when needed, or keeps it open all the time. If the flag is on, the audio device or MIDI port stays open all the time, ensuring no other program can steal it 🔒. If the flag is off, then it's automatically closed, allowing other programs to have direct access to the audio device, or the device to be disconnected. The default is off.
• -b nframes — the buffer size of the audio device in frames. Heads up: a frame consists of one sample for each channel in the stream. This is the number of frames that will be buffered before being played, so it controls the playback latency ⏱️. The default is 7680, or twice the block size (-z), if the block size is set.
• -C min:max, -c min:max — the range of channel numbers for recording and playback directions respectively that any client is allowed to use. This is a subset of the audio device channels. The default is 0:1, i.e. stereo 🎧.
• -d — enable debugging to standard error, and do not disassociate from the controlling terminal. Can be specified multiple times to further increase log verbosity 📝 (spam it if you need to, bestie).
• -e enc — attempt to configure the device to use this encoding. The default is s16. Encoding names use the following scheme: signedness (s or u) followed by the precision in bits, the byte-order (le or be), the number of bytes per sample, and the alignment (msb or lsb). Only the signedness and the precision are mandatory ✨. Examples: u8, s16le, s24le3, s24le4lsb.
• -F device — same as -f except that if the device is disconnected, the one given with the previous -f or -F option will be used 🔄.
• -f device — add this sndio(7) audio device to devices used for playing and/or recording. Preceding per-device options (-aberwz) apply to this device. Sub-devices (-s) that are applied after will be attached to this device. Device mode and parameters are determined from sub-devices attached to it. If no -f option is used, sndiod will use rsnd/0, rsnd/1, ..., rsnd/3 🎶.
• -j flag — controls whether program channels are joined or expanded if the number of channels requested by a program is not equal to the device number of channels. If the flag is off, client channels are routed to the corresponding device channel, possibly discarding channels not present in the device 🗑️. If the flag is on, then a single client channel may be sent on multiple device channels, or multiple client channels may be sent to a single device channel. For instance, this feature could be used for mono to stereo conversions 🎧✨. The default is on.
• -L addr — specify a local network address sndiod should listen on; sndiod will listen on TCP port 11025+n, where n is the unit number specified with -U. Without this option, sndiod listens on the Unix-domain socket only, and is not reachable from any network 🔌. If the option argument is - then sndiod will accept connections from any address 😳.

As the communication is not secure, this option is only suitable for local networks where all hosts and users are trusted. Fr fr, don't be reckless with this one.

• -m mode — set the sub-device mode. Valid modes are play, rec, and mon, corresponding to playback, recording and monitoring. A monitoring stream is a fake recording stream corresponding to the mix of all playback streams 👀. Multiple modes can be specified, separated by commas, but the same sub-device cannot be used for both recording and monitoring 🚫. The default is play,rec (i.e. full-duplex).
• -Q port — specify an alternate MIDI port to use. If it doesn't work, the one given with the last -Q or -q options will be used. For instance, this allows a USB MIDI controller to be replaced without the need to restart programs using it 🎹🫶.
• -q port — expose the given MIDI port. This allows multiple programs to share the port. If no -q option is used, sndiod will use rmidi/0, rmidi/1, ..., rmidi/7 🎼.
• -r rate — attempt to force the device to use this sample rate in Hertz. The default is 48000 ⏱️.
• -s name — add name to the list of sub-devices to expose. This allows clients to use sndiod instead of the physical audio device for audio input and output, in order to share the physical device with other clients 🤝. Defining multiple sub-devices allows splitting a physical audio device into sub-devices having different properties (e.g. channel ranges). The given name corresponds to the “option” part of the sndio(7) device name string ✨.
• -t mode — select the way clients are controlled by MIDI Machine Control (MMC) messages received by sndiod. If the mode is off (the default), then programs are not affected by MMC messages 🙅. If the mode is slave, then programs are started synchronously by MMC start messages; additionally, the server clock is exposed as MIDI Time Code (MTC) messages, allowing MTC-capable software or hardware to be synchronized to audio programs 🎛️🔥.
• -U unit — unit number. Each sndiod server instance has a unique unit number, used in sndio(7) device names. The default is 0 🔢.
• -v volume — software volume attenuation of playback. The value must be between 1 and 127, corresponding to -42dB and -0dB attenuation in 1/3dB steps 📉. Clients inherit this parameter. Reducing the volume in advance allows a client's volume to stay independent from the number of clients, as long as their number is small enough. 18 volume units (i.e. -6dB attenuation) allows the number of playback programs to be doubled 🤯. The default is 127.
• -w flag — control sndiod behaviour when the maximum volume of the hardware is reached and a new program starts playing. This happens only when volumes are not properly set using the -v option ⚠️. If the flag is on, then the master volume is automatically adjusted to avoid clipping ✂️. The default is off.
• -z nframes — the audio device block size in frames. This is the number of frames between audio clock ticks, i.e. the clock resolution ⏰. If a sub-device is created with the -t option, and MTC is used for synchronization, the clock resolution must be 96, 100 or 120 ticks per second for maximum accuracy. For instance, 100 ticks per second at 48000Hz corresponds to a 480 frame block size. The default is 480, or half of the buffer size (-b), if the buffer size is set.

---

Okay so ordering matters, bestie, pay attention 👑. On the command line, per-device parameters (-aberwz) must precede the device definition (-f), and per-sub-device parameters (-Ccjmtvx) must precede the sub-device definition (-s). Sub-device definitions (-s) must follow the definition of the device (-f) to which they are attached. It's giving ✨sequence✨.

If no audio devices (-f) are specified, settings are applied as if the default device is specified. If no sub-devices (-s) are specified for a device, a default sub-device is created attached to it. If a device (-f) is defined twice, both definitions are merged: parameters of the first one are used but sub-devices (-s) of both definitions are created 🫶. The default sndio(7) device used by sndiod is rsnd/0, and the default sub-device exposed by sndiod is snd/default 💖.

If sndiod is sent SIGINT or SIGTERM, it terminates 💀. If sndiod is sent SIGHUP, it reopens all audio devices and MIDI ports 🔄.

By default, when the program cannot accept recorded data fast enough or cannot provide data to play fast enough, the program is paused, i.e. samples that cannot be written are discarded and samples that cannot be read are replaced by silence 🙈. If a sub-device is created with the -t option, then recorded samples are discarded, but the same amount of silence will be written once the program is unblocked, in order to reach the right position in time ⏱️. Similarly silence is played, but the same amount of samples will be discarded once the program is unblocked. This ensures proper synchronization between programs 🎯 — which is literally the whole point, iykyk.

🎹 MIDI CONTROL 🎹

ok so here's where it gets iconic — sndiod spins up a MIDI port with the exact same name as the exposed audio sub-device, and MIDI programs can just… connect to it. It exposes the audio device clock and lets you control audio device properties straight through MIDI. no cap. 💅

A MIDI channel gets assigned to each stream, and the volume is changed using the standard volume controller (number 7). And like, the reverse too: when the audio client changes its own volume, that same MIDI controller message gets sent out. Which is lowkey perfect for monitoring, or as feedback for motorized faders. motorized faders are so main character, honestly. 🎚️✨

The master volume can be changed using the standard master volume system exclusive message.

Streams created with the -t option are controlled by these MMC messages:

• relocate — audio sndiod clients just ignore this one 🙈 but the given time position gets sent to MIDI ports as an MTC "full frame" message, which forces all MTC-slaves to relocate to that position (more on that below).
• start — puts all streams in starting mode. In this mode sndiod waits for every stream to become ready to start, and then starts them synchronously. Once started, new streams can still be created (sndiod) but they'll be blocked until the next stop-to-start transition. patience, bestie ⏳
• stop — puts all streams in stopped mode (this is the default). In this mode, any stream trying to start playback or recording gets paused. Client streams that already started aren't affected until they stop and then try to start again.

Streams created with the -t option export the sndiod device clock using MTC, so non-audio software or hardware can be synchronized to the audio stream. Maximum accuracy hits when the number of blocks per second equals one of the standard MTC clock rates (96, 100 and 120Hz). These sample rates (-r) and block sizes (-z) are the recommended ones:

• 44100Hz, 441 frames (MTC rate is 100Hz)
• 48000Hz, 400 frames (MTC rate is 120Hz)
• 48000Hz, 480 frames (MTC rate is 100Hz)
• 48000Hz, 500 frames (MTC rate is 96Hz)

For instance, this command creates two devices: the default snd/default and a MIDI-controlled snd/mmc:

$ sndiod -r 48000 -z 400 -s default -t slave -s mmc

Streams connected to snd/default behave normally, while streams connected to snd/mmc wait for the MMC start signal and then start synchronously. And regardless of which device a stream is connected to, its playback volume knob is exposed. every stream gets its moment ✨

---

🔌 HOT PLUGGING 🔌

If devices specified with -F are unavailable when they're needed, or get unplugged at runtime, sndiod will attempt to seamlessly fall back to the last device specified. bye bestie, we'll manage 🫶

But heads up: sndiod will not automatically switch to a specified device that gets plugged in at runtime. Instead, sndioctl(1) must be used to change the server.device control. you gotta ask, it's not gonna read your mind 💀

For instance, specifying a USB device with -F following a PCI device with -f lets sndiod use the USB one preferably when it's connected, and fall back to the PCI one when it's disconnected. iconic failover behaviour, honestly. 🦋

---

🌸 EXAMPLES 🌸

Start the server using default parameters, creating an additional sub-device for output to channels 2:3 only (that's the rear speakers on most cards), exposing the snd/default and snd/rear devices:

$ sndiod -s default -c 2:3 -s rear

Start the server creating the default sub-device with low volume and an additional sub-device for high volume output, exposing the snd/default and snd/max devices:

$ sndiod -v 65 -s default -v 127 -s max

Start the server configuring the audio device to use a 48kHz sample frequency, 240-frame block size, and 2-block buffers. The corresponding latency is 10ms, which is the time it takes the sound to propagate 3.5 meters. physics said slay 🔊

$ sndiod -r 48000 -b 480 -z 240

---

👀 SEE ALSO 👀

sndio(7)

---

💀 BUGS 💀

Resampling is low quality; down-sampling especially should be avoided when recording. not the vibe, fr fr.

If -a off is used, sndiod creates sub-devices to expose first and then opens the audio hardware on demand. Technically, this allows sndiod to attempt to use one of the sub-devices it exposes as an audio device, creating a deadlock. And there's nothing to prevent the user from shooting themselves in the foot by creating such a deadlock. 🙈 we warned you, bestie.

---

ok that's the whole page, you're officially a sndiod girlie now 👑 this Debian build ships with the $Mdocdate$ version stamp, and yeah the date is literally a placeholder — very mysterious of it. go forth and serve audio, periodt. 💖🎀