Daemon is broken with MIDI & WINE

[satheevrin]

I used to be able to play really ancient programs with music to them, but ever since this updated past 2.3.0 , its broken the way the Daemon functions. To repro, simply do the following...

On Arch, of course

sudo pacman -S fluidsynth lib32-fluidsynth soundfont-fluid

edit SOUND_FONT=/usr/share/soundfonts/FluidR3_GM.sf2 in /etc/conf.d/fluidsynth

create the symbolic link: sudo ln -s FluidR3_GM.sf2 /usr/share/soundfonts/default.sf2

systemctl --user enable fluidsynth.service

reboot...

Launch an old game through WINE (visual novel, space cadet). The Daemon reports that the service is running, but MIDI music is not playing. With the newest versions, every I had to do systemctl --user restart fluidsynth.service in order to get MIDI music to work in WINE

the intended behavior is for the Daemon to work at boot in WINE and you should not have to restart the service.

Downgrading to v 2.3.0 has restored this Daemon to its intended behavior where I would go into WINE, launch an app and the MIDI music would play

[derselbst]

Pls. share the logs of the fluidsynth daemon after boot and after first manual restart.

[satheevrin]

Where is the log saved?

[satheevrin]

I figured it out. Here are the logs

The first file is fluidsynth at boot and running WINE to play a game with MIDI:

fluidsynthboot.txt

the second file is fluidsynth ater having to forcibly restart the daemon using systemctl --user restart fluidsynth.service and then receiving sound in WINE while playing the same game with MIDI music:

fluidsynthreboot.txt

[derselbst]

Ok, great. Given all the errors it surprises me that it works at all. Esp, because:

error: Failed to find an audio format supported by alsa

i.e. fluidsynth cannot output any sound to ALSA, and:

warning: Failed to allocate a synthesis process

i.e. it cannot allocate a voice. Ergo, you should get no sound at all. To investigate further, pls.

1. Post the exact commandline that the fludisynth daemon is started with (it should be in the fluidsynth.service, but there may be additional variables included, which are expanded from I don't know where).
2. Once you've found the commandline of the fluidsynth daemon, add the --verbose flag, restart the daemon and post its logs again.
3. Post the output of the aplay -l command.
4. Post the output of the aplay -L command.
5. Post the output of ps aux | grep fluidsynth (this should also show the full commandline, in case you can't figure it out in step 1, but I need this command to see if there might be multiple fluidsynth instances running on your machine).

[satheevrin]

Okay, I think this is what you wanted:

fluidsynth.txt

I'm not entirely sure what I'm looking at (I'm still a linux noob, but it sounds like you do!!), but as I said before, this has happened on two machines of a fresh Arch install. I noticed that this is listing my hardware, but i don't know if that''s relevant or not.My hardware is different for each machine, i should note.

I had to downgrade to 2.3.0-2 on my main, only then did it behave correctly as it intended through WINE

[derselbst]

Thanks for the logs. I'm confused though. Why are there no error: Failed to find an audio format supported by alsa and Failed to allocate a synthesis process. messages in the log anymore? And I wouldn't have expected the ALSA lib *** log messages to see.

Anyway, the line Default ALSA Output (currently PipeWire Media Server) looks interesting. From fluidsynth's Arch package changelog we can see that pipewire support was indeed added in version 2.3.0-2. (Even though there was a change in 2.3.1-2 but I don't think it's related).

Saying that, if pipewire opens ALSA exclusively, fluidsynth might not be able to open the default soundcard and therefore, we would see error from the previous two logs. In fluidsynth 2.3.1 we've changed the creation order between pipewire and fluidsynth, see #1177. I.e. since 2.3.1 pipewire is started before fluidsynth, therefore potentially blocking ALSA.

So, to verify that this is the problem, pls. reinstall fluidsynth 2.3.3, then open the fluidsynth.service and change the line

fluidsynth/fluidsynth.service.in

Line 5 in 6721e92

After=pipewire.service

to Before=pipewire.service. Save, reboot and try if this resolves the issue.

If it does, in order to permanently fix the issue, you could:

• uninstall pipewire, if you don't use it, or
• modify the fluidsynth.service (or the env file containing the $OTHER_OPTS) to add the -a pipewire option to fluidsynth, so that fluidsynth acutally uses pipewire as sound output rather than directly going via ALSA. And don't forget to change it back to After=pipewire.service

[satheevrin]

I do use pipewire, actually, but I never thought that could be the problem. So, I guess what you're saying is maybe the Arch people messed this up?

I upgraded back to the current. it looks like you wanted me to modify the systemd unit, but from what im seeing it was already like this in my file:

[Unit]
Description=FluidSynth Daemon
Documentation=man:fluidsynth(1)
After=sound.target
After=pipewire.service

[Service]
# added automatically, for details please see
# https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort
ProtectSystem=full
ProtectHome=read-only
ProtectHostname=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectKernelLogs=true
ProtectControlGroups=true
# end of automatic additions
# required in order for the above sandboxing options to work on a user unit
PrivateUsers=yes
Type=notify
NotifyAccess=main
EnvironmentFile=/etc/conf.d/fluidsynth
EnvironmentFile=-%h/.config/fluidsynth
ExecStart=/usr/bin/fluidsynth -is $OTHER_OPTS $SOUND_FONT

[Install]
WantedBy=default.target

I guess that confirms it then, so, maybe I just have to live with the downgrade until the Arch people decide to update this again? (I'm seeing that was somewhere around June). It's no big deal, I just wanted to confirm that something with my end wasn't corrupted.

[derselbst]

So, I guess what you're saying is maybe the Arch people messed this up?

No, I'm not saying this. I've asked you to try changing a line in that file. But you have just posted the file, which is not helpful at all.

Pls. carefully read the section starting with "So, to verify..." again and let me know if I wasn't specific enough.

[satheevrin]

Alright, sorry, I misunderstood you. I changed that line like you asked me, but it didn't make a difference..

"[Unit]
Description=FluidSynth Daemon
Documentation=man:fluidsynth(1)
After=sound.target
Before=pipewire.service"

[derselbst]

Hm, you could still add the -a pipewire to the fluidsynth daemon. If this doesn't help, I'm out of ideas...

[satheevrin]

Alright, that's my last goal for now then...could you tell me how to do that? Modifying the daemon that is with that argument?

[derselbst]

Well, you either add the mentioned flag to the ExecStart of the fluidsynth.service, or you open one of the EnvironmentFiles, and add the mentioned flag to the $OTHER_OPTS env variable.