On Thu, Mar 13, 2025 at 11: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). > > 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. My guess here is that > the "WantedBy=default.target" line should rather get replaced by > something like "WantedBy=multi-user.target"? >
>From your description it is user service in which case multi-user.target simply does not exist for user services. default.target is usually correct. > I really don't know, especially because I cannot reproduce the issue in > the first place. Could you please do me a favour and review the > fluidsynth.service file so I can recommend a fix for this to upstream? > What's wrong with adding After=pulseaudio.service (or whatever this user service is called)? It also has After=sound.target and I would tentatively expect that sound stacks order themselves Before=sound.target, but probably that is not the case. > Thank you very much! > > - Fabian > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053245