If PulseAudio restarts, Fluidsynth stays running but no audio is produced

[DestyNova]

FluidSynth version

FluidSynth runtime version 2.1.1
Copyright (C) 2000-2020 Peter Hanappe and others.
Distributed under the LGPL license.
SoundFont(R) is a registered trademark of E-mu Systems, Inc.

FluidSynth executable version 2.1.1
Sample type=double

(installed in Ubuntu 20.04 via apt)

Describe the bug

FluidSynth is running as a daemon using systemctl, using the PulseAudio driver. Everything works fine until the PulseAudio service is restarted (I'm not sure why PulseAudio crashes, but it's almost certainly nothing to do with FluidSynth).
Afterwards, FluidSynth produces an error message on stdout, but keeps running and never produces audio again until I manually restart it.

Expected behaviour

FluidSynth should terminate immediately with a non-zero exit code if the output driver fails. This would allow systemctl (or other daemon scripts) to restart FluidSynth and start a connection to the new instance of PulseAudio (if it's running).

Actual behaviour

The following message is written to stdout:

fluidsynth: error: Error writing to PulseAudio connection.

FluidSynth stays running but produces no more audio until manually killed and restarted.

Steps to reproduce

1. Start PulseAudio (e.g. with systemctl --user start pulseaudio or pulseaudio --start)
2. Start FluidSynth with the pulseaudio output driver (e.g. in my case fluidsynth -is -g 2 -a pulseaudio -m alsa_seq -r 48000 /usr/share/sounds/sf3/MuseScore_General_Lite.sf3)
3. Kill and restart PulseAudio.
4. Watch the FluidSynth stdout for an error, and try playing a MIDI file (e.g. aplaymidi -p129:0 test.mid assuming FluidSynth is using that MIDI port address).

Thanks for the great work on FluidSynth, by the way.

[derselbst]

I just reviewed the code and this turned out to be a bigger job to implement: Currently, the audio driver has no way of talking back to the client whether everything is still ok. One just calls new_fluid_audio_driver which may or may not create a background thread (in case of Pulseaudio it does). And this thread keeps running until signaled to terminate upon delete_fluid_audio_driver. A possible way of solving this could be to introduce a fluid_audio_driver_is_alive() function and polling it from time to time. Or giving clients a callback when something breaks. The first approach sucks. The second is nicer, but will become problematic for callback-driven APIs like jack. Because if jack crashes, you'll never get a callback again. So one would need a watchdog or something...

You'll probably be faster to make systemd also kill fluidsynth when it detected pulseaudio crashed and then restart both.

[mawe42]

Could we maybe let the pulse driver retry creating the server connection if a write failed? So instead of hard failing, do a soft fail and reconnect, maybe with a configurable retry period?

[DestyNova]

Thanks @derselbst -- I was indeed able to configure systemd to depend upon PulseAudio and restart when it restarts, by adding the following to /etc/systemd/user/multi-user.target.wants/fluidsynth.service:

[Unit]
PartOf=pulseaudio.service

I think it would be best if the driver could try to reconnect like @mawe42 suggested, but I appreciate it may be awkward with the way the driver and client interact right now.