Re: Tragic State of FreeBSD Audio/Sound

Reply: Adrian Chadd : "Re: Tragic State of FreeBSD Audio/Sound"
Reply: Tomek CEDRO : "Re: Tragic State of FreeBSD Audio/Sound"
In reply to: Tomoaki AOKI : "Re: Tragic State of FreeBSD Audio/Sound"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>
Date: Sun, 26 Jul 2026 00:03:59 UTC
On Fri, 24 Jul 2026 19:32:39 +0900
Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:

> On Thu, 23 Jul 2026 16:32:49 -0700
> Kevin Bowling <kevin.bowling@kev009.com> wrote:
> 
> > On Thu, Jul 23, 2026 at 8:16 AM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
> > >
> > > On Tue, 21 Jul 2026 17:53:41 -0700
> > > Kevin Bowling <kevin.bowling@kev009.com> wrote:
> > >
> > > > On Tue, Jul 21, 2026 at 4:54 PM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
> > > > >
> > > > > On Tue, 21 Jul 2026 11:02:27 -0700
> > > > > Kevin Bowling <kevin.bowling@kev009.com> wrote:
> > > > >
> > > > > > On Tue, Jul 21, 2026 at 3:13 AM Gleb Popov <arrowd@freebsd.org> wrote:
> > > > > > >
> > > > > > > On Tue, Jul 21, 2026 at 12:57 PM Kevin Bowling <kevin.bowling@kev009.com> wrote:
> > > > > > > >
> > > > > > > > Only major outstanding work is pipewire/pipewire-pulse don't know how to
> > > > > > > > elevate their priority on FreeBSD and they really should be RT.
> > > > > > >
> > > > > > > What's needed for that?
> > > > > >
> > > > > > There are multiple issues:
> > > > > >
> > > > > > 1) Either a fix for the priority in PipeWire (SCHED_FIFO, don't set a
> > > > > > negative nice.level = -11 as a normal user) or something to make RTKit
> > > > > > work
> > > > > > 2) Use the process ID, _gettid().
> > > > > > 3) kldload mac_priority and user in realtime group
> > > > > >
> > > > > > > > Disable the stock PulseAudio autostart.
> > > > > > >
> > > > > > > Why, what's wrong with it?
> > > > > >
> > > > > > Try killing it with KDE running and see what happens.
> > > > >
> > > > > Putting others aside, if anyone want to use pipewire,
> > > > > pulseaudio shouldn't be installed alongside.
> > > >
> > > > Not quite yet.  You _need_ pulseaudio installed, because it defines
> > > > the API and ABI presently.  I'm not aware of any way to build pulse
> > > > software with i.e. pipewire as the bdep?
> > >
> > > When I've tried pipewire before (at the moment, wireplumber was
> > > NOT yet ported!), if pulseaudio is installed, something out-of-control
> > > from Mate DE (random apps) attempt to start pulseaudio and failed,
> > > even if pipewire was built with PULSEAUDIO enabled
> > 
> > > And IIRC, lost track with, but someone proposed splitting
> > > pulseaudio into core library part (maybe including headers
> > > for exposing API/ABI) and others to minimize dependencies
> > > in any of MLs or forums.
> > >
> > > Couldn't it help things?
> > 
> > Yes something that will probably be the end state, pulseaudio becomes
> > a bdep not an rdep.  But it is tricky.
> 
> Would be. Should need tricky plist handling like in x11/nvidia-driver
> and x11/linux-nvidia-libs. Or separating ports itself (not FLAVORize
> nor subpackage).
> 
> Maybe what's wanted would be:
>   *Core library part that have libpulse.so* and minimal headers
>    with mandatory share/* components.
> 
>   *Additional library part that have libpulse-*.so* and minimal
>    headers with mandatory share/* components for them.
> 
>   *Others with OPTION'ified ones.
> 
> And the latter ones should depend on the former one.
> 
> Making core part to be BUILD_DEPENDS or LIB_DEPENDS would
> depend on how the each dependant ports.
> Anything supporting libpulse only when it's installed at runtime
> would BUILD_DEPENDS, but anything always want libpulse to run would
> LIB_DEPENDS.
> 
> 
> > > Or pipewire to use distfiles for pulseaudio and install
> > > minimally required things as part of pipewire (assuming
> > > setting CONFLICTS_INSTALL)?
> > >
> > > Using distfile for other port to build is done on
> > > graphics/nvidia-drm-*-kmod* from the beginning Austin
> > > created them. (Used for builds only, though.)
> > >
> > >
> > > > > IIUC, pipewire was (at least initially) developed as
> > > > > the "successor" of pulseaudio and not intended to be installed
> > > > > alongside (choose one basis), and provides pulseaudio
> > > > > compatibility for apps not yet natively support pipewire.
> > > >
> > > > pipewire-pulse (included in our default install) is a stand in.
> > > > "Eventually," software should write directly to the pipewire graph.
> > > > But that will take a long time, if ever, because Pulse wasn't awful as
> > > > a client API (which is an easy problem space).
> > > >
> > > > Overall, pipewire is pretty nice.  It is analagous to something like
> > > > Apple's coreaudio.  It can do bitperfect with my sink, and you can
> > > > build graphs that avoid any SRC (Sample Rate Conversions) for proaudio
> > > > and such.  I've basically reached a local maxima on the sink to where
> > > > the kernel would need some work to support things like digital
> > > > passthrough or more pro audio oriented stuff, but I think it's
> > > > basiaclly feature complete for desktop audio.
> > >
> > > IIRC, pipewire uses 32bit float format internally.
> > > This can be avoided (at least some point and later), right?
> > > Even if it's not, actually affected format would be 32bit fixed
> > > (integer) only for PCM, if exponent part is kept zero.
> > > Supports for DSD (including DoP) would be the different story.
> > 
> > F32 is generally the right choice for desktop audio mixing, the same
> > used by macOS and Windows.  The argument against F32 is that it cannot
> > exactly represent S32 audio, which for listening is an academic note.
> > On the other hand F32 simplifies volume summation robustly because it
> > has a huge dynamic range.
> > 
> > PipeWire is ultimately graph based, if you want to avoid quantization
> > and SRC, it readily handles that graph if the hardware can match it.
> > My sink honors FreeBSD's bitperfect if told, and you can therefore
> > plumb streams that never touch software conversions if you ask for it.
> 
> Thanks for the clarification!
> 
> 
> > > > > And when I've tried pipewire a bit in early days it appeared
> > > > > in ports tree, I've experienced the same on Mate DE.
> > > > > The only workaround was to deinstall pulseaudio, but as
> > > > > pulseaudio is depended upon by many ports, upgrading ports
> > > > > forcibly pull pulseaudio in again unless nothing depending
> > > > > upon pulseaudio is upgraded.
> > > >
> > > > Read my instructions again and let me know how it goes.  All you need
> > > > to do is prevent pulseaudio from starting.  But it needs to remain
> > > > installed.
> > >
> > > I already had Hidden=true at the end of my
> > > ~/.config/autostart/pulseaudio.desktop, but pulseaudio is kicked
> > > and works. Something should be kicking it up without depending on
> > > ~/.config/autostart/pulseaudio.desktop.
> > >
> > > # Mate DE seems to set Hidden=true in desktop entries in
> > > # ~/.config/autostart/ is deactivated via its control panel.
> > > # And doesn't show *.desktop when NoDisplay=true.
> > >
> > > Anyway, when I've tried Pipewire before, Wireplumber didn't
> > > exist in ports, so tried again based on your suggestion.
> > > All existing and non-default configs for pipewire and pulseaudio
> > > are renamed not to be picked. (These configs for pipewire are
> > > assuming the absense of wireplumber and OSS support and should be
> > > harmful if picked for this test.)
> > >
> > > Note that, as already written, NoDisplay=true is flipped
> > > to false not to be missed by Mate, and Mate added
> > > X-MATE-Autostart-Delay=0 at the bottom.
> > > X-KDE-autostart-phase=1 was untouched (should be silently ignored).
> > > Exec= line is modified to fit my home directory.
> > >
> > > Even when disabling default Pipewire, pipewire-pulse,
> > > PulseAudio sound and WirePlumber, keeping PipeWire FreeBSD
> > > activated, didn't work on Mate.
> > > Pulseaudio is started. (I thought it would, as pulseaudio
> > > was always invoked even if disabled on autostart settings.)
> > >
> > > `killall pulseaudio`, wailt until all pulseaudio process quits,
> > > and manually invoking your script worked. Thanks!
> > >
> > > Maybe modifying script to kill pulseaudio first (and wait
> > > until all pulseaudio process quit) could help, but not yet
> > > tried. (Another possiblity would be to call the script
> > > from ~/.xinitrc before `exec`'ing Mate.)
> > 
> > I'm not an expert in these DEs and clearly, something needs to be done
> > to make pulseaudio less viral.
> 
> Me, too, never dug into Mate internals in depth (it clearly beyonds me).
> But I suspect some of core components are blindly attempting to
> communicate pulseaudio earlier than "autostart" are handled.
> 
> 
> > But can you clearly state whether you successfully stopped it, and if
> > pipewire and pipewire-pulse worked correctly with my sink?  It would
> > be good to know that the DE experience needs cleaning up, but that
> > this is foundationally working.
> 
> Currently when I could confirm pipewire start working fine is:
>   *in-base virtual_oss is in use
>   *your version of sink is installed
>   *pulseaudio is focibly started by Mate first
>   *after Mate DE started up but no sounds are played yet,
>    kill pulseaudio with killall
>   *run your script (edited to match my environment) manually
> 
> Tests are done on stable/15 only for now.
> Original version of the sink by shkhln is not tested for now
> (interested in, though).
> 
> If starting your script via ~/.xinitrc and pulseaudio is
> forcibly invoked by Mate later, killing pulseaudio doesn't help.
> In this case, re-running your script after that didn't help, too.
> Not sure why, though, at least currently.
> 
> Regards.

An additional info.
Not a fix, nor clarification of root cause, but as a workaround,
adding

  pgrep -U "$(id -u)" -x pulseaudio >/dev/null && killall pulseaudio
  sleep 5

lines between the conditional for XDG_RUNTIME_DIR and first pgrep line
in your start-pipewire-freebsd script is working for me.

5 seconds of sleep may be tuned. Just set because `killall pulseaudio`
took 1 to 3 seconds depending on underlying workloads by seeing repeated
`ps | fgrep pulseaudio`, so add 2 second mergin (as I don't think
this 1-3 secs is not yet have valid statistical backgrounds).

If killall doesn't return until confirming all detected matching
processes are finished, this guard does NOT have any sense, but
unfortunately, it seems to return just after the signal was sent.

Regards.


> > Regards,
> > Kevin
> > 
> > > Regards.
> > >
> > > > > So, I think
> > > > >   *Make pulseaudio and pipewire conflicting each other
> > > > >   *Add USES to pull in whichever pulseaudio or pipewire
> > > > >   *Add DEFAULT_VERSIONS for it to choose whichever as
> > > > >    dependency
> > > > > would be needed.
> > > > >
> > > > > I imagine something like this.
> > > > >   https://forums.freebsd.org/threads/porting-x11libre-to-freebsd.98455/page-5#post-711350
> > > > >
> > > > >
> > > > > Not sure about current state (at the moment, OSS supports
> > > > > was not yet provided and I've become too tired to play
> > > > > around ALSA configurations, thus, abandoned further tests),
> > > > > but if pulseaudio is still needed to build pulseaudio
> > > > > compatibility supports, using distfiles for pulseaudio
> > > > > but do NOT depend on pulseaudio port would be needed
> > > > > to achieve the above.
> > > > >
> > > > > Regards.
> > > > >
> > > > >
> > > > > > > >    if [ -z "$XDG_RUNTIME_DIR" ]; then
> > > > > > > >        export XDG_RUNTIME_DIR="/var/run/user/$(id -u)"
> > > > > > > >        mkdir -p "$XDG_RUNTIME_DIR"
> > > > > > > >        chmod 700 "$XDG_RUNTIME_DIR"
> > > > > > > >    fi
> > > > > > >
> > > > > > > This is done by pam_xdg, you shouldn't do that yourself.
> > > > >
> > > > >
> > > > > --
> > > > > Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>
> > >
> > >
> > > --
> > > Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>
> 
> 
> -- 
> Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>


-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>