Arch Linux

Description:

When using a system with plain ALSA (i.e. no JACK, no PulseAudio), timidity -Os eventually crashes or runs into an infinite loop with "cannot get status", given enough load.

Steps to reproduce (alternative 1):

* Get a nice soundfont, e.g. "soundfont-sgm" (AUR).
* Run timidity with a sufficiently complex MIDI file, e.g.

$ timidity -a -A 70 -p256 -EwpvseToz -EFchorus=n -EFreverb=f,63 -x"soundfont /usr/share/soundfonts/SGM-V2.01.sf2" -B 1,1 -Os -s44100 --verbose=2 some_complex_midi_file.mid

* Wait for it to crash with "cannot get status". Loading the CPU with some other processes might help. For me, it crashes in the first few seconds.

Steps to reproduce (alternative 2):

* Alternatively, run it as an ALSA sequencer client, e.g.

$ timidity -a -A 70 -p256 -EwpvseToz -EFchorus=n -EFreverb=f,63 -x"soundfont /usr/share/soundfonts/SGM-V2.01.sf2" -B 1,1 -Os -s44100 -iA --realtime-priority=6 --verbose=2

* Now, try to interact with timidity, e.g. by using rosegarden, and give it some load by using your MIDI keyboard, playing back a file, etc. For me, even a simple program change can trigger this issue.
* BEWARE! The --verbose=2 will spam your logs with "cannot get status" as soon as this issue is triggered.
* Even if you do not set verbosity, whenever it runs into that issue, you will get high CPU load and an unusable timidity that needs to be restarted, only to fail again later.
* Note that I am used to running timidity -iA as root so --realtime-priority=6 would work, but it does not affect the outcome.
* Note that setting -B to higher values only delays the practically inevitable "crash".

This is what I found out about this issue, and how:

$ git clone https://git.code.sf.net/p/timidity/git timidity-git
$ cd timidity-git
$ grep -Hrn -C3 -F 'cannot get status' . # points to timidity/alsa_a.c

Then, in timidity/alsa_a.c near line 548, we see a related function call to snd_pcm_status which is probably this one:

https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga32891eaac37741728a9b23027012c892

There, it reads: "The function is thread-safe when built with the proper option."

So maybe some compiler flags or the build process is broken?

# pacman -Qi timidity # output shortened for brevity:
Name : timidity++
Version : 2.15.0-5
Architecture : x86_64
Build Date : Thu 03 Dec 2020 07:21:41 PM CET

I remember that it worked flawlessly back in summer 2020, then it started to fall apart at some point in autumn. It got worse near the end of 2020 (although this might be due to the config dir change I noticed only recently).

$ asp checkout timidity++
$ cd timidity++
$ git log

The git log pretty much reflects the experienced changes in the past as I remember them, so it is probably due to commit d38a575bf526ea9a7abc744f45717a2537b8b2f0, or a more recent change.

Note: I know that using JACK might be more appropriate for some use cases, but I am not used to it (as I did not find the time), and there might be other parts of timidity that are still affected by these compilation issues as well (assuming that this is where the issue come from). In the past and with my setup, timidity as an ALSA sequencer client used to work with delays short enough to make live input from a MIDI keyboard possible, even without a realtime kernel, and even with -B1,1. (I tried some rt tweaks but to no avail.) At worst, I got buffer underruns, but it never "crashed".