Sndio: a small audio and MIDI framework part of the OpenBSD project | Hacker News Reader

Sndio: a small audio and MIDI framework part of the OpenBSD project

sndio.org

101 pointssetra25 comments

This is the native audio subsystem used by OpenBSD, it includes a library (libsndio) and a privsep server (sndiod). There was a massive successful undertaking to write backends for most 3rd party audio software in the ports tree, things like chromium, and it is now included upstream in SDL, OpenAL, Mozilla Firefox, mpd, etc.

There is a good support for sndio in the FreeBSD ports tree as well. Albeit hidden behind the SNDIO build time option. It was quite the ride to get it to that point :-)

There are also now some sndio backends out there for applications not in the OpenBSD ports tree like Cava, shairport-sync, and Kodi.

voidlinux's firefox package has sndio support in it. It takes very little cpu to run this unlike pulseaudio which would kill this little underpowered laptop I'm currently on (several generations old sual dore atom).

For Pulseaudio please file bugreports. Could be that it's transcoding things (44.1kHz to 48kHz conversion, etc).

I have a pretty slow CPU (NUC5PPYH) and Pulseaudio has been working fine for loads of years.

> voidlinux's firefox package has sndio support in it.

Wow, didn't know that. I'm a fan of all three but no time to muck around with distros. Might reconsider.

I know very very little about audio frameworks, but what does sndio have over it's competition? It is clearly a simpler and likely cleaner system than PulseAudio, but what about compared to ALSA and OSS?

I have been using a OpenBSD system as my living room "media" computer for a while. Before that it was a Linux system. I have to discuss sndiod (the mixer daemon) as that is the interface that is normally used and it has the same API as the underlying sound drivers.

Comments:

1. There was a learning curve. You put all your default configuration in the /etc/mixerctl.conf file. After boot you use the mixerctl command to change anything you need to change. In my case I never use the mixerctl command as everything just works by using the per application volume controls. I have the master volume mapped to some function keys but I never use them.

2. The Sndio drivers, at least for my hardware, simplify the interface. That had good and bad results over the previous ALSA interface. The bad was that there were missing features. The good is that it was possible to actually figure out how to use regular audio. I was never able to figure out how to configure 5.1 audio properly on ALSA due to the ridiculous complexity of the onboard HD audio exposed through ALSA. When I moved to OpenBSD I was able to get rid of the extra sound card (which OpenBSD did not support).

3. The addition of sndiod (the mixer daemon) is for all practical purposes transparent. You get a single volume control per app and that is that. The hardware mixer controls are effectively hidden in a useful way. There is nothing like the separate ALSA hardware controls you have to mess with when you use Pulseaudio.

4. Once you set up your audio inputs (which are also done in a transparent way through sndiod) you are done. So when I pick up the mic to talk on mumble I expect that I will be heard, even if I have rebooted. Compared to my experience on Linux, this feels like witchcraft.

5. Sndio through sndiod has network transparency that is done in a fairly transparent way. You just add on a server name when specifying the device name. I use this functionality for a whole house audio system where the target is a sndiod running on a Linux system using ALSA as the backend. Debian has a sndiod package now.

For simple audio playback there's not much difference between their APIs. OSS is a bit of an outlier because it works on a sound device via standard IO system calls. All the other frameworks expose very similar functions: you initialize the library, you tell it about your audio format and then you start writing the audio data. Xiph.org's libao [1] is worth a mention because it's a very neat library that offers true cross-platform support.

[1] https://xiph.org/ao/

On Linux, this is implemented on top of ALSA, which is the native Linux kernel sound API.

So then would sndio be the OpenBSD native sound API?

Basically, on OpenBSD, audio functionality was partially moved from kernel to user space, it was extended and called sndio. From this standpoint it's the OpenBSD native audio API. The remaining kernel audio(4) and midi(4) APIs are internal interfaces used by sndio to get access to the bare hardware; they are too limited to be useful to typical programs.

For the sake of easier application software, yes. sndio is the higher level of abstraction. There is a lower level API, audio/mixer/midi(4), but they exist as only ioctl(2) calls.

I've never heard of someone preferring PulseAudio to ALSA

Pulse audio is OK for routing audio around. It even supports LADSPA filters through a module. So I’ve used it when playing Dungeons & Dragons over Mumble, to filter my voice when role-playing monsters (nothing beats a little reverb and pitch tuning to make the monster boss more frightening to the players) and putting music into the channel. I would not know how to do that with ALSA. But Pulse Audio uses ALSA, so...

That said, JACK is much better for routing audio through applications. And jack-rack actually lets you change the parameters of LADSPA filters without reloading. And it is easy to get a graphical mixer up controlling individually the volume from all the sources.

I've tried 3 times in the past to run JACK on Ubuntu. Each time I had bricked audio after installing, tried to fix for around 1-2 hours and gave up. My experience with JACK has been horrible.

I don’t know your setup, but Ubuntu uses PulseAudio as default, and it can sometimes take the sound devices hostage. There is a package called pulseaudio-module-jack which will let you output sound from JACK through PulseAudio. Using qjackctl you can see how everything is connected and direct it to the pulse source. The pulse source can be connected, to say your speakers, by loading a loopback module in pactl.

There's also Cadence from KXStudio repository[0]. It's a replacement for qjackctrl that can be used to setup pulseaudio-to-jack bridge relatively painlessly.

[0] http://kxstudio.linuxaudio.org/Applications:Cadence

I've had precisely the opposite experience - for me, JACK is amazing and gives me 40-channels of pro audio over my external audio interfaces (I run a studio with a Linux DAW), but if I put PulseAudio anywhere near this configuration, it dies in a burning pile of poo. I despise PulseAudio and will never use it.

That does sound like fun. Do you have a link to the software you use for applying said filters?

In Pulse I just used the LADSPA module, and loaded it with pactl load-module module-ladspa-sink. There is an example in the docs[0].

I stacked a number of filters on a null-sink and then used the loop-back module to put the sound from the mic into the top filter. Then I redirected mumble to the null-sink’s monitor. The filters I used were the ones I found in the debian package repo.

In comparison, it was much easier to do in JACK, where I could create the filter stack in jack-rack[1], which has a GUI, and do the plumbing in qjackctl.

[0] https://www.freedesktop.org/wiki/Software/PulseAudio/Documen...

[1] http://jack-rack.sourceforge.net/

I like network transparency and the ability to move running streams from speakers to USB headphones.

or duplicate streams and send it to multiple sound outputs.

I have and I do, vastly. ALSA's software mixer was a terrible hack that you'd be lucky to get to work at all, and then you'd have to take care to have all of your applications request the exact same sample format. ESD was decent in many respects, but still hogged the device from anything that didn't explicitly support it.

Before PulseAudio came along, my "solution" to Linux desktop audio was to simply keep using an ancient sound card that still had a hardware mixer.

Can sndio replace Jack?

It doesn't look like sndio targets the application->application audio routing use-case, nor does it appear to prefer a lower latency audio pull-API. So, it does not look like by design it can be a jack replacement.

Reply on news.ycombinator.com