I was messing around with pulseaudio and pipewire. I thought it was good idea to remove pipewire and install pulseaudio. Anyway as I was installing and removing packages I lost the ability to hear anything from my previously recorded audio using ALSA.
After removing every pulseaudio package and installing again pipewire (I think/hope that I 've done it right) it 's still not working.
But I installed qpwgraph and I opened it
When I start it no sound but in the qpwgraph I saw that there is a box Ardour with just 2 outputs named:
Connected to my soundcard’s:
Analog Stereo 1/2:Playback_FL
Analog Stereo 1/2:Playback_FR respectively.
By switching to JACK a big Ardour block is created (still no sound) and in my soundcard is connected two outputs from ardour named:
When I connected the
to my soundcard I could hear my recording again.
When I restarted the program though all the connections are lost.
Also when I disconnect from jack ardour crashes.
I know there are a lot and I am willing to seperate the issues if it is more comfortable and easy to be managed and replied!
What version of wireplumber do you have installed? There is a bug in wireplumber 0.4.11 which unfortunately prevents requesting the ALSA device from working properly. I have not seen any fix available yet, so I believe that if you have 0.4.11 installed you will either have to find a 0.4.9 package to install instead, or you will have to use the pipewire-jack implementation with Ardour.
I confirmed that wireplumber 0.4.12 does fix the original problem, although it seems that wireplumber takes slightly longer to release the reservation than Ardour expects. With both jackd and Ardour ALSA backend the request to acquire the device failed on first attempt, but when I retried right away the request succeeded on the second attempt. If I can find out what causes the delay and whether it is somewhat predictable, I may submit a request for Ardour to extend the timeout when requesting a device reservation.
I noticed in the Ardour ALSA backend code there is a wait parameter of 500 with a comment that it waits “5 seconds” but in the request_device.c code has a comment at the beginning that “Without the -w option, ’ ARD_PROG_NAME ’ yields the device after 500ms.”
Is that 500 at line 2477 of alsa_audiobackend.cc actually 500 ms, i.e. 0.5 seconds, and not 5 seconds? I don’t know how long dbus requests usually take to complete, so no idea if 0.5 seconds is reasonable, or is off by an order of magnitude like the backend comments indicate.
After looking at the code it appears that the 500 is 500 wait loops of 10ms each, so 5000ms, i.e. 5 seconds as the comment correctly indicates. 5s seems like a huge amount of time for dbus to respond, so not sure why the request failed at first attempt. I don’t know what dbus tracing tools are available, I will need to look for information on that to see what is happening on the dbus side.