OSSv4 as default sound system?



I am about to install TrueOS with Lumina desktop but I would like to know more about the default sound system first.

Do you have many packages with PA as dependency (e.g. mpv, seamonkey, chromium)?
What is the default sound system, OSSv4 or PA?
Is TrueOS Lumina still shipped with PA?

I use OpenBSD XFCE with OSSv4 and the sound is perfect to my ears. I am looking for a more desktop oriented system with OSSv4 as default sound system.

P.S. I noticed you added a stable release, thanks!


Our current STABLE image has pulseaudio. However our UNSTABLE image has sndio which originates from OpenBSD along with OSS as a fallback when sndio is not supported by an application.


This is actually a very interesting question since FreeBSD does not technically enforce a single sound system…

By default, FreeBSD base uses a self-updated and self-maintained version of OSS. Within the package tree you will find applications that require/use OSS from base, OSSv4 from packages, ALSA, PulseAudio, Jack (which does not really work anymore), and SNDIO (from OpenBSD) - many of those with build options to switch between at least 2 or 3 of the options. So depending on which applications you have installed, you may actually have multiple sound systems installed/running on your system (and some other apps that use runtime-switches to determine which sounds systems to utilize, like libao).

On TrueOS, since we have control over the build options for packages, we have been trying to move as many applications as possible over to SNDIO (or base OSS) as the default backend and disabling the ALSA/PulseAudio options where possible. This is obviously a work-in-progress, but it appears that there is a large push among the FreeBSD port maintainers to move to SNDIO as well, and the number of ports which support it has been increasing dramatically in size recently.


Thanks for the explanation. Having been away from Unix sound systems for a while, I was really confused with all the different choices when I came back. I’m glad you guys are trying to get some control over it. It seems like a candidate to document once the dust settles.


I have Jack working on TrueOS STABLE.


I would love to use OSSv4, since the built-in oss doesn’t support my sound card properly, but the oss port didn’t build on FreeBSD CURRENT or TrueOS the last time I checked. It is incompatible with pulseaudio though, which has sometimes caused me problems with KDE applications.

Does SNDIO use the built-in, FreeBSD kernel drivers, or does it use its own drivers like the oss port does? As far as I can tell, there has been no progress in the FreeBSD sound drivers for a while (comparing the HW compatibility list for soundcards between releases, it basically doesn’t change). Maybe the OpenBSD guys have been doing better on that front, since they seem to care more about desktop machines? I don’t know, but I can hope. It’s a moot point if SNDIO just uses the built-in FreeBSD drivers though - though presumably, if the OpenBSD guys had already gotten working drivers, it would be easier for someone to get them into FreeBSD. FreeBSD is so behind on sound drivers that I don’t think that it supports any PCI-E sound cards in existence, and I don’t think that it properly supports many of the USB sound cards. I’ve tried to find a sound card that I could buy which would work with the built-in FreeBSD sound drivers and have found nothing except maybe some ancient PCI cards that won’t even work in my computer, because they’re PCI and not PCI-E. For a while, oss worked as a workaround (though since you have to build your own kernel, and it doesn’t work with the stuff that requires pulseaudio, it’s still far from ideal), but now, unfortunately, that isn’t an option anymore.


It appears there is a lot of new ports aiming at Jack audio and LV2 coming around the corner.


Here is a comment by Yuri Victorovich in FreeBSD ports Bugzilla that explains how audio support is going in FreeBSD. :smiley:



I am not an expert on this matter yet but from my understanding sndio is more like a pulseaudio equivalent. It does not supply drivers for hardware it simply adds functionality like network streaming, and having per application volume levels.


sigh Figures. Occasionally, I’ve considered donating a sound card to get some more modern sound cards supported by FreeBSD, but I have no idea how to go about donating hardware to get it supported, and given that there seems to be essentially zero improvement in hardware support for sound cards for at least several releases, I question that anyone is actually working on the problem. Too much of FreeBSD’s focus seems to be on servers, which don’t need sound cards. Sadly, my best hope for decent sound card support is probably to try and figure out how to get the oss port building again, but last time I looked into it, it looked like it would take far more time than I had to work on the problem - though someone familiar with the API calls that are causing problems would likely be able to sort it out in a much more reasonable period of time. And even if I did have oss working, then pulseaudio wouldn’t work, since they’re not compatible. So, I guess that I’m kind of screwed regardless. :frowning:


Is there any news on this topic? I’m once again stuck with audio barely working thanks to pulseaudio on a system with 5.1 sound - rear and center are dead but constantly emit a screeching sound when pulseaudio is running…

Could at least Pulseaudio not be made a hard dependency for the trueos-desktop package, so it can be ripped out for good? Essentially everything is better than this steaming pile of crap…

FreeBSD has perfectly working in-kernel multi-channel mixing for OSS (which linux still lacks, hence the whole alsa/jack/pulseaudio/whatever mess of sound servers/proxies on linux), so why not just default to OSS until everything (if actually needed) can be switched to SNDIO?


with so many linux programs requiring pulse audio, it believe it’s been made the default on the desktop


What we ended up doing (for the moment) was this:

  • If an application supports Pulse or ALSA, build with Pulse support enabled
  • If an application supports SNDIO, build with sndio support

For both of these cases, the default fallback at runtime (if pulseaudio or sndio is not running) is to output to system OSS. What this gains us though (if pulseaudio/sndio are running) is the ability for the more complicated audio/video interactions such as WebRTC in a browser.

The reason we did this was that there are still some very important utilities in the ports tree which only support pulseaudio, and we can’t do a “full” switchover until enough applications gain support for SNDIO instead of pulse.


Thanks for the update.
And apart from those applications in ports that might not be able to output sound, is there any other reason why pulseaudio has to be a hard dependency for the lumina-desktop package?


Pulseaudio should not be a direct dependency of any of the Lumina packages. All that Lumina uses is the Qt5 Multimedia framework which is flexible as to what backend audio system it will use (gstreamer -> base OSS by default).


Well,Its not the pulseaudio package itself, but paprefs and pavucontrol:

# pkg remove pulseaudio
pkg-static: trueos-desktop is locked, cannot delete paprefs
pkg-static: trueos-desktop is locked, cannot delete pavucontrol
Cannot perform request


Both are pa- related. But what depends on them?