View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009270 | ardour | bugs | public | 2023-03-05 20:41 | 2023-03-06 05:18 |
| Reporter | znbm | Assigned To | |||
| Priority | high | Severity | major | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | Ryzen 5 2600 | OS | Manjaro, Kernel 5.14.21-2 | OS Version | (any) |
| Product Version | 7.3 | ||||
| Summary | 0009270: ALSA I/O halts with Behringer UM2 | ||||
| Description | I 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 Reproduce | Create 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 Information | This 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. | ||||
| Tags | alsa, hangs, i/o failure, usb | ||||
|
|
What buffer size(s) were you using with each backend? |
|
|
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. |
|
|
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. |
|
|
You're right -- `$ cat /proc/asound/CODEC/pcm0p/sub0/hw_params` yields ```access: MMAP_INTERLEAVED 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. |
|
|
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. |
|
|
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. |
|
|
The export hang is a semi-known problem, and I believe it does not happen with builds from ardour.org (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. |
| 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 |
