On Thu, Jul 23, 2026 at 8:16 AM Tomoaki AOKI <[email protected]> wrote: > > On Tue, 21 Jul 2026 17:53:41 -0700 > Kevin Bowling <[email protected]> wrote: > > > On Tue, Jul 21, 2026 at 4:54 PM Tomoaki AOKI <[email protected]> > > wrote: > > > > > > On Tue, 21 Jul 2026 11:02:27 -0700 > > > Kevin Bowling <[email protected]> wrote: > > > > > > > On Tue, Jul 21, 2026 at 3:13 AM Gleb Popov <[email protected]> wrote: > > > > > > > > > > On Tue, Jul 21, 2026 at 12:57 PM Kevin Bowling > > > > > <[email protected]> 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. > > 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. > > > > 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. 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. 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 <[email protected]> > > > -- > Tomoaki AOKI <[email protected]>
