Development of Zrythm is still in the alpha phase, and this can be seen, for example, in regular crashes. These crashes were triggered by various actions in our lab, such as selecting the color for a track or cutting sections of audio. Crashes were also observed simply when the application ran for a longer period of time. The problems were always associated with a flood of xruns on the JACK back end. A look at top in the terminal showed a challenging 300 percent CPU load and more for Zrythm in this situation. Every now and then the computer even hung completely. In some cases, Zita-a2j running in the background, which makes MIDI devices that are registered in ALSA available to JACK went zombie. Since this small server is necessary for normal operation of Ubuntu Studio, a reboot of the computer was the easiest way out.

Bear in mind that JACK is a professional audio system. It's about real-time performance with guaranteed maximum latency of less than five milliseconds. Since all this power is supposed to be available to simple user accounts, you have to grant this option as a special privilege to the audio user group in /etc/limits.conf and the kernel has to support this setting.

In our lab, we used Ubuntu Studio 20.04 with its special low-latency kernel. This gives applications that use JACK in far more than a web browser and 3D games the ability to push the system limits. Doing so can completely exhaust RAM, but there are limits for the CPU, so there is always a little bit left in reserve for calling up a rescue console and typing killall -9. In Zrythm's case, though, we were forced to press the reset button in our lab after 20 minutes of waiting in one case.

When we asked Theodotou for tips on how to avoid this kind of disaster, he explained in the interview that he has tried to contain errors of this kind. They rarely occur, and he fixes the problem as soon as possible once a user brings it to his attention. Users should therefore report scenarios of this kind with logs and backtraces and describe steps for reproducing the error. The Zrythm project uses the Sourcehut developer platform for bug reports. Bug reports [5] can also be sent directly from within the application. The bug report system is well maintained, and I'm pretty optimistic that reports are not just dumped into a black hole.

Whatever else you do, it is a very good idea to save your work regularly – your next action could prematurely end the session. Automatic fielding of data loss in case of crashes worked quite well in our lab. It was almost always possible to restore the project completely from a backup, including the last actions that you did not save manually.

However, this assurance comes at a price: Zrythm creates a backup every minute. To do so, it simply creates a copy of the current state with all audio files in ~/.local/share/zrythm/projects/<Project>/backups/. There doesn't seem to be a cleanup mechanism, which meant that this directory grew to a staggering 90GB in our lab – and that was only with three small projects, each of them less than two minutes long. You will want to delete the backups manually from time to time. In addition, the interval can be extended in the settings.