The issue happens loading Timidity with timidity-daemon in a pulseaudio
environment. If Timidity is loaded from the user (on a terminal inside kde
session) everything works.

With daemon it's not that it doesn't work at all: it works only with exclusive
access.
If I launch some midi application (with output to Timidity) when I've not yet
used audio, the application works. But everything other I launch, it remains
muted until i close the midi application.

On the contrary, if I launch midi applications when something other is already
using audio (i.e. a simple browser on youtube, kaffeine etc), midi output is
muted.

Purging and reinstalling timidity and timidity-daemon packages does not help.


Here I paste a syslog output triggered by a "/etc/init.d/timidity restart".

21/4/2014 03:27:55      newton  pulseaudio[7290]        [pulseaudio] authkey.c:
Failed to open cookie file '/etc/timidity/.pulse-cookie': File o directory non
esistente
21/4/2014 03:27:55      newton  pulseaudio[7290]        [pulseaudio] authkey.c:
Failed to load authorization key '/etc/timidity/.pulse-cookie': File o
directory non esistente
21/4/2014 03:27:55      newton  pulseaudio[7290]        [pulseaudio] client-
conf-x11.c: xcb_connection_has_error() returned true
21/4/2014 03:27:55      newton  pulseaudio[7290]        [autospawn] core-
util.c: Home directory /etc/timidity not ours.
21/4/2014 03:27:55      newton  pulseaudio[7290]        [autospawn] lock-
autospawn.c: Impossibile accedere al lock di autospawn.
21/4/2014 03:27:55      newton  pulseaudio[7290]        [pulseaudio] main.c:
Failed to acquire autospawn lock

Dear Maintainer,

I spent a couple of hours debugging the issue the OP is seeing (and
which I am experiencing too), I looked at the source code of timidity
and puleseaudio and at how start-stop-daemon is used in
/etc/init.d/timidity and I think I've got an idea of what is going on,
especially wrt. this message:

  [pulseaudio] authkey.c: Failed to open cookie file '/etc/timidity/.pulse-cookie': File o directory non esistente
  ...

In the message above we see that the cookie file is looked up under
/etc/timidity/, there is an exact reason for that.

The story goes like this:

timidity is launched with the -Os option which means "Output to ALSA",
but this also means implicitly that it will be a pulseaudio client.

Now, pulseaudio check for an authentication cookie for its clients under
$HOME/.pulse-cookie

The fact here is that, when launched from /etc/init.d/timidity,
start-stop-daemon is used, and what makes the difference here is its
"--chuid timidity" option, this forces the HOME env variable to be the
one of the timidity user as set in /etc/passwd, and so pulseaudio picks
this HOME dir to build the path of the cookie file. However the timidity
user has no rights to write to /etc/timidity and so the cookie cannot be
created.

This is why the error message does not show up when launching timidity
from a shell without start-stop-daemon, because in this case the current
HOME of the user launching the program is  used, not the one of the
timidity user.

Now that we know what the problem is we can think to a solution:

  - change the home dir of the timidity user (e.g. with usermod) to
    /var/run/timidity where he actually has writing rights.

    This way the cookie can be created if not present already. I'd go
    for this solution, considering also that the home dir does not affect where
    the configuration file /etc/timidity.cfg is looked up for.

    The path of the configuration file is specified in the code as an
    absolute path:

      /* You could specify a complete path, e.g. "/etc/timidity.cfg", and
      then specify the library directory in the configuration file. */
      /* #define CONFIG_FILE "/etc/timidity.cfg" */
      #ifndef CONFIG_FILE
      #  ifdef DEFAULT_PATH
      #    define CONFIG_FILE DEFAULT_PATH "/timidity.cfg"
      #  else
      #    define CONFIG_FILE PKGDATADIR "/timidity.cfg"
      #  endif /* DEFAULT_PATH */
      #endif /* C

  - replace the "--chuid timidity" option with just a "--user timidity"
    and set the HOME variable from the SERVER_HOME variable which is in
    /etc/defaults/timidity.

    NOTE also that SERVER_HOME is currently not used at all.

    In this case I'd still set SERVER_HOME to /var/run/timidity for the
    reasons stated above.


Maybe this report can be merged with #694383 and maybe even some other one.

Let's fix this before Jessie!

Regards,
   Antonio

Package: timidity-daemon
Version: 2.13.2-40.1
Followup-For: Bug #745373
But it doesn't work, midi applications still require exclusive access.



I get these message  trying to start a midi application (but they are present
even when timidity works thanks to no concurrency)

Sep 25 02:07:16 newton pulseaudio[28411]: [pulseaudio] server-lookup.c: Unable
to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch
a dbus-daemon without a $DISPLAY for X11
Sep 25 02:07:16 newton pulseaudio[28411]: [pulseaudio] main.c: Unable to
contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a
dbus-daemon without a $DISPLAY for X11

You are right Valerio, my proposal merely fixes the error about not
finding the cookie.

I think the issue is that timidity is started at system boot, in
particular before pulseaudio, as the timidity user, while pulseaudio is
launched at login from the user session.

Maybe the definitive solution is to launch a timidity instance when the
user logs in.

I tried this way.

1. Remove /etc/init.d/timidity

2. Add a systemd user unit for timidity in a file
named /etc/systemd/user/timidity.service (a package would copy it
in /usr/lib/systemd/user instead), this is the unit file:

--------------------------------------------------------------------
[Unit]
Description=TiMidity++ Daemon
After=sound.target

[Service]
ExecStart=/usr/bin/timidity -iA -Os

[Install]
WantedBy=default.target
--------------------------------------------------------------------

3. Enable the unit for all users:
sudo systemctl --global enable timidity.service
a package could call that in a postinst hook.

Now log out from every user session and at the next login the timidity
instance should be loaded as the user itself and would play nicely with
pulseaudio, it will be seen as an alsa plugin.

Could you please test this way and let me know if it solves the problem
for you?

If so we could prepare patches for the timidity package, if the
maintainer agrees.

Ciao ciao,
   Antonio