Removing hard dependencies on PulseAudio and splitting ports

bsduck

bsduck

Dear community,

Many people are annoyed by PulseAudio.
Recent examples:
forums.freebsd.org

Other - Looking to setup a desktop environment that doesn't need Pulseaudio

I was getting ready to install kde or xfce when I noticed they pulled in pulseaudio. I remember reading how unFreeBSD this was (or something like that) and was trying to figure out how to get either without pulseaudio and without losing volume control on my laptop - unsuccessfully. So, what's a...
forums.freebsd.org forums.freebsd.org
forums.freebsd.org

After upgrading no more audio in firefox

I did pkg upgrade and now I have no audio in firefox. I do have it with chrome, the problem seems to be firefox. Any hint? Thanks
forums.freebsd.org forums.freebsd.org

SirDice said:
Packages are built with the port's default options set. Most of the time Pulseaudio is set to off by default because a lot of people don't like it and it pulls in dependencies they don't want. I would suggest setting up your own package repository, there you can set everything how you want it.
Click to expand...
This attitude seem to fade away. Now some widely used ports are being built with PulseAudio support by default and therefore pull PulseAudio automatically when installed from pkg. This is especially problematic because PulseAudio shows the ungentlemanly behaviour of enabling itself without asking once it's installed.

Two ports in particular recently added PulseAudio to the default options:

audio/alsa-plugins which is a direct dependency of www/qt5-webengine and therefore indirectly required by Falkon, Qutebrowser, Konqueror, KMail, Amarok, MuseScore, ...

accessibility/speech-dispatcher which is a direct dependency of www/chromium and accessibility/qt5-speech and therefore indirectly required by most of KDE software (including Plasma destop), Linphone, FreeCAD, ...

As a result, lots of people ended up with PulseAudio added in a recent pkg upgrade and automatically enabled, sometimes leading to problems.

I emailed the maintainer of alsa-plugins about this, who replied it's not fair to let PulseAudio users rebuild everything in order to get things working. That's a good argument, but annoying all other pkg users by pushing Poetterware they don't need neither want on their systems and which may break audio setup is not fair either. We need a solution which is acceptable for both sides.

For this particular port, he suggested that it could be split in smaller ones. That's probably the way to do, and this is true for other ports too. For example x11-wm/lxqt-panel, which pulls PulseAudio because its built-in audio volume applet needs it. If this applet were made a separate port, like audio/xfce4-pulseaudio-plugin, installing LXQt wouldn't require PulseAudio anymore and nobody would be wronged in the move.

I'd like to do something to fix these problems and have lots of time available. The problem is: I don't know how to split a port. Your help is welcome.
 
bsduck said:
I emailed the maintainer of alsa-plugins about this, who replied it's not fair to let PulseAudio users rebuild everything in order to get things working.
Click to expand...
So you break existing setups for people who don't even know what Pulseaudio is? This makes no sense.
bsduck said:
I'd like to do something to fix these problems and have lots of time available. The problem is: I don't know how to split a port. Your help is welcome.
Click to expand...
I wonder if something like Apulse would work.
 
Jose, I think it's more "PulseAudio was not a dependency before, I updated packages and now it is". Basically inconsistency in a ports dependencies between versions. Hard on the maintainer if upstream keeps flipping around.
bsduck I think the maintainer is referring to "flavors" of the ports.
"find every port that has pulseaudio as a build or run dependency and see if it can be disabled. if so create a nopulse flavor that has pulseaudio disabled".
 
I never cared for pulseaudio. I just treat it as another compile-time dependency. Even with that, I'd want to compile it early on, with as many options enabled as practical, to avoid complaints from the make system. There's also portaudio and JACK as audio options for ports. I enable those, too, if available. My thinking basically goes, I don't want to end up hunting down the correct audio lib, because without it, some random application is not working correctly. I do agree that hard deps should be minimized, but I like having options and convenience. It ends up being a trade-off.
 
Jose said:
I wonder if something like Apulse would work.
Click to expand...
Something like that would be an option indeed: https://aur.archlinux.org/packages/pulseaudio-dummy/

The real PulseAudio could be declared as a build-only dependency, allowing the runtime library to be provided by the "fake" one using apulse:
Code: 
PULSEAUDIO_BUILD_DEPENDS=       pulseaudio:audio/pulseaudio
PULSEAUDIO_LIB_DEPENDS=         libpulse.so:audio/pulseaudio-dummy
That way PulseAudio would be used if installed, and otherwise pkg would install pulseaudio-dummy to satisfy the dependency. Not bad.

It's not an optimal solution because it still means installing unnecessary software, as well as having a weird PulseAudio -> ALSA -> OSS double compatibility layer, but it would already be better than the current situation and could be an acceptable compromise. I don't think apulse will autostart itself and create problems that way. I don't know however how Firefox (and other programs with similar automatic backend selection) would behave if it's installed: is the only presence of libpulse.so or the pulseaudio executable enough for it to choose the PulseAudio backend instead of the OSS one? In this case this would still not be solved.

I will further investigate. Thank you!

mer said:
I think the maintainer is referring to "flavors" of the ports.
"find every port that has pulseaudio as a build or run dependency and see if it can be disabled. if so create a nopulse flavor that has pulseaudio disabled".
Click to expand...
I thought about it too. It would be fine for a few end-user applications, but doing so with ports which are themselves dependencies of many other ports would be complex and I'm not sure this would be accepted. In this case it would make more sense to have the standard package built without PulseAudio support and an extra flavour for it. For example speech-dispatcher and speech-dispatcher-pulse. Otherwise most people will still end up with PulseAudio running just by installing random KDE software.
 
This seems a lot of work for something that will most likely disappear with multimedia/pipewire and then depending on how PipeWire integrate with FreeBSD, this effort will be needed again. And of course PipeWire had a PulseAudio option..
Which would give use this kind of layer: PipeWire -> PulseAudio -> ALSA -> OSS
 
FWIW, I install from packages so I can't use any of these hard dependency fixes, but I do have some random KDE software I use from time to time, and am annoyed by pulseaudio too, so I followed one of Alexander's suggestions by adding the following line to /usr/local/etc/pulse/client.conf ...
Code: 
autospawn=no
... in my plasma5-plasma install. This successfully prevented pulseaudio from respawning, and from even starting in the first place.

It might also be worth mentioning that in my stripped down plasma5-plasma install, the only component which uses pulseaudio is accessibility/speech-dispatcher and I don't use that anyway, so I'm good for now, but as monwarez just mentioned, all of this may be subject to change due to future upgrades.
 
Yeah, just y'all wait until KDE finally pulls the QT6.3/KF6/Plasma6 on us. FreeBSD's entire ports-mgmt category will blow up in everybody's faces. ;)
 
astyle said:
Yeah, just y'all wait until KDE finally pulls the QT6.3/KF6/Plasma6 on us. FreeBSD's entire ports-mgmt category will blow up in everybody's faces. ;)
Click to expand...
I really LOVE KDE, and have for years, but I keep a MATE desktop on reserve in anticipation of further birthing pains with KDE as it seems to be in a bit of an unstable period in its evolution right now. Regardless of all that, I've always preferred KDE as a general-purpose, fully-featured desktop environment, but for a long time now have preferred MATE as a simpler, more lightweight and stable front-end for any of my working Apache/PHP/Postgresql server systems. Thanks :D
 
Coming back to the idea of splitting ports: the maintainer I wrote to obviously didn't mean flavours.
Of course the real solution for this port in particular is to split it into many small ones, it shouldn't be one big monolithic port.
Click to expand...
In the case of alsa-plugins, this would mean to have different ports for different plugins, instead of a port including all plugins, so you can pick what you need (like with gstreamer plugins) instead of depending on the whole set. For example www/qt5-webengine obviously doesn't need alsa-plugins for its PulseAudio plugin, since itself comes with PulseAudio support disabled by default.

Another option would be to convince maintainers that enabling PulseAudio by default is bad, and make them revert to the previous defaults, but that will be even more complicated ;) And I must admit that having packages that work for both PA and non-PA users without alienating anyone would be nice. Given that some Linux distributions like Void manage to provide this, this shouldn't be an impossible task for us.
 
@OP: Sometimes, it feels like you're missing the point of /usr/ports. With some effort up front, it's possible to set up /usr/ports to match the packages (or install the ports.txz distribution from get-go), and then do this:
Code: 
# cd /usr/ports/my/port
# make config
(adjust your options)
# make
# make package
# cd /usr/ports/packages (assuming that's where results of previous line go)
# pkg install ./port (install the port in the current dir, NOT my/port from FreeBSD repos)

FWIW, Poudriere can be helpful (And grahamperrin will vouch for that!)
 
It's also possible to stop pulseaudio from starting automatically (if that is a lower hanging fruit than adding pulse flavors to all ports that may use pulse audio).

You can do that by editing /usr/local/etc/pulse/client.conf and changing the autospawn argument.

Code: 
autospawn = no

After that, pulseaudio will need to be started manually for any application that uses pulse.

The manpage for pulse-client.conf has additional information (sorry, I couldn't get the manpage tag to work correctly):
autospawn= Autospawn a PulseAudio daemon when needed. Takes a boolean
value, defaults to yes. Note that setting this to "no" doesn't disable
the systemd service. The autospawn option is only meant to be used on
systems without systemd. If you use systemd to start PulseAudio, use
"systemctl --user stop pulseaudio.service pulseaudio.socket" to stop
the daemon temporarily, or "systemctl --user mask pulseaudio.service
pulseaudio.socket" to permanently disable the units (the "disable"
command of systemctl probably won't work, because the pulseaudio.socket
unit is often installed to /usr/lib/systemd/user/sockets.target.wants/,
which makes it impossible to disable the unit with the "disable"
command).
Click to expand...
Yes, there is a lot of extra info for Linux-based systems using systemd in the manpage, but setting autospawn to no does work (speaking from experience).
 
The "autospawn" option is ignored for a lot of scenarios. It only prevents pulse from loading at X startup.
I just rm/mv'ed /usr/local/bin/pulseaudio from my systems and/or replaced it with a softlink to /bin/true to effectively stop pulseaudio from being loaded and messing up my sound configuration.

With the (annoying) frequency of updates for firefox (even ESR!) and the time it takes to build from ports, I rather nuke pulseaudio this way than rebuilding firefox every few days from source.
IMHO there are other even more annoying and bloated dependencies like e.g. akonadi, which pulls a full mysql-server and a ton of other packages. Because of that I usually build okular from ports without the "share" option, which reduces the install size by several 100MB!

Instead of trying to remove dependencies on single packages, I'd rather like to see a "minimal" variant of at least some bigger software packages, which still provides the basic functionality and tries to leverage what is already available in base (e.g. using OSS for sound...), but removing unnecessary bells&whistles that require a whole rats nest of dependencies...
 
sko said:
I just rm/mv'ed /usr/local/bin/pulseaudio from my systems and/or replaced it with a softlink to /bin/true to effectively stop pulseaudio from being loaded and messing up my sound configuration.
Click to expand...
I do the same with dbus-launch and dbus-daemon :)
 
astyle said:
@OP: Sometimes, it feels like you're missing the point of /usr/ports. With some effort up front, it's possible to set up /usr/ports to match the packages (or install the ports.txz distribution from get-go), and then do this:
Click to expand...
That's more or less what I do, but that's not the point of this topic. I do have lxqt-panel and alsa-plugins installed, and no PulseAudio installed, that's not the problem. The problem is: a user shouldn't have to use workarounds or build ports locally in order to have a PulseAudio-free desktop. This should be the default. OSS is one of the things that make FreeBSD desktop better than Linux desktop in my opinion, and ports pulling in PulseAudio for no reason are kind of sabotaging this. Like if installing Krita would pull in the Plasma desktop and automatically start it at login.
 
bsduck said:
That's more or less what I do, but that's not the point of this topic. I do have lxqt-panel and alsa-plugins installed, and no PulseAudio installed, that's not the problem. The problem is: a user shouldn't have to use workarounds or build ports locally in order to have a PulseAudio-free desktop. This should be the default. OSS is one of the things that make FreeBSD desktop better than Linux desktop in my opinion, and ports pulling in PulseAudio for no reason are kind of sabotaging this. Like if installing Krita would pull in the Plasma desktop and automatically start it at login.
Click to expand...
To be honest, I agree with the idea. My thinking goes, that would take a rather thorough analysis of the entire ports tree. Consider the fact that there's 3 audio back-ends that any given project can use: PulseAudio, PortAudio, and JACK. Even if you try using GStreamer or PipeWire or an external player for audio (say, audio/mpg123), there's a good chance it will still ultimately have PulseAudio as the back-end. You can go around asking different projects to rework their reliance on PulseAudio, or you can compile your own. That's just my take on the situation...
 
You must log in or register to reply here.
Back
Top