0.3.55 breaks audio device request mechanism

• PipeWire version (pipewire --version): 0.3.55
• Distribution and distribution version (PRETTY_NAME from /etc/os-release): Fedora Linux 36 pipewire-0.3.55-2.fc36
• Desktop Environment: KDE
• Kernel version (uname -r): 5.18.11-200.fc36.x86_64

Description of Problem: After updating to 0.3.55 pipewire maintains exclusive access to the audio device, even when Ardour or jackd requests to use the audio device.

How Reproducible: repeatable

Steps to Reproduce:

1. Attempt to start Ardour using the ALSA backend or attempt to start jackd

Actual Results: Ardour error that the ALSA backend cannot be started, or jackd error starting with report that pipewire is using the audio device.

Expected Results: Pipewire will gracefully stop using the audio device so that audio applications can open for exclusive access

Additional Info (as attachments):

• pw-dump > pw-dump.log:pw-dump.log

moved from pipewire#2557 (moved)

PipeWire does not do device reservation, it's the session manager that does that. Are you running wireplumber?

I think it's the wireplumber update that broke it.. I can reproduce.

Yes to wireplumber, although I am using the Fedora default configuration, I do not really understand yet how to configure wireplumber, and obviously was mistaken about where the responsibilities are split betweeen wireplumber and pipewire. wireplumber-0.4.11-2.fc36.x86_64

I did confirm that downgrading to wireplumber 0.4.9 corrects the problem found. I have not submitted any wireplumber issues before, is it considered part of the pipewire project? Or should this be in a different repo issue list?

I see that there is a separate wireplumber repository. Can this issue be moved there, or should I resubmit in that repository issue list?

Any progress on this? Fedora 37 release is coming up soon, and I am afraid that 0.4.9 will no longer be available in the release repository after the new release, forcing an upgrade to the broken version.

Have you tried 0.4.12? There was a device reservation bug in 0.4.11 that was fixed.

added area::device-management type::bug labels

Have not tried 0.4.12 yet, just saw that it was released a few hours after I added that comment. Will check that version and report back.

0.4.12 does correct the problem. Is there any reason that it would take wireplumber longer time than previously to release the reservation? Both jackd and Ardour ALSA direct backend failed to acquire the reservation the first time it was requested, but when retried both applications did successfully acquire the reservation. That seems like the applications are probably timing out too quickly on the request. I can put in a request to at least those two applications to increase the timeout if it is likely that the delay will be close to deterministic so that I can give a definitive request for maximum time to wait.

closed