Breaks pipewire

[pothos]

FluidSynth version

2.3.0

Describe the bug

When fluidsynth installs its systemd user service unit, it takes hold of /dev/snd/* nodes and pipewire won't create sinks/sources for the soundcard, breaking the system sound.

Expected behavior

Don't interfere with pipewire when installed, if usage is exclusive, make this clear in the service unit dependencies

Steps to reproduce

Install fluidsynth and pipewire on Debian sid

Additional context

More details in https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/364

To fix this I suggest the following addition to fluidsynth.service.in:

Conflicts=pipewire.service
Before=pipewire.service

The idea is that either fluidsynth.service is running and pipewire not or vice versa but never both. Users could then stop pipewire and start fluidsynth.

[derselbst]

Thanks for the report. Could you pls. let me know which audio driver fluidsynth is using when you run it as service?

[pothos]

Should be the default, I didn't configure anything

[derselbst]

Ok, so ALSA acquires the /dev/snd/* files and when you try to run pipewire, which wants to open the same in exclusive mode it obviously fails. Understood. In this case I'll just apply the change you suggested and ship the fix with 2.3.1. Thanks!

[pinkflames]

Is Before=pipewire.service really a fix here? I'm no systemd --user expert but to me it seems like a guarantee that this will always cause the /dev/snd/* conflict. Also note that the legacy pulseaudio.service is probably also affected for the same reason.

If the alsa backend is supposed to work via the PulseAudio or PipeWire plugin for ALSA it would make sense to start after these two user services: pipewire-pulse.service pulseaudio.service. pipewire-pulse.service could be replaced with pipewire-session-manager.service but then you must beware that Debian has that replaced with wireplumber.service and may not notice that they need to edit fluidsynth.service, too.

Alternatively the default for the user unit could be changed to the pulseauido backend, which is more likely to not have such undesired behaviors.

[pothos]

Before= and After= have the same effect with Conflicts=, they just mean that the units can't run at the same time. If we actually don't need the Conflicts= then yes, After= makes sense.

[derselbst]

I would like to have this in upcoming 2.3.1, but I keep being busy and I found no time testing the effect of Before= or After= / with or without Conflicts=. It would be helpful if you could let me know your preference.

[pinkflames]

It might help to clarify that I'm myself not a user of fluidsynth.service - I merely became aware of the issue from the PipeWire side, so I do not know how to test or use the daemon.