Removing hard dependencies on PulseAudio and splitting ports

[First_Law_of_Unix]

Have you tried installing "gtk-mixer":

FreshPorts -- audio/gtk-mixer: GTK based volume control tool

GTK-Mixer is GTK based volume control tool ("mixer"). GUI from xfce4-mixer: https://gitlab.xfce.org/apps/xfce4-mixer but xfce4 and gstreamer does not used. Features - plugins for support different sound backens - change system default sound card - set volume per line/channel - enable/disable...

www.freshports.org

pkg install gtk-mixer

Seems like it only requires x11 which ctwm uses.

You can use gtk-mixer to mute or unmute the audio ports easily since it is a GUI.

 

[Deleted member 72152]

I know about gtk-mixer, I have no issues changing the volume of different devices, the problem comes when I want to switch between them. This requires me to change hw.snd.default_unit to the corresponding number of the card listed in /dev/sndstat. I actually use hotkeys in ctwm that use the mixer command to turn the volume up/down and have osdmixer to see what the values are. However, I had to set up scripts to change the aforementiomed sysctl variable and restart osdmixer.

 

[sko]

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?

I switch between the sound card/speakers and USB DAC/Headphones regularly (using only dsbmixer) and don't have to restart e.g. firefox or vlc. The only thing that seems to (sometimes) stick to the output device is audio/deadbeef, but re-opening is sufficient.

Back when pulseaudio crept into the system, the usual experience would be hanging pulseaudio processes that block the audio device, last application that played sound and more often than not the whole USB bus (i.e. nothing that is attached/detached shows up in dmesg) until you at least killed each and every pulseaudio process but mostly I had to reboot to fix everything.

So NO, pulseaudio is not required to switch devices; in fact it isn't even capable of doing that reliably. OTOH OSS is perfectly capable of this without any problems.

 

[Alain De Vos]

So you don't have to type a sysctl command each time you want to switch from headphones or speakers for example.

You need to stop :
sndiod parameters_for_speakers
And start :
sndiod paramaters_for_headphone
This can easily be done on commandline.

 

[tyson]

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.

Im not using FreeBSD now as desktop, but probably could install it and test.
From what I remember last time I was running it, you can just switch to headphones 'on the fly', just need proper setup on device.hints.
Check my post long time ago and snd_hda()
Never liked pulseaudio too, and I was avoiding it as much as possible. FreeBSD OSS is perfectly fine, and the quality of output is way better than Linux/Windows when starting/stopping/switching sound.

 

[Alain De Vos]

In sysctl.conf you have

hw.snd.default_unit=1

In rc.conf:

sndiod_flags="-f rsnd/1 -L 127.0.0.1  -m play -s default

 

[Deleted member 72152]

You need to stop :
sndiod parameters_for_speakers
And start :
sndiod paramaters_for_headphone
This can easily be done on commandline.

In sysctl.conf you have

hw.snd.default_unit=1

In rc.conf:

sndiod_flags="-f rsnd/1 -L 127.0.0.1  -m play -s default

This is really no different than what Im having to do currently without sndio. I use sysctl to change the unit (between 6 and 7 for me) and then restart the application. Sndio should be capable of mixing in the same way Pulseaudio does, but better.

I switch between the sound card/speakers and USB DAC/Headphones regularly (using only dsbmixer) and don't have to restart e.g. firefox or vlc. The only thing that seems to (sometimes) stick to the output device is audio/deadbeef, but re-opening is sufficient.
So NO, pulseaudio is not required to switch devices; in fact it isn't even capable of doing that reliably. OTOH OSS is perfectly capable of this without any problems.

This is why I avoid Pulseaudio in the first place, the project is over 10 years old and still has the same issues it did in the beginning. I'll gladly take having to restart an application to change devices, but can't OSS itself handle that perfectly fine? Why doesn't it do this for everything?

Firefox is a notable example. It won't use the new sound device until the tab has been restarted, but each tab of Firefox is actually an independent application (Firefox was one of the first browsers to do this) so its the same as restarting the application.

 

[First_Law_of_Unix]

This is really no different than what Im having to do currently without sndio. I use sysctl to change the unit (between 6 and 7 for me) and then restart the application. Sndio should be capable of mixing in the same way Pulseaudio does, but better.

This is why I avoid Pulseaudio in the first place, the project is over 10 years old and still has the same issues it did in the beginning. I'll gladly take having to restart an application to change devices, but can't OSS itself handle that perfectly fine? Why doesn't it do this for everything?

Firefox is a notable example. It won't use the new sound device until the tab has been restarted, but each tab of Firefox is actually an independent application (Firefox was one of the first browsers to do this) so its the same as restarting the application.

It's not possible yet to use OSS for all apps on FreeBSD, since FreeBSD is using many Linux stuff ported into FreeBSD. Any Linux stuff ported into FreeBSD means it comes with the "burden" of Pulseaudio in most cases.

However, I think the best thing you can do is to create a batch script, so simply clicking on it will make changes to the output settings from speaker to headphone.
This will be easier for you, rather than typing manually all the time.

Also would like to confirm, are you using two different sound cards, or is it that the two different physical audio ports using the same sound card device (for example motherboard built in sound card chip providing audio for the two different physical audio ports)?

I practically have two different sound cards and one of the sound card has multiple audio ports, I never tried/tested outputting sound at the same time for two different sound cards or multiple physical audio ports. Will look into this and I'm sure it can be done, let you know.

 

[tyson]

It's not possible yet to use OSS for all apps on FreeBSD, since FreeBSD is using many Linux stuff ported into FreeBSD. Any Linux stuff ported into FreeBSD means it comes with the "burden" of Pulseaudio in most cases.

However, I think the best thing you can do is to create a batch script, so simply clicking on it will make changes to the output settings from speaker to headphone.
This will be easier for you, rather than typing manually all the time.

Also would like to confirm, are you using two different sound cards, or is it that the two different physical audio ports using the same sound card device (for example motherboard built in sound card chip providing audio for the two different physical audio ports)?

I practically have two different sound cards and one of the sound card has multiple audio ports, I never tried/tested outputting sound at the same time for two different sound cards or multiple physical audio ports. Will look into this and I'm sure it can be done, let you know.

This is most non-true statement I have ever read. One can use all apps he want if they support OSS, be it browsers/audioplayers etc.
I just did basic installation and Firefox and mpv don't need pulseaudio. Lets say those are most used "audio" apps Id use on any OS be it MacOS/Linux. Ye I know, but who need more than an audio player and browser? If you need more advanced apps, you dont mind to accept some burden.

Also, if you check my other post in this thread, it solves switching between headphones/speakers issue with simple one file edit.
But i will repost it, for your ease of use.
Add to /boot/device.hints

#Front
hint.hdaa.1.nid20.config="as=1 seq=0"
#Center
hint.hdaa.1.nid22.config="as=1 seq=1"
#Back/rear
hint.hdaa.1.nid21.config="as=1 seq=2"
#Side
hint.hdaa.1.nid23.config="as=1 seq=4"
#Headphones * MOST IMPORTANT ONE *
hint.hdaa.1.nid27.config="as=1 seq=15"

I use 7.1 speakers, and headphones. If you want only stereo output find what is your config with sysctl -a|grep hdaa and search for green jack. Magically when you connect headphones it just switch to this output now.

 

[fernandel]

I have the same applications installed years... At the time when I used ports I never had pulseaudio on my system but I think about two years ago when I switched to packages I cannot avoid anymore and I do not want to build ports again, special those which pull pulseaudio.

 

[tyson]

I have the same applications installed years... At the time when I used ports I never had pulseaudio on my system but I think about two years ago when I switched to packages I cannot avoid anymore and I do not want to build ports again, special those which pull pulseaudio.

Yes. Certain desktop environments rely on pulseaudio, for example KDE.
Lots of our ports is software made with Linux in mind, so there will be certain linuxism forced on us.
We can resist, as long as they support OSS.

 

[fernandel]

Yes. Certain desktop environments rely on pulseaudio, for example KDE.
Lots of our ports is software made with Linux in mind, so there will be certain linuxism forced on us.
We can resist, as long as they support OSS.

The "problem" are Blender, FreeCAD, Qutebrowser and the most guilty Qt5Webengine. But with building ports I did avoid pulseaudio. Now is what it is.

 

[Deleted member 72152]

I built Blender to use for video editing and I built it without Pulseaudio; but it really doesnt compare to Kdenlive so Ive been working on building that now..

I think I posted before that a blacklist system for pkg would be extremely beneficial for anyone who knows what theyre doing, would be much more efficient than building certain ports and locking them because Ive probably got 10+ that are locked.

 

[fernandel]

I built Blender to use for video editing and I built it without Pulseaudio; but it really doesnt compare to Kdenlive so Ive been working on building that now..

I think I posted before that a blacklist system for pkg would be extremely beneficial for anyone who knows what theyre doing, would be much more efficient than building certain ports and locking them because Ive probably got 10+ that are locked.

I do not building packages,

 

[First_Law_of_Unix]

This is most non-true statement I have ever read. One can use all apps he want if they support OSS, be it browsers/audioplayers etc.
I just did basic installation and Firefox and mpv don't need pulseaudio. Lets say those are most used "audio" apps Id use on any OS be it MacOS/Linux. Ye I know, but who need more than an audio player and browser? If you need more advanced apps, you dont mind to accept some burden.

Alright , tell me exactly how I can get a professional multi-band (at least 8+ bands) equalizer GUI app running on FreeBSD for OSS (good luck finding one).

I'm using this this Linux app (it is a professional infinite frequency bands GUI equalizer) working 100% on FreeBSD for system wide sound but needs Apps to run on pulseaudio:

GitHub - pulseaudio-equalizer-ladspa/equalizer: Pulseaudio LADSPA Equalizer

Pulseaudio LADSPA Equalizer. Contribute to pulseaudio-equalizer-ladspa/equalizer development by creating an account on GitHub.

github.com

Yes, to listen to sound in a civilized manner, I have to use pulseaudio. But if you can do "magic" to make this Linux app "work on OSS", please do so harry potter, I'm all ears, enlighten me on how to get the job done.

Would rather use OSS, I tried and there are no GUI apps for multi band equalizer for OSS system wide sound on FreeBSD. This has been discussed before and others have said the same.

Lastly, please do not show me how to use the command line to tweak multi-band frequencies (it is annoying doing that way), I need to use a GUI interface.

 

[monwarez]

I know about gtk-mixer, I have no issues changing the volume of different devices, the problem comes when I want to switch between them. This requires me to change hw.snd.default_unit to the corresponding number of the card listed in /dev/sndstat. I actually use hotkeys in ctwm that use the mixer command to turn the volume up/down and have osdmixer to see what the values are. However, I had to set up scripts to change the aforementiomed sysctl variable and restart osdmixer.

If you don't want to restart application after switching between different devices, then consider using audio/virtual_oss .
With it you can change device output on the fly without needing to restart the application (except for some applications like wine, maybe there is some configuration to be done), you can even take the mic of one device and the speaker of another device which is not feasible with just tuning hw.snd.default_unit .

 

[hendrack]

Have you looked at pipewire?

If you want to keep binary packages you can disable the pulseaudio daemon and have wireplumber as sound server for the packages with pulse dependency.

If you use ports, you can also build pulseaudio without daemon from source. The linuxy stuff only requires libpulse as build dependency, not the sound server. Thats what I did in Gentoo Linux, its a bit of a long walk compiling KDE from source, customization comes with a price tag, but I am happy with pipewire/wireplumber.

 

[Styrsven]

I have also good experience with pipewire in gentoo, but haven't found out how to make it usable in FreeBSD. Are you talking about your gentoo experience, or FreeBSD? I haven't found any traces of wireplumber in any port.

 

[hendrack]

I have also good experience with pipewire in gentoo, but haven't found out how to make it usable in FreeBSD. Are you talking about your gentoo experience, or FreeBSD? I haven't found any traces of wireplumber in any port.

I was talking about Gentoo, but last time I tried it 6 months ago on FreeBSD I compiled wireplumber manually without problems, so writing a port shouldn't be much of a problem. The problem was that I did not understand back then how to make the desktop environment I used XDG compliant (which pipewire/wireplumber sessions need). And I still don't entirely, but somehow elogind and sddm does the magic on Gentoo.

 

[sidetone]

Because PulseAudio uses LGPL2.1, it means it can be fixed in a way that's worthwhile for use with other open source software, that's not limited to GPL software. Dynamic linking of LGPL2.1 means that it can be used with other licenses, without interfering with them, except for programs under licenses which can't use combined derivatives. Alsa and libCanberra also use LGPL2.1: these are already used as libraries on FreeBSD, and a lot of their implementation has been cleaned up.

I used to think that LGPL was a one way street to GPL, but so can most permissive licenses. Ironically of the GPL licenses, LGPL3 can't be used in GPL2 series. It's better to embrace LGPL2.1, because it has compatibility for any program that uses its libraries, provided that it's through dynamic linking. A lot of the problem with LGPL2.1 isn't the license itself, it's that a lot of programs in it call for dependency hell. LGPL2.1 is a glue that when, what relies on it is kept separate, permissive licenses, file-based copyleft licenses, proprietary, and GPL (including LGPL3 series) code can use it through dynamic linking. LGPL2.1 is that link, where files that depend on dynamic linking to it don't cross contaminate each other: code that uses those libraries is considered a derivative.

From OpenBSD, there's a layer from PulseAudio to Sndio. In FreeBSD, this port is audio/pulse-audio-module-sndio, but the links to it aren't available. Not sure if this is what I hope it is. Either way, there needs to be a joint effort from the BSD's to fork and trim down PulseAudio, then maintain that for use with a separate program that's a layer to Sndio. BSD programs can make use of the shared libraries through dynamic linking.

The funny thing about PulseAudio, is that a lot of people agree it behaves in a faulty manner, and Poettering blamed Ubuntu because he thought they implemented it wrong. Then, he needs to figure how to make it work on Ubuntu, instead of blaming them, because maybe the problem is PulseAudio itself.
http://0pointer.de/blog/projects/pa-in-ubuntu.html, http://0pointer.de/blog/projects/jeffrey-stedfast.html. Maybe he tries to put PulseAudio into everything to support his ego.


Also, a reference from another thread to a rant of PulseAudio, then a comparison about a worry of PipeWire perhaps following that path.

If anyone is interested in reading a long rant by a Linux distro maintainer and his thoughts on pipewire, here is the thread.

When is enough, enough..? - LinuxMusicians

I personally have no complaint as long as the sound comes out of the speaker and goes in through the microphone.

 

[crypt47]

As one who had been tortured by PAudio for about 8-9 years, while on Enterprise Linux, I hate it as much as the inventor who obviously sold his soul, did a lot of harm and eventually showed his true face. Kill it with fire.

 

[Zare]

As one who had been tortured by PAudio for about 8-9 years, while on Enterprise Linux, I hate it as much as the inventor who obviously sold his soul, did a lot of harm and eventually showed his true face. Kill it with fire.

Inventor is not to blame, adopters are. And adopters might have their own reasons which may or may not be a good excuse to adopt.

Going for ALSA was not a good choice at all. They had to stick to OSS. Because it uses all standard UNIX interfaces, inner workings are abstracted and it was a good way to approach the problem of stability vs introducing features. F.e. multiplexed device access becomes a problem of kernel and automagically appears with the OS update, without a touch on userland code.

Then they didn't follow through with ALSA and broke their legs; effort moved to pulse which is not a good design for sound server. But it allows features.

IMO Linux kernel project is the problem. I like them and Linus's approach, but in this case they not interested to have a capable sound system in their software. I don't know how to describe this situation where there's a fat userspace 3rd party library/server needed to have a encircled end-user sound support in the whole OS.

In the end came "the inventor" and gave them (distributors) something that's not designed well but enables all the features they don't have and they really want. Same situation with pulse and systemd.

In the end, serious users utilize ALSA for hardware access and Jack for audio server and work around this situation.
The biggest casualty of this situation is Android which has had way worse audio I/O performance than iPhone. I am not aware of current situation and what ASP done to remedy this, but when you don't have a normal kernel audio system that's what you get.

 

[crypt47]

Inventor is not to blame, adopters are. And adopters might have their own reasons which may or may not be a good excuse to adopt.

Though I agree with you that Linux world lacks planning ahead and reinvents things over and over again, I admire Linus as an engineer and hate Pottering as engineer too. They are two opposites to me. One is brilliant in his decisions and personality, another one has long history of inventing software that works bad and his personality sux. This is very simple to me. Btw I also like Theo as an engineer though he was criticied for his personality. Know very little about him though. Saw some videos with him and I liked him.

 

[sidetone]

As one who had been tortured by PAudio for about 8-9 years, while on Enterprise Linux, I hate it

That's reasonable.

as much as the inventor

Not enough reason to hate him. Dislike him, and think lowly of him, ok. Suppose he's a narcissist.

who obviously sold his soul, did a lot of harm and eventually showed his true face.

He probably did, and his software has a bad reputation.

Inventor is not to blame, adopters are. And adopters might have their own reasons which may or may not be a good excuse to adopt.

It's his fault 100%. He created software, and since he wanted it to work because he promotes it, he didn't do anything to implement it on their design. He knows how to program, and claims to be a great software engineer, and he didn't deliver on implementing it on either Linux or anything else. It's his responsibility beyond simply creating it, and to make it work, since he showcases his junk software.

If it's not his responsibility to help implement it correctly, then he needs to stop promoting it. Argo, it's junk.

The problem is supposedly because he wanted his software inside the kernel, and being able to retain the main version on LGPL without being GPL, or not have to deal with maintaining a fork? His fault again. He's making demands that it go on to the lowest level without proving it. He could prove it by providing a fork of the Linux kernel, or even prove it on Minix. His software is supposed to be low level enough, that it shouldn't be on the API, then, that's his fault. He knows how Linux operates, if he can't make it work as intended beyond the API, or can't fork it within the kernel, that's his fault. Did he make a guide, on how to implement it on Linux, especially after it didn't work? No. It's his baby, so therefore, again, it's his fault. He complained. It doesn't work on anything, even on something as great as FreeBSD, which doesn't have the designed limitations of Linux, so then again, his fault. People on FreeBSD don't like it, after hearing about it, and half of the users would reject adopting it. If his software draws complaints from Linux Musicians, then he either has an obligation to make it work for them, drop his claims, or admit his software is crap.

If his software is close to the greatest ever, then he doesn't show it, except talk and blame. He didn't make an example including on Minix, Linux or any other type of kernel. He didn't write a guide on "how to implement it correctly". He didn't get on board on implementing it. He comes across as a narcissist who promotes his name brand and blames others, while not doing anything to make his brand software be implemented correctly, except make grandiose demands and blame.

If his demands are that it be implemented on the lowest level, perhaps so low that it goes into the Kernel, then he needs to provide his own kernel implementation, or make a separate API exclusively for his Poetteringware and LGPL software without GPL's restrictions with Linus' permission, or put it on an extension of Minix as a proof of concept.

Why do Sndio and JACK work, without making such grandiose demands?

 

[Zare]

sidetone Let me clarify that I don't want anyone in any way to think that I'm defending the person in question. I do not like his act.

We all know Red Hat pushed him and that's where Linux bent over. So they also take the blame.

The issue is that pulseaudio stack works on Linux desktop for desktop users. The issue is that person in question doesn't care about music on Linux, he is someone that wrote an audio stack without even being an audio enthusiast let alone engineer or musician. He reflected his mindset in his software, and someone else that holds $$$ decided that mindset is completely compatible with what modern Linux ought to be.