On Sat, 25 Jul 2026 21:09:07 -0700 Adrian Chadd <[email protected]> wrote:
> Hi y'all, > > On Sat, 25 Jul 2026 at 17:04, Tomoaki AOKI <[email protected]> wrote: > > > > > 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. > > Just to be clear, like, this is ok for "test out replacing pulseaudio" > but it can't be expected to work. Yes, at least currently, it's tests for me in preparation for forcible switch from pulseaudio to pipewire. > If y'all would like to see this happen, I highly recommend someone > dedicate / fund the work > to figure out splitting up pulseaudio into a build vs run dep, and all > the hijinx required to > provide pipewire or pulseaudio via some runtime mux. Sound server related things would be difficult to handle. Some would say "why not integrating into sndio? Shouldn't it be the BSD-way?". Some would say "jack is justice! May all switch to jack!". And someone like me would say "pulseaudio was the only working way that allowed sharing sounds between multiple apps including ones lacking direct supports for in-base OSS when I started to use sounds on FreeBSD". And among others, IIUC, pipewire was developed as the successor of pulseaudio, intending to supercede it. So at some point upstream could drop supports for existing pulseaudio codes. If anyone possible forks and keep on maintaining as XLibre guys is doing for xorg, it would be OK. But if not, the transition would be forced once unfixed vulnerabilities are found on pulseaudio. Of course, it would be nice if: *upstream merges mimimal required codes of pulseaudio for making pipewire-pulse independent from pulseaudio repo or *anyone possible (technically and in work loads) pops in to do the job but there could be someone requesting forcible switch to other sound servers (would be sndio or jack, currently) instead. > I can't imagine anyone supporting this bait and switch :-P It's the severe problem. I've lost track with this, but found (again) this old and looong thread in Forums. https://forums.freebsd.org/threads/removing-hard-dependencies-on-pulseaudio-and-splitting-ports.81398/ Regards. > -adrian -- Tomoaki AOKI <[email protected]>
