Having been hit by this on Buseter Testing before, I did some
investigation. Here are my findings:

Conditions for this bug to appear are:

   * timidity-daemon is installed
   * timidity service (from the timidity-daemon package) is enabled or
     timidity gets started by hand
   * No midi device is provided by the kernel

Only if all of these these conditions are fulfilled at the same time,
this comes into effect.

A quick test on Stretch with the timidity service enabled did not reveal
the bug. However, timidity was not running after boot, and I didn't find
the reason why. After starting it by hand, pulseaudio got unusable, just
like it does on Buster. So my guess is that the bug was actually present
in Stretch, it just did not show due to timidity not starting properly
at boot.

A removal of timidity-daemon on affected systems is sufficient. It is
set to "Suggests" instead of "Recommends" with timidity as of 2.14.0-8,
so the majority of people who install games or music programs that pull
in timidity will no longer be affected.

People who will be affected are those that got timidity-daemon installed
in Stretch by the "Recommends" dep, and then upgraded to Buster. Even an
apt autoremove will keep timidity-daemon installed.

One way to escape this bug is to have a midi device available in the
system, which can also be snd_virmidi. But I don't consider this a clean
solution, because it will probably interfere for people who have real
midi hardware.

What other options do we have? Simply keep it as-is and document it in
the the upgrade manual? Or do we have some mechanism available that
would remove timidity-daemon if it was installed automatically? Any
other ideas?

Reply via email to