08-29-2021, 10:32 PM
(This post was last modified: 08-29-2021, 10:34 PM by moonwalkers.)
(08-29-2021, 12:46 PM)JGkn Wrote: Sound Server-3: PulseAudio v: 15.0 running: no
Sound Server-4: PipeWire v: 0.3.33 running: yes
K, that's probably where the problem lies - my script is geared towards PulseAudio and does not have any provisions for PipeWire. The core idea of the script is to first make the permissions on the audio device such that no new process can open it, then stop all the existing processes (which on a system using PulseAudio should be only the PulseAudio user session instance), then do the bind/unbind, and then restart the audio server. I haven't yet played with PipeWire--PulseAudio works well enough for my needs that I don't feel like fiddling with a less mature option, even if theoretically superior--so I cannot give you ready-to-go solution. You'll have to figure out yourself how to make sure PipeWire doesn't use the sound card while the driver is being rebound. But my guess is you might be able to simply replace the pulseaudio.s(ervice|ocket) with the equivalent PipeWire systemd units, assuming they still run in user session context and not system-wide context. If they run in system-wide context you should be able to get rid of all the dbus-related shenanigans.
This message was created with 100% recycled electrons