ALSA stop working, Jack Crashes

Installation & Configuration Linux
#1

Hello,
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:
Ardour:output_FL
Ardour:output_FR
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:
ardour:auditioner/audio_out 1
ardour:auditioner/audio_out 2

When I connected the
ardour:Master/audio_out 1
ardour:Master/audio_out 2
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!

Please help a new coming guy to the DAW magic!

#2

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.

#3

Yes I have indeed the 0.4.11-4.
Strange thing that it was working before I start add/remove programs. Maybe I didn’t have it installed at all?

#4

Perhaps not installed, or perhaps you still have 0.4.9 before removing and reinstalling.

#5

Just upgrade to 0.4.12!
But also for some reason master input and output has been reset and after enable it plays both on ALSA and JACK

#6

I have not seen that version yet, it looks like it was just released three days ago.

The bug entry has not been updated, but this note is in the release notes, so hopefully that fixed the problem:

  • Fixed a mistake in the code that would cause device reservation not to
    work properly
1 Like
#7

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.

#8

@x42
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.

#9

The timeout here is at most 5 seconds: (500 * 10ms):

  1. check if request-device process was started and printed success OK? → end
  2. sleep 10 ms
  3. count down from 500; jump to 1 or → error

… to any higher-priority request."

And by default the priority used is int32_max. Ardour does not use the -p option to specify a priority, so there can be no higher priority request.

If some other application holds the device, ARD waits for at most 4 second for the device to be released in order for ARD to acquire it.

#10

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.

#11

It’s not just dbus.

  1. Start external tool
  2. dbus request
  3. other application needs to respond, close the device, release resources
  4. reply via dbus
  5. print to stdout → inform Ardour

granted this usually takes a few ms, except pulse and others also use an internal 500ms delay to yield the device. Probably some safeguard for accidental requests causing audible hiccups.

#12

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.