[Slackbuilds-users] TiMidity++ as daemon, failure to connect to pulseaudio

[Didier Spaier]

Hello,

On 07/24/2018 07:24 AM, Kyle Guinn wrote:
> On 7/23/18, Rubén Llorente <porting at use.startmail.com> wrote:
>> Hello.
>>
>> The instructions provided in TiMidity++'s Slackbuild page for running
>> it as a daemon/alsa sequencer don't work.
>> https://slackbuilds.org/repository/14.2/audio/TiMidity++/
>>
>> rc.timidity will have the daemon started, but it will fail to generate
>> any sound output.
>>
>> I suspect that, when I start a desktop session, a pulseaudio instance
>> under the privileges of my user gets started. TiMidity++, running as a
>> root daemon, is not authorized to inject sound into Pulseaudio because
>> it is a different user than my desktop one.
>>
>> Could somebody else reproduce this problem and confirm it?
>>
>> A possible solution would be to run pulseaudio as a system wide daemon,
>> but that is too problematic.
>>
>> Another possible solution would be to apply something like this:
>> https://wiki.archlinux.org/index.php/PulseAudio/Examples#Allowing_multiple_users_to_use_PulseAudio_at_the_same_time
>>
>> My suggestion, if this issue is reproducible and shown to be caused for
>> the above reasons, is to update the slackbuild in the following ways:
>>
>> 1- Recommend the creation of a timidity user for running as a daemon.
>> Running the daemon as root is a bit dangerous.
>> 2- Modify rc.timidity for starting the daemon under the privileges of
>> said user.
>> 3- Recommend the solution posted in the Arch wiki. I have yet to try it,
>> and is also a bit dangerous because it allows system-wide access to the
>> daemon run by the user to everybody in the system, unless you take
>> additional messures (such as changing the permissions of the socket?)
>>
>> Trivial solution is to start timidity with the desktop session, running
>> with the privileges of the user sitting in front of the machine.
> 
> I'm listed as maintainer, but I don't think I've ever had a need to
> use it in daemon mode, and all my systems are mostly PulseAudio-free.
> So I'm not in a great position to test this.  If you find a good
> solution, would you like to take over maintenance and submit an
> update?  It's been a while since I've needed to use this program and
> I'm sure the script could use some love.
> 
> -Kyle

I have had a similar issue issue with Slint, because we need to start
the espeakup daemon early in the boot process so that users can have
speech before logging in, thus this daemon has to be started as
root. The solution we applied is to use portaudio as audio backend for
espeakup. portaudio itself relies on alsa, so to avoid that in turn alsa
redirect on pulse we remove from /etc/asound.conf these lines:
pcm.default pulse
ctl.default pulse

Conversely we include in /etc/pulse/default.pa these lines:
load-module module-alsa-sink device=dmix
load-module module-alsa-source device=dsnoop

This way a regular users can use applications relying on pulse, and
both alsamixer and pavucontrol work.

I never used TiMidity++, but I see in ./configure --help that
"--with-default-output=" offers many options. among which alsa, alib,
portadio and jack. Maybe try one of these, or maybe just change
default.pa and asound.conf as above would suffice?

It is easy the check if starting the TiMidity++ daemon spawns pulse,
just issue after it starts this command:
ps -ef|grep pulse

HTH,

Didier