Removing hard dependencies on PulseAudio and splitting ports

which FreeBSD ports require it …

<https://www.freshports.org/audio/pulseaudio/#dependencies> ▶ … required by

Alternatively:

pkg rquery -r FreeBSD '%ro' pulseaudio | sort

Without a lock pkg would just re-install the package on next run because of the changed options.

Possibly, depending on how things are configured.

My comment about locking was more general, in response to the comment about desktop environments and browsers (not PulseAudio in particular).
 
Thanks for the list etc, but I worded it badly. I actually meant (leaf) ports that won't have sound when they're compiled without Pulseaudio support (if any that is). I remember testing OBS and I'm pretty sure that I didn't have any issues playing back sound.
 
I just realized that telegram-desktop now have pulseaudio as a build requirement, sigh.
 
Definitely.


I'd be interested in an list. I know there are some but haven't met many of them.

Quoting FreshPorts:

... that's not that much.
And how many are optional? We know it should be optional for alsa-plugins, how many others? I have yet to run into absolutely having to have Pulseaudio. I did have to use apulse on Linux when I ran Steam on it.
 
Just based on this thread, un-setting PulseAudio in make.conf can make sense for those who can be bothered. I don't care, it doesn't get in my way. :p
 
And how many are optional? We know it should be optional for alsa-plugins, how many others? I have yet to run into absolutely having to have Pulseaudio. I did have to use apulse on Linux when I ran Steam on it.
Since upgrading to the 3rd quarter's quarterly upgrades, I now have pulseaudio as a requirement for the speech-dispatcher pre-compiled binary package on my kde5 and plasma5-plasma systems. This wasn't true for the 2nd quarter's versions, and still isn't true for my Mate desktop system.
Code:
root@kde5:~ # pkg info -r pulseaudio
pulseaudio-14.2:
        alsa-plugins-1.2.2
        speech-dispatcher-0.10.2
This may yet inspire me to attempt building these two components from ports, and yes, mixing ports and packages, in my oh-so-precious free time, but I ain't quite there yet. I'm still able to keep it from running by setting autospawn = off in /usr/local/etc/pulse/client.conf and, in any case, I'm not really dependent on the plasma5 desktop environment-- I just happen to like playing around with it. Mate is enough to fullfil my requirements.
 
Jose said:
And how many are optional?

Code:
# grep -R OPTIONS_DEFINE= /usr/ports/* | grep -i PULSEAUDIO | sed -E 's/\/Makefile.*//'
/usr/ports/accessibility/speech-dispatcher
/usr/ports/audio/libcanberra
/usr/ports/audio/drumstick
/usr/ports/audio/xmp
/usr/ports/audio/csound
/usr/ports/audio/openal-soft
/usr/ports/audio/lmms
/usr/ports/audio/ncspot
/usr/ports/audio/deadbeef
/usr/ports/audio/shairport-sync
/usr/ports/audio/noson-app
/usr/ports/audio/libmatemixer
/usr/ports/audio/fasttracker2
/usr/ports/audio/darkice
/usr/ports/audio/alsa-plugins
/usr/ports/audio/linux-c7-alsa-plugins-pulseaudio
/usr/ports/audio/pulseaudio
/usr/ports/audio/cava
/usr/ports/audio/forked-daapd
/usr/ports/audio/aqualung
/usr/ports/audio/mumble
/usr/ports/audio/gsequencer
/usr/ports/audio/lollypop
/usr/ports/audio/linux-c7-pulseaudio-libs
/usr/ports/audio/fluidsynth
/usr/ports/audio/libopenmpt
/usr/ports/audio/musescore
/usr/ports/audio/sonic-visualiser
/usr/ports/audio/libao
/usr/ports/audio/kmix
/usr/ports/audio/rtaudio
/usr/ports/audio/xfce4-pulseaudio-plugin
/usr/ports/audio/bambootracker
/usr/ports/audio/spotifyd
/usr/ports/comms/fldigi
/usr/ports/comms/multimon-ng
/usr/ports/devel/efl
/usr/ports/devel/allegro5
/usr/ports/devel/allegro-devel
/usr/ports/devel/ptlib
/usr/ports/emulators/fmsx
/usr/ports/emulators/citra
/usr/ports/emulators/rpcs3
/usr/ports/emulators/vice
/usr/ports/emulators/virtualbox-ose-legacy
/usr/ports/emulators/virtualbox-ose
/usr/ports/emulators/yuzu
/usr/ports/games/retroarch
/usr/ports/graphics/libprojectm
/usr/ports/multimedia/mythtv
/usr/ports/multimedia/wf-recorder
/usr/ports/multimedia/phonon
/usr/ports/multimedia/QtAV
/usr/ports/multimedia/gnome-mplayer
/usr/ports/multimedia/gmtk
/usr/ports/multimedia/avidemux
/usr/ports/multimedia/quodlibet
/usr/ports/multimedia/pipewire
/usr/ports/net/gtk-vnc
/usr/ports/sysutils/mate-settings-daemon
/usr/ports/x11/waybar
/usr/ports/x11/polybar
/usr/ports/x11/wf-shell
/usr/ports/x11/plasma5-plasma

This gives 64 ports where Pulseaudio is an option.
 
How do you exactly *use* sndio though? I couldn't get it to show any devices in OBS Studio, which I built with sndio instead of Pulse.
 
How do you exactly *use* sndio though? I couldn't get it to show any devices in OBS Studio, which I built with sndio instead of Pulse.

Alright it seems OBS is able to only capture input sound of OSS devices. Playing/monitoring sound via OSS seems not possible and would need PulseAudio for that.

Here is the option for "sndio input client" available:
screenshot_1.jpg

Another option available is the "Audio Input Capture (OSS)", then able to choose OSS devices to capture input sound via OSS:
screenshot.jpg

Here are some links of how other users are able to do so:

However if you are doing some professional audio work, I would stick with pulseaudio/pipewire for now since there are not much apps and pro apps supporting OSS as of yet.
 
However if you are doing some professional audio work, I would stick with pulseaudio/pipewire for now since there are not much apps and pro apps supporting OSS as of yet.
Scratch "as of yet". I think most devs don't think one minute about OSS, because as far as Linux goes, it's such a small margin of users and I have yet to get OSSv4 to properly work on Linux. Seems to get harder with each kernel release.
On the other hand FreeBSD sound works out of the box as expected and I haven't had a better audio experience on any other operating system. :)

There are some programs that I'd like to use but potentially need Pulseaudio, such as OBS and Dolphin (the Gamecube emulator) but I've been building everything without Pulseaudio to avoid it so this is the last resort. I don't avoid Pulseaudio because of the stigma, but I have a bad experience with it and ALSA in general (probably boils down to ALSA itself) where I would get a constant popping sound regardless of what configurations I made. I have never had this issue on FreeBSD.
 
Regarding sound options for ports, I currently have these on my package builder:
Code:
OPTIONS_UNSET+= ALSA JACK PULSE PULSEAUDIO 
OPTIONS_SET+=   SNDIO PORTAUDIO
Enabling SNDIO and PORTAUDIO is mainly for ports that can't use OSS directly.

My reason to still avoid pulseaudio is a bad experience a very long time ago, when Debian introduced it, I wasted a few days trying to get it to work, just to finally disable it. I'm pretty sure quality improved since ... otherwise you'd still see a lot more complaints, now that it's more or less the "default". So some day, I'll have to revisit it, because:

I don't see any chance to get rid of it being a default option any more.

First reason is the growing amount of software that just can't use anything else. With a reasonable large set of packages on your poudriere builder, you will have it build pulseaudio anyways, even with the option disabled. Happened to me because of xrdp, pulseaudio is the only option for remote audio.

Then, it provides some features like e.g. the ability to mix and rewire streams of individual applications. Of course, other sound daemons can do similar things, but with pulseaudio already there because it's just required by a growing number of applications, people will use it. As a consequence, you would restrict features for users of the official repositories if you disabled pulseaudio in the default options.

If you (like me) don't need these features, it's indeed just wasted disk space and RAM, given FreeBSD's excellent implementation of the OSS interface. But indeed, as already mentioned, it isn't much space, so, not really a relevant thing nowadays, you can just live with it...
 
Scratch "as of yet". I think most devs don't think one minute about OSS, because as far as Linux goes, it's such a small margin of users and I have yet to get OSSv4 to properly work on Linux. Seems to get harder with each kernel release.
Well an older OSSv3 was the standard audio subsystem of Linux, until ALSA replaced it when in 2002 OSS became proprietary software, which was later changed in 2007. Since then nobody really bothered on Linux about OSS any longer.

ALSA immediately back then received high praise:
 
Well an older OSSv3 was the standard audio subsystem of Linux, until ALSA replaced it when in 2002 OSS became proprietary software, which was later changed in 2007. Since then nobody really bothered on Linux about OSS any longer.

ALSA immediately back then received high praise:
The website definitely looks like its from 2005. 😂
Looks like "high praise" indeed. I get why ALSA was created, and I've attemped to use pure ALSA + dmix, which pops much less, but it still happens. Perhaps I'm mis-remembering the history books, but didn't FreeBSD just continue using the free and open-source version of OSS until OSS v4 came along? Now it's more of its own thing. Maybe Linux could have done the same.

Regarding sound options for ports, I currently have these on my package builder:
Code:
OPTIONS_UNSET+= ALSA JACK PULSE PULSEAUDIO
OPTIONS_SET+=   SNDIO PORTAUDIO
Enabling SNDIO and PORTAUDIO is mainly for ports that can't use OSS directly.

My reason to still avoid pulseaudio is a bad experience a very long time ago, when Debian introduced it, I wasted a few days trying to get it to work, just to finally disable it. I'm pretty sure quality improved since ... otherwise you'd still see a lot more complaints, now that it's more or less the "default".
I have the same build options. I've only been using Linux/*BSD since 2017, and in that time I've experienced the same issues people were having with PulseAudio over 10 years ago. No "solution" worked. Neither did Pipewire, which had the same issues. Though, with the way things are going, it looks like Pulse and/or Pipewire will be the norm more than it already is.
 
Scratch "as of yet". I think most devs don't think one minute about OSS, because as far as Linux goes, it's such a small margin of users and I have yet to get OSSv4 to properly work on Linux. Seems to get harder with each kernel release.
On the other hand FreeBSD sound works out of the box as expected and I haven't had a better audio experience on any other operating system. :)

There are some programs that I'd like to use but potentially need Pulseaudio, such as OBS and Dolphin (the Gamecube emulator) but I've been building everything without Pulseaudio to avoid it so this is the last resort. I don't avoid Pulseaudio because of the stigma, but I have a bad experience with it and ALSA in general (probably boils down to ALSA itself) where I would get a constant popping sound regardless of what configurations I made. I have never had this issue on FreeBSD.
That is true, I try my best to avoid anything other than OSS. Hopefully someday if I have the free time I'll like make professional audio GUI apps using OSS system.
 
I haven't actually made use of Pulseaudio on FreeBSD, but since its a layer for sound it allows you to switch audio devices on the fly without needing to re-open the application, right? If so, is sndio also capable of this?
 
Well I think you'll run into issues so it's good practice to restart sound servers, drivers and apps to get things working properly after changing low level parameters.
Some commands (below) which you can reload the pulseaudio sound server on the fly.

Check if pulseaudio is running:
pulseaudio --check

To stop pulseaudio:
pulseaudio -k

To restart pulseaudio:
pulseaudio -D

(I simply log out and login again or simply reboot)
 
I haven't actually made use of Pulseaudio on FreeBSD, but since its a layer for sound it allows you to switch audio devices on the fly without needing to re-open the application, right? If so, is sndio also capable of this?
When i boot my pc i know which sound devices i want. So, "on the fly changing", why ?
 
When i boot my pc i know which sound devices i want. So, "on the fly changing", why ?
So you don't have to type a sysctl command each time you want to switch from headphones or speakers for example.
 
That is a great burden, do you have two different audio output ports (one for the headphones and speakers) are you using a GUI desktop environment?
Yes, I have the speakers hooked up to the back and the headphones in the front. I gave up and just use the headphones now. I don't use a desktop environment, x11-wm/ctwm currently.
 
Back
Top