View Issue Details

IDProjectCategoryView StatusLast Update
0009270ardourbugspublic2023-03-06 05:18
Reporterznbm Assigned To 
Status newResolutionopen 
PlatformRyzen 5 2600OSManjaro, Kernel 5.14.21-2OS Version(any)
Product Version7.3 
Summary0009270: ALSA I/O halts with Behringer UM2
DescriptionI use a Behringer UM2 USB audio interface, and when I want to use my Alesis V49 MIDI controller during playback, I use the ALSA backend.
After some arbitrary duration -- usually between several seconds and several minutes --
playback suddenly halts and is replaced by a low-frequency square wave sound playing in the right channel.
After another ten seconds, the audio system stops completely and must be restarted, usually resulting in the same issue.
At this point, "The current operation is not possible because of an error communicating with the audio hardware." errors are common for many operations.
Steps To ReproduceCreate a new Ardour session, using ALSA as the backend and the UM2 as the input and output device.
Create a new MIDI bus with a MIDI-controlled instrument.
Play a loop range with some audio in it.
Play MIDI notes, whether from a MIDI controller, the piano roll, or a MIDI region.
Wait several minutes for playback to halt.
Additional InformationThis issue occurs reliably with ALSA, and also with JACK, effectively making these backends unusable.
Notably, it does not occur with Pulseaudio, which works perfectly (but lacks MIDI I/O support).

The issue might occur when MIDI is not involved at all, but I haven't reproduced it.

Changing the "Record Monitoring" does not seem to help.
Changing the MIDI system to "ALSA sequencer" seems to make the error occur faster.
Changing it to "None" does not seem to completely prevent the error -- other MIDI sources can still cause the issue.

No relevant output appears on stdout or stderr.

I assume the square wave sound is caused by the UM2's firmware when it encounters an error.

Personally, I'd prefer if this issue were fixed by adding MIDI I/O support to the Pulseaudio backend.
High-latency Pulseaudio MIDI input would much better fit my workflow than low-latency ALSA MIDI input,
even if the latter worked reliably.
Tagsalsa, hangs, i/o failure, usb



2023-03-06 00:43

administrator   ~0027429

What buffer size(s) were you using with each backend?


2023-03-06 01:07

reporter   ~0027430

Typically (and most recently) 1024 samples, which I think is the default. Pulseaudio also uses 1024 samples.
For what it's worth, stdout also informs me that all of the MIDI buffers are "of size 8192".

I tested it just now and found some very interesting behavior:

When starting ALSA with 8192 samples, Ardour gives a "Could not configure Audio/MIDI engine with given settings." error popup.
Then it opens the "Starting Audio/MIDI Engine" splash anyway, but at least it doesn't hang.

When starting ALSA with 4096 samples, Ardour crashes with this message on stderr:
** (ardour-7.2.0:382037): ERROR **: 16:04:12.547:
unhandled exception (type std::exception) in signal handler:
what: negative distance in timecnt constructor

When starting ALSA with 1024 samples, playback runs properly for about five seconds, then halts as described above.

When starting ALSA with 256 samples, the audio instantly halts... but the tone is higher pitch, and it seems to flicker on and off randomly for a while.
The audio engine doesn't actually seem to halt, and I can get snippets of playback to play between the tone.

When starting ALSA with 64 samples, the audio instantly halts, and the tone is even higher pitch. Its waveform seems to waver slightly every second or so.

At this point I don't think the audio I hear is actually a square wave, nor is it probably generated by the UM2. But it's always sounded the same, no matter what audio I'm playing back.


2023-03-06 01:34

administrator   ~0027431

It is very unlikely that PulseAudio is using 1024 at the hardware level. When using PulseAudio, you should open a terminal window, and run this command:

cat /proc/asound/card0/pcm0p/sub0/hw_params

substituting "card0" with the right cardN value for the device you are using. My guess is that the real problem is that your computer cannot support the buffer sizes you're using; PulseAudio works because under the hood it uses a much larger buffer size.

The exception message is compeltely unrelated to what we're discussing (though it is a bug that should be tracked down.


2023-03-06 02:03

reporter   ~0027432

You're right -- `$ cat /proc/asound/CODEC/pcm0p/sub0/hw_params` yields
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 44100
buffer_size: 88200

On an unrelated note, JACK seems to work much better than ALSA, provided the server is started via QjackCtl.
The issue appears immediately at very small sizes like 64, but at 256 I haven't seen it happen at all.
I recall it also being problematic in the past, but for now it seems like a good workaround.
Thanks for the help.


2023-03-06 03:20

administrator   ~0027433

to compare the Ardour- and QJackctl- started instances of JACK, start each of them and while one is running, in a terminal window run this command:

ps aux | grep jackd

Compare the two commands yourself or post them here and I can comment.


2023-03-06 04:39

reporter   ~0027434

Launching JACK from Ardour's Audio/MIDI Setup window has always yielded a "Could not reconnect to Audio/MIDI engine" error, regardless of "Device", "Driver", "MIDI System", etc.
I always assumed this was an issue with Manjaro's packaging of Ardour, since it prints something like this to stderr:
JACK command line will be: /usr/bin/jackd -t 200 -p 2048 -R -T -X alsarawmidi -d alsa -n 2 -r 48000 -p 1024 -d hw:CODEC,0 -X alsarawmidi
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Automatic start of JACK server is disabled at configure time
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Regardless, using a QjackCtl-provided server (`/usr/bin/jackd -dalsa -dhw:CODEC -r48000 -Xseq`) works fine.

On an unrelated note, I remembered out how this error manifests when using JACK.
It doesn't occur randomly; instead, it reliably happens immediately after exporting and normalizing audio.
It also hangs Ardour, although fortunately the exported file is unaffected.
Let me know if I should make a new issue for that behavior.


2023-03-06 05:18

administrator   ~0027435

The export hang is a semi-known problem, and I believe it does not happen with builds from (you could try a demo version at no cost, parallel installed with the Manjaro one).

The only obvious difference with the two JACK commands are that Ardour has been told use the ALSA Raw MIDI API when starting JACK, whereas QJackctl is using the ALSA Sequencer MIDI API. I'd be surprised, however, if that explained the difference. But fundamentally, I'd suspect a packaging/build error, indeed.

Issue History

Date Modified Username Field Change
2023-03-05 20:41 znbm New Issue
2023-03-05 20:41 znbm Tag Attached: alsa
2023-03-05 20:41 znbm Tag Attached: hangs
2023-03-05 20:41 znbm Tag Attached: i/o failure
2023-03-05 20:41 znbm Tag Attached: usb
2023-03-06 00:43 paul Note Added: 0027429
2023-03-06 01:07 znbm Note Added: 0027430
2023-03-06 01:34 paul Note Added: 0027431
2023-03-06 02:03 znbm Note Added: 0027432
2023-03-06 03:20 paul Note Added: 0027433
2023-03-06 04:39 znbm Note Added: 0027434
2023-03-06 05:18 paul Note Added: 0027435