On Thu, Mar 13, 2025 at 10:42 AM Fabian Greffrath <fab...@greffrath.com> 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
