Pipewire instead of pulseaudio

In FreeBSD, yes. In Linux, no. This is due to the OSS mixer functionality in the FreeBSD kernel that Linux doesn't have. But note that there are limitations with that mixer, IIRC an example is 16 max applications at the same time.
If you are playing audio from 16 different applications at the same time, you either have mutant hearing or a problem! :p
 
If you are playing audio from 16 different applications at the same time, you either have mutant hearing or a problem! :p

Well, paused applications count - mplayer, vlc, xine. And pulseaudio and jack each count as one. If you try hard enough you can run out.
 
Were any of you able to get pipewire up and running? When I run pipewire & pipewire-pulse and then play a youtube video, the server hangs permanently, even connecting to the server via pavucontrol doesn't work.

I installed Pipewire from FreeBSD ports.
 
Has anybody used the jackd compatibility in pipewire yet?

The pipewire-carrying Linux distributions simply start a jackd.
 
i have replaced pulseaudio with pipewire on linux before when it wasnt the default


i used wireplumber

freebsd install wireplumber and pipewire

Code:
sudo pkg install wireplumber pipewire

from my notes

wireplumber makes things quite easy! If you just want to replace PulseAudio with Pipewire, enable the media session service and restart and that’s all!!

On linux
For JACK client, run command:

Code:
sudo cp /usr/share/doc/pipewire/examples/ld.so.conf.d/pipewire-jack-*.conf /etc/ld.so.conf.d/

And then

Code:
sudo ldconfig

obviously would need to change the paths and command for freebsd for the above code

verify pipewire is working

Code:
pactl info

It should output Sound server: PulseAudio (on PipeWire x.x.x) indicates Pipewire is in use as sound ouput.
 
I migrated my two HTPCs with Kodi from Xubuntu to FreeBSD (Mate) to get rid of Pulseaudio, as it caused many audio issues (no pass-through, lagging and even some wow&flutter). On my hardware, FreeBSD with OSS allows pass-through (up and to Dolby TrueHD-Atmos and DTS:X) and PCM 7.1 with up to 192 kHz sampling rate. If I install Kodi from Packages (with Pulseaudio) I have no audio whatsoever in Kodi.

Interesting. I use Kodi from packages (quarterly) and the pulseaudio option is off, so no pulseaudio installed. You may want to look for another package that pulls in pulseaudio, and decide whether that's needed on the HTPC.

Nice to see Dolby TrueHD-Atmos and DTS:X supported by passthrough - this is HDMI passthrough, not SPDIF, right?
If by chance you get to login on one of the HTPCs, could you provide me the output of sysctl hw.snd.verbose=2; cat /dev/sndstat while playing one of those formats?
Question popped up in the review of a recent kernel change.

Has anybody used the jackd compatibility in pipewire yet?

The pipewire-carrying Linux distributions simply start a jackd.

I suppose this is a different Jack compatibility scheme compared to what you mentioned before, pipewire replacing the Jack library? Does it use a Jack sink like the pulseaudio one?
 
I suppose this is a different Jack compatibility scheme compared to what you mentioned before, pipewire replacing the Jack library? Does it use a Jack sink like the pulseaudio one?

No, the is only the library replacement scheme. The demon itself does not speak jack protocol. I didn't run it yet.
 
No, the is only the library replacement scheme. The demon itself does not speak jack protocol. I didn't run it yet.

From ArchWiki it seems there's both a Jack replacement library and a Jack sink. The first makes Jack clients connect to the pipewire server, the latter can be used to run pipewire on top of native Jack (much like you use pulseaudio now).

Not totally convinced of the pipewire architecture, at least not for audio. They'll have to support the pulseaudio and Jack APIs forever, because their native one isn't suitable for normal applications. And the decoupling of wakeup frequencies / period buffer sizes is not as good as our current OSS in-kernel buffering.

Anyway, lots of improvements over pulseaudio, which is nice.
 
From ArchWiki it seems there's both a Jack replacement library and a Jack sink. The first makes Jack clients connect to the pipewire server, the latter can be used to run pipewire on top of native Jack (much like you use pulseaudio now).

Well it is a Linux audio subsystem, so by law they had to make it chaotic.

But I don't read that wiki page as PW implementing the jack server-side API. Also it implements the client-side API so that you can run PW on top of jackd.
 
Well it is a Linux audio subsystem, so by law they had to make it chaotic.

Not chaotic at all - the master plan is to play Tower of Hanoi with audio stack components, through DBUS. And isn't that what we all secretly want?

But I don't read that wiki page as PW implementing the jack server-side API. Also it implements the client-side API so that you can run PW on top of jackd.

There's two paragraphs there, the one about "JACK Clients" references a replacement library for Jack clients. If Jack clients can connect to pipewire through that, it means the library converts Jack API calls to pipewire API (not through Jack IPC). Also this method is mutually exclusive with pipewire on top of Jack, see package conflicts with pipewire-jack-client.
 
Has anybody used the jackd compatibility in pipewire yet?

The pipewire-carrying Linux distributions simply start a jackd.

Had a go at it yesterday, newest pipewire from ports (1.2.1_1). It detects jackdbus, but then segfaults immediately.
So not quite there yet ;-)
 
sysctl hw.snd.verbose=2; cat /dev/sndstat
Sorry I did not see this until now. Here is the output while playing a movie with TrueHD 7.1 Atmos from Kodi in Passthrough mode (over Nvidia HDMI audio device):

Code:
pcm0: <NVIDIA (0x0081) (HDMI/DP 8ch)> on hdaa0  (1p:4v/0r:0v) default
    snddev flags=0x200002e7<SIMPLEX,AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC,PRIO_WR>
    [pcm0:play:dsp0.p0]: spd 192000, fmt 0x08800400, flags 0x4000a108, 0x00000004
    interrupts 133849, underruns 0, feed 133849, ready 0 [b:32768/16384/2|bs:32768/16384/2]
    channel flags=0x4000a108<TRIGGERED,BUSY,HAS_VCHAN,VCHAN_ADAPTIVE,PASSTHROUGH>
    {userland} -> feeder_mixer(0x08800400) -> {hardware}
    pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp0]: spd 192000, fmt 0x08800400, flags 0x1000112c, 0x00000001, pid 3833 (kodi-x11)
    interrupts 0, underruns 0, feed 133849, ready 65536 [b:0/0/0|bs:65536/4096/16]
    channel flags=0x1000112c<RUNNING,TRIGGERED,SLEEPING,BUSY,HAS_SIZE,VIRTUAL>
    {userland} -> feeder_root(0x08800400) -> {hardware}
    pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp1]: spd 8000, fmt 0x00100008, flags 0x10000000, 0x00000000
    interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:0/0/0]
    channel flags=0x10000000<VIRTUAL>
    {userland} -> feeder_root(0x00000000) -> {hardware}
    pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp2]: spd 8000, fmt 0x00100008, flags 0x10000000, 0x00000000
    interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:0/0/0]
    channel flags=0x10000000<VIRTUAL>
    {userland} -> feeder_root(0x00000000) -> {hardware}
    pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp3]: spd 8000, fmt 0x00100008, flags 0x10000000, 0x00000000
    interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:0/0/0]
    channel flags=0x10000000<VIRTUAL>
    {userland} -> feeder_root(0x00000000) -> {hardware}
 
Hint (thanks to the maintainer): if audio/jack fails to build as outlined below, then force a rebuild of audio/opus.

Code:
…
[ 77/181] Linking build/jackd
11:00:30 runner ['c++', 'common/Jackdmp.cpp.1.o', 'dbus/audio_reserve.c.1.o', 'dbus/reserve.c.1.o', '-o/wrkdirs/usr/ports/audio/jack/work/jack2-1.9.22/build/jackd', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-Lcommon', '-L/usr/local/lib', '-L/usr/local/lib', '-L/usr/local/lib', '-ljackserver', '-lopus', '-lpthread', '-lsamplerate', '-ldbus-1', '-lm', '-fstack-protector-strong', '-Wl,--no-undefined']
ld: error: undefined reference due to --no-allow-shlib-undefined: __memcpy_chk@FBSD_1.8
>>> referenced by /usr/local/lib/libopus.so

ld: error: undefined reference due to --no-allow-shlib-undefined: __memset_chk@FBSD_1.8
>>> referenced by /usr/local/lib/libopus.so
c++: error: linker command failed with exit code 1 (use -v to see invocation)

* Node /wrkdirs/usr/ports/audio/jack/work/jack2-1.9.22/build/common/memops.c.7.o is created more than once (full message on 'waf -v -v'). The task generators are:
  1. 'audioadapter' in /wrkdirs/usr/ports/audio/jack/work/jack2-1.9.22/common
  2. 'oss' in /wrkdirs/usr/ports/audio/jack/work/jack2-1.9.22
If you think that this is an error, set no_errcheck_out on the task instance
Waf: Leaving directory `/wrkdirs/usr/ports/audio/jack/work/jack2-1.9.22/build'
Build failed
 -> task in 'jackd' failed with exit status 1:
        {task 11417245020256: cxxprogram Jackdmp.cpp.1.o,audio_reserve.c.1.o,reserve.c.1.o -> jackd}
['c++', 'common/Jackdmp.cpp.1.o', 'dbus/audio_reserve.c.1.o', 'dbus/reserve.c.1.o', '-o/wrkdirs/usr/ports/audio/jack/work/jack2-1.9.22/build/jackd', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-Lcommon', '-L/usr/local/lib', '-L/usr/local/lib', '-L/usr/local/lib', '-ljackserver', '-lopus', '-lpthread', '-lsamplerate', '-ldbus-1', '-lm', '-fstack-protector-strong', '-Wl,--no-undefined']
*** Error code 1

Stop.
make: stopped in /usr/ports/audio/jack
=>> Cleaning up wrkdir
===>  Cleaning for jackit-1.9.22_2
build of audio/jack | jackit-1.9.22_2 ended at Sat Aug 24 12:00:31 BST 2024
build time: 00:00:12
!!! build failure encountered !!!
%
 
Sorry I did not see this until now. Here is the output while playing a movie with TrueHD 7.1 Atmos from Kodi in Passthrough mode (over Nvidia HDMI audio device):

Code:
pcm0: <NVIDIA (0x0081) (HDMI/DP 8ch)> on hdaa0  (1p:4v/0r:0v) default
    snddev flags=0x200002e7<SIMPLEX,AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC,PRIO_WR>
    [pcm0:play:dsp0.p0]: spd 192000, fmt 0x08800400, flags 0x4000a108, 0x00000004
    interrupts 133849, underruns 0, feed 133849, ready 0 [b:32768/16384/2|bs:32768/16384/2]
    channel flags=0x4000a108<TRIGGERED,BUSY,HAS_VCHAN,VCHAN_ADAPTIVE,PASSTHROUGH>
    {userland} -> feeder_mixer(0x08800400) -> {hardware}
    pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp0]: spd 192000, fmt 0x08800400, flags 0x1000112c, 0x00000001, pid 3833 (kodi-x11)
    interrupts 0, underruns 0, feed 133849, ready 65536 [b:0/0/0|bs:65536/4096/16]
    channel flags=0x1000112c<RUNNING,TRIGGERED,SLEEPING,BUSY,HAS_SIZE,VIRTUAL>
    {userland} -> feeder_root(0x08800400) -> {hardware}

It seems the sample rate is matching what TrueHD 7.1 Atmos provides, while the sample format is set to 7.1 channel AC3. But this is a variable bitrate format anyway. Since FreeBSD audio doesn't know about the bitrate, I suppose the HDMI protocol has some way to throttle the audio stream to what is consumed by the end device.

Anyway, appreciated. Let's be happy that it works!
 
And my axe.
And my bow, though I'm just an amateur archer (I'll step down if we get a better one). What else do we need?

About all I've done with pulseaudio is learn how to kill it (don't remember if restarts were involved) to fix audio issues. Maybe it added something and/or worked fine somewhere but OSS seemed fine since I came to FreeBSD and I haven't seen any observed benefit from it myself as a desktop user.
 
14.1-RELEASE brought significant improvements.
I don't think it has anything to do with the OS release, but thankfully several ports have changed the default options and disabled pulseaudio option or dropped it as a dependency (but some have re-enabled it for whatever dumb reason...).


I'm still building my own packages though, and I have OPTIONS_UNSET+=PULSEAUDIO in make.conf as well as audio/pulseaudio in poudriere.d/blacklist, forbidden and restricted...
 
… thankfully several ports have changed the default options and disabled pulseaudio option or dropped it as a dependency …

Maintainers of www/ungoogled-chromium were visited by the Priest of the Church of Minimalism.

1724670711016.pngThankfully, relevant ports have all audio backends enabled by default.

1724672736255.png
 
It seems the sample rate is matching what TrueHD 7.1 Atmos provides, while the sample format is set to 7.1 channel AC3. But this is a variable bitrate format anyway. Since FreeBSD audio doesn't know about the bitrate, I suppose the HDMI protocol has some way to throttle the audio stream to what is consumed by the end device.

Anyway, appreciated. Let's be happy that it works!
192 kHz and 7.1 is the maximum that the Nividia card supports and also reflect the maximum specs of HDMI (according to Wikipedia). Kodi sees the streams as "Raw" in pass-through mode. The end device then figures it out. Interestingly enough, the FreeBSD system passes through DTS:X properly which many media players (e.g. Nvidia shield) cannot do.
 
With 14.1-RELEASE?



Detail of an issue ;-)
Not fought it in 14.1 and I was late to the game coming to 14 and don't think I've fought against pulseaudio in that short timeframe. I think there were at least a couple times on 13 (if not many) but definitely times on previous versions; such timeframes are kind of a blur in my head. My 'go kill pulse' script appears to be creation dated 2019 and used to be needed regularly enough (usually for firefox) that I made a script as that was easier than me remembering what to kill or how. `.pulseaudio -k` seemed to be the main part though I had some other things I tried doing too.

As someone who normally builds their own copy from ports, I'm okay with the ports tree unconditionally having build dependencies on optional dependencies but prefer that optional run dependencies that can be dynamically runtime detected be excluded from showing as a dependency. I don't normally mind optional runtime dependencies being activated if it makes a program have more features/capabilities as long as there is no severe detriment to the stability and performance of the program. Pulseaudio was definitely making things worse and not better at least on my system.
 
Back
Top