<div dir="ltr"><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Mar 13, 2025 at 10:42 AM Fabian Greffrath <<a href="mailto:fabian@greffrath.com">fabian@greffrath.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear systemd developers,<br>
<br>
I have a release-critical bug filed against the fluidsynth package in<br>
Debian [1] that I don't quite understand. The bug is especially against<br>
the fluidsynth.service file (attached to this mail).<br>
<br>
To provide some background, fluidsynth is a MIDI daemon that can work<br>
with different sound backends, most notably pulseaudio and pipewire.<br>
<br>
Users report that the fluidsynth daemon is loaded before pulseaudio and<br>
thus blocks the audio device, so that pulseaudio can only work on<br>
"dummy output". Some users can reproduce this, others don't (including<br>
myself). My guess is that I am using pipewire instead of pulseaudio and<br>
so the correct order of the services is already granted by the<br>
"After=pipewire.service" line. My next best guess is that expanding the<br>
line to read "After=pipewire.service pulseaudio.service" will fix the<br>
issue for both groups of users (one of the participants of the bug also<br>
suggested this but got no replies).<br></blockquote><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The next strange issue is that reportedly even the Debian-gdm system<br>
user already loads the fluidsynth daemon, blocking it during the<br>
opening of the session for the actual human user.</blockquote><div><br></div><div>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".</div><div><br></div><div>I don't think gdm needs to play MIDI, though, so as a workaround I would add a drop-in with:</div><div><br></div><div style="margin-left:40px">[Unit]</div><div style="margin-left:40px">ConditionUser=!Debian-gdm</div><div><br></div><div>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.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">My guess here is that<br>
the "WantedBy=default.target" line should rather get replaced by<br>
something like "WantedBy=multi-user.target"?<br></blockquote><div><br></div><div>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).</div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>