FS#50122 - [fluidsynth] service doesn't work with user pulseaudio

Attached to Project: Community Packages
Opened by Javier Domingo Cansino (txomon) - Thursday, 21 July 2016, 22:32 GMT
Last edited by David Runge (dvzrv) - Tuesday, 05 February 2019, 11:33 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Ray Rashif (schivmeister)
David Runge (dvzrv)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:

Nowadays, fluidsynth is being distributed with a service that gets installed in /usr/lib/systemd/system, with the idea of running it as a daemon. The problem when running it as part of the system is that pulseaudio driver won't work.

I would

Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:
Write the following in /etc/conf.d/fluidsynth:

SOUND_FONT=/usr/share/soundfonts/FluidR3_GM2-2.sf2
AUDIO_DRIVER=pulseaudio
OTHER_OPTS='-r 48000'

Start the service, and something like this will appear:

$ systemctl status fluidsynth
● fluidsynth.service - FluidSynth Daemon
Loaded: loaded (/usr/lib/systemd/system/fluidsynth.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Thu 2016-07-21 23:55:52 CEST; 13min ago
Process: 12017 ExecStart=/usr/bin/fluidsynth -is -a $AUDIO_DRIVER $OTHER_OPTS $SOUND_FONT (code=exited, status=0/SUCCESS)
Main PID: 12017 (code=exited, status=0/SUCCESS)

Jul 21 23:55:52 mymachine systemd[1]: Started FluidSynth Daemon.
Jul 21 23:55:52 mymachine fluidsynth[12017]: fluidsynth: error: Failed to create PulseAudio connection
Jul 21 23:55:52 mymachine fluidsynth[12017]: Failed to create the audio driver
Jul 21 23:55:52 mymachine fluidsynth[12017]: FluidSynth version 1.1.6
Jul 21 23:55:52 mymachine fluidsynth[12017]: Copyright (C) 2000-2012 Peter Hanappe and others.
Jul 21 23:55:52 mymachine fluidsynth[12017]: Distributed under the LGPL license.
Jul 21 23:55:52 mymachine fluidsynth[12017]: SoundFont(R) is a registered trademark of E-mu Systems, Inc.


Copying the file from /usr/lib/systemd/system to /usr/lib/systemd/user should solve the problem, and allow to start the service like systemctl --user start fluidsynth

With the following status output:

systemctl --user status fluidsynth
● fluidsynth.service - FluidSynth Daemon
Loaded: loaded (/usr/lib/systemd/user/fluidsynth.service; disabled; vendor preset: enabled)
Active: active (running) since Fri 2016-07-22 00:20:59 CEST; 4s ago
Main PID: 13990 (fluidsynth)
CGroup: /user.slice/user-1000.slice/user@1000.service/fluidsynth.service
└─13990 /usr/bin/fluidsynth -is -a pulseaudio -r 48000 /usr/share/soundfonts/FluidR3_GM2-2.sf2

Jul 22 00:20:59 mymachine systemd[8758]: Started FluidSynth Daemon.
Jul 22 00:20:59 mymachine fluidsynth[13990]: fluidsynth: Using PulseAudio driver


My guess would be to copy the file because you may want to have it as a system wide service with alsa, or user pulseaudio, so both services are required.
This task depends upon

Closed by  David Runge (dvzrv)
Tuesday, 05 February 2019, 11:33 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with 1.1.10
Comment by Johannes Sasongko (sjohannes) - Thursday, 26 April 2018, 08:52 GMT
As of fluidsynth 1.1.10 (already in Arch), the service file has moved from system to user, and you can start it with "systemctl --user start fluidsynth". I think that sort of fixes this issue?

Both '-a alsa' and '-a pulseaudio' seem to work fine with this setup.
Comment by Bachsau (Bachsau) - Monday, 15 October 2018, 07:37 GMT
The best solution would be to provide an additional session based service file. People can then choose which one to activate to either run it system wide or in a user session. As PulseAudio also runs in the user session, this would be the perfect solution for PulseAudio users.
Comment by David Runge (dvzrv) - Tuesday, 05 February 2019, 11:33 GMT
To run fluidsynth system-wide (as root) was not safe and should never have been packaged that way (apart from being disfunctional), which is why I helped upstream to implement the systemd user service.

Loading...