Re: Tragic State of FreeBSD Audio/Sound

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.


> 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>