On Thu, Mar 13, 2025 at 10:42 AM Fabian Greffrath <fabian@xxxxxxxxxxxxx> wrote:
Dear systemd developers,
I have a release-critical bug filed against the fluidsynth package in
Debian [1] that I don't quite understand. The bug is especially against
the fluidsynth.service file (attached to this mail).
To provide some background, fluidsynth is a MIDI daemon that can work
with different sound backends, most notably pulseaudio and pipewire.
Users report that the fluidsynth daemon is loaded before pulseaudio and
thus blocks the audio device, so that pulseaudio can only work on
"dummy output". Some users can reproduce this, others don't (including
myself). My guess is that I am using pipewire instead of pulseaudio and
so the correct order of the services is already granted by the
"After=pipewire.service" line. My next best guess is that expanding the
line to read "After=pipewire.service pulseaudio.service" will fix the
issue for both groups of users (one of the participants of the bug also
suggested this but got no replies).
That should work, at least as long as both fluidsynth.service and pipewire(or pulseaudio).service are both enabled to run on startup (well, at logon).
I don't really recall how pulseaudio is set up – does it ever use "delayed" socket activation (where only pulseaudio.socket starts at first, and the .service runs on demand)? The After= alone wouldn't have any effect in such setups, and an additional Wants= would be needed.
Does Debian support having both Pulseaudio and PipeWire installed at the same time? If not, then I *think* you could list both of them in Wants= (in addition to After).
The next strange issue is that reportedly even the Debian-gdm system
user already loads the fluidsynth daemon, blocking it during the
opening of the session for the actual human user.
When Fluidsynth does direct device access, it should do what PulseAudio and Pipewire do, i.e. release the devices when the systemd-logind session becomes no longer "active".
I don't think gdm needs to play MIDI, though, so as a workaround I would add a drop-in with:
[Unit]
ConditionUser=!Debian-gdm
or some other condition that's appropriate, so that it wouldn't start *at all* for gdm. (Maybe alternatively link ~gdm/.config/systemd/user/fluidsynth.service to /dev/null, like "systemctl --user mask" would create.)
My guess here is that
the "WantedBy=default.target" line should rather get replaced by
something like "WantedBy=multi-user.target"?
It is a per-user service, so default.target is correct. The per-user systemd instances don't have "multi-user.target" (they only run in multi-user mode in the first place).
--
Mantas Mikulėnas
