I found this bug under Debian Release Critical Bugs relevant for testing.
Modern Linux audio stacks such as PulseAudio and PipeWire are designed
around per-user audio sessions rather than system-wide sound services.
As a result, running TiMidity++ as a system-wide daemon (whether via
SysV init or a system service) is no longer the recommended approach and
may not work correctly when the audio device is managed by the user's
audio session.
If required, users can start a TiMidity++ daemon manually with:
$ timidity -iA
For a more permanent setup, TiMidity++ can be started automatically at
login using a desktop autostart entry or a systemd --user service.
This is also the approach taken by other distributions. The OpenSUSE
README states:
When using pulseaudio the use of timidity as a system wide daemon is
discouraged,
because both pulseaudio and timidity need the same device
exclusively. However
timidity can be started as a daemon for the user to provide the MIDI
ports he/she
needs [...]
and recommends:
$ timidity -iAq -Oe -s 44100
Similarly, the Arch Linux wiki notes:
If you are using PulseAudio, that may also cause the service to fail.
You may want to
add the following command as an autostart program in your desktop
environment.
$ timidity -iA
Given the move towards per-user audio services, I don't believe
replacing the existing SysV init script with a system-wide systemd unit
would be an improvement. A systemd --user service would be more
appropriate for users who require a persistent TiMidity++ daemon. Such a
service file is, I believe, not commonly provided by Debian.
I hope this helps!
Kind regards,
Edmund
--
Edmund Lodewijks <[email protected]>
TZ: UTC+2 / GMT+2
