i.e. OSS?
No and I try to avoid pulseaudio in the first place. It's a highly opinionated and often troublesome piece of software, even in the linux ecosystem where it's developed on and for. The experience with pulseaudio covers the whole spectrum, from "Sound works perfectly and instantly better than ALSA and everything else" to "Pulseaudio borked my audio hart and no fix in sight" and everything in between. And to this day I haven't understood what benefits pulseaudio actually brings to the table, especially on FreeBSD.
This breaks my heart. And my heart breaks even more when much appreciated and awesome ports, like emulators/pcsx2, list pulseaudio unconditionally as a dependency even when the port works just fine with OSS. Someday I want to launch a PR campaign on https://bugs.freebsd.org to disable pulseaudio in every port for which it's not a true hard dependency. It might be easier when subpackages are supported in the ports framework. With subpackages we could seperate libpulse.so and pulseaudio into two packages and make every port dependend on the libpulse-package. Everyone who truly truly really wants pulseaudio could then install the server binary with the pulseaudio-package. That's actually what some linux distros do and is the right way. It's sad that there are linux distros which make it easier to have a pulseaudio-free system than FreeBSD, where it is foreign.
you have my sword.
The reason to go with pulse in the default options is a very pragmatic one: in the majority of upstream projects, this is the best maintained and tested option, even if other adapters are provided. Of course that's because it became the de-facto standard on Linux desktops. And then, once you run pulseaudio, it's best to have ALL audio use it, otherwise issues are more likely...
Agreed, the battle for the good cause is a long and exhausting one.
Ha! Well, thinking about this, I think a) it's probably indeed doable (using cuse(3) to provide some userspace OSS devices), and I'd very much appreciate it, b) it won't be simple at all but a lot of work, c) no, I didn't imply thatI also read between your lines: you're teasing me to implement an OSS and sndio backend for xrdp (probably like audio/pulseaudio-module-xrdp). Ok, I'm not uninterested. Well played Sir, well played
and d) unfortunately, this won't solve the underlying problem:. While FreeBSD has a very nice implementation of OSS, the one in Linux was quite bad (not even solving the issue of opening /dev/dsp and friends was a system-wide exclusive resource...). Instead of fixing this, they came up with ALSA, that's a long time ago and IMHO that's where things started to go sideways...
Simple. You don't know or understand how the FreeBSD ports tree is managed.
When I first tried to play sounds on FreeBSD, everything other than pulseaudio had worse problems. Most apps I've tried AT THE MOMENT (not now!) using OSS didn't support shared vchans, thus forced me to quit application previously using sound to use another. Yes, it's VERY old story, though.
Now it got me curious. I took a first glimpse at the pulseaudio and pipewire module for xrdp and it doesn't seem to be THAT difficult at all (famous last words...). Maybe after my Ryujinx porting efforts I'm trying it if I'm still interested in this. Such projects can be a lot of fun.Ha! Well, thinking about this, I think a) it's probably indeed doable (using cuse(3) to provide some userspace OSS devices), and I'd very much appreciate it, b) it won't be simple at all but a lot of work, c) no, I didn't imply that
I understand your frustration, I also wish we had a different status quo in the ports tree management for this topic. But as zirias@ and SirDice have pointed out, it's probably too much work and effort involved in convicing every port maintainer to disable pulseaudio by default for small gain. In the end, for most programs you can change the audio backend in the options at runtime and if pulseaudio really interferes with your audio setup then
ln -sf /bin/true /usr/local/bin/pulseaudio is always a last resort . Of course subpackaging the pulseaudio port is interesting, as is something like apulse just for OSS or sndio. But such things would need time too, and pulseaudio is actually on its way out in the linux ecosystem. Pipewire is becoming the new standard.
Uh, what ....?
So you're obviously talking about some specific Linux distribution while we have to guess which one.
It might be possible to build several packages out of this pulseaudio mess, although I could only know by having a deeper look. Without subpackage support in our ports framework (still waiting for that feature), it's not guaranteed such a thing is possible.
Which browser are you talking about? Something like this would surprise me a lot. When OSS is supported in some upstream project, it's always in the default port options. Looking at the "big ones", chromium doesn't support OSS (but has sndio enabled by default which is reasonably lightweight), and firefox certainly has OSS in the default options.
There's a FAQ about this here on these forums.
I don't think it does. It solves problems for Linux due to not having an OSS-like audio stack by moving the mixer functionality to userland instead of the kernel. As I see it, FreeBSD use-case of pulseaudio is strictly for compatibility.
In my experience, yes. One of my HTPCs was on xfce for quite a while after they introduced the pulseaudio dependency. It was not a problem to bypass it, e.g. from Kodi, as long as I compiled Kodi without pulseaudio support. Other applications allowed selecting the audio system, e.g. Firefox.