Timidity daemon doesn't play nice with pulse audio

[Niels Kjøller Hansen]

Binary package hint: timidity

I had timidity installed on gutsy when I upgraded to Hardy. On gutsy, it was natural for me that timidity daemon wouldn't play when other applications were using the sound output (i.e. playing music in Totem or Rhythmbox).

The same thing is the case with Hardy. But timidity can play midi-files fine from the command-line when listening to music from Rhythmbox. So I figure that this should be do-able from the daemon as well. I have been poking around the /etc/init.d/timidity script looking for options, but I am not good enough at this, so I was hoping someone else maybe could look at the problem?

* Release: Hardy, updated april 1st 2008
* Package version: 2.13.2-19ubuntu1
* Current behaviour: Timidity daemon does not play along other music applications, but timidity commandline tool does.
* Expected: Timidity daemon works in the same way as the command-line tool.

[gborzi (gborzi)]

The problem with timidity++ as a MIDI server with pulseaudio is explained here: http://blog.flameeyes.eu/articles/2007/11/24/problems-running-timidity-with-pulseaudio
A possible solution, besides adding the root user to the pulse-access group is to start timidity as a server when a Login to gnome is made, i.e. open System -> Preferences -> Sessions and add an entry in the Startup Tab with
/usr/bin/timidity -iA -Os
The problem is that when logging out timidity is not terminated, so at the next login two timidity servers will be running.

[gborzi (gborzi)]

I have solved the above mentioned problem of killing timidity on gnome logout by adding this line
killall timidity
in /etc/gdm/PostSession/Default just before the "exit 0" line.

[NY00123 (ny00)]

Reproduced here.
Fixed using gborzi's hints (for both login and logout).

Furthermore, I've edited /etc/init.d/timidity and added the line "exit 0" in the beginning,
so it shouldn't start the unnecessary daemon as root.

[e-eng (e-eng-deactivatedaccount)]

On Intrepid Ibex I have the same problem, timidity does not connect to pulseaudio. When other music applications work(and they work perfectly with pulseaudio) i get no sound from timidity in tuxguitar.
When I first start playing a file in tuxguitar(so with timidity), the other applications like banshee or youtube won't work.(no sound, freezes, etc...)

It would be nice if you could fix this for Jaunty.

But thanks for the workaround.

[e-eng (e-eng-deactivatedaccount)]

Maybe you can take a look at my bugreport, because this issue still happens in Jaunty

https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/323320

[Julian Lam (julian-lam)]

I believe this is because TiMidity is loaded prior to the Pulseaudio sound server.

I fixed this problem by restarting the timidity session: sudo /etc/init.d/timidity restart

After that, all MIDI-out wavemapping worked perfectly, and my program (in my case, Sibelius 4.x) did not steal focus from Firefox/emesene/etc

Give that a try. It's a more elegant workaround and can be programmed into Timidity (to start later.. or something... I guess...)

[e-eng (e-eng-deactivatedaccount)]

Thanks, restarting timidity also works, but again, the latency will be worse than before.(a played note gets first red and then you hear the note, when there is a fast song you do not hear the highlightened notes, but these which were 0.5 sec. ago) 0.5 doesn't sound much, but in fact, when you try to play a song with tuxguitar, it is a lot and really weird for the guitar player when the notes aren't highlightened at the same time when you hear them.

[e-eng (e-eng-deactivatedaccount)]

Btw, for the moment I use tuxguitar 1.1(the ubunutu package from their homepage) and I use gervill which is the default sound in tuxguitar now, no timidity+sound font. It sounds not bad, the latency is ok and there aren't problems with pulseaudio. Maybe you can give it a try.

http://tuxguitar.com.ar/download.html

[Julian Lam (julian-lam)]

The program in question for me is Sibelius, which also has a delay.

Perhaps you can play around with optional switches when restarting timidity... for example, the manpage for timidity says that the switch "F" can introduce a delay. This may or may not solve the problem.

[Jochen Kemnade (jochenkemnade)]

Another way to fix this might be to have pulseaudio run as a system-wide daemon instead of a per-user instance. This can be accomplished by changing the PULSEAUDIO_SYSTEM_START=0 line in /etc/default/pulseaudio to PULSEAUDIO_SYSTEM_START=1. This should make pulseaudio start before the timidity daemon. It is not recommended to run pulseaudio as a system-wide daemon, however.
Maybe it would also be possible to have the timidity server run in the user's context instead of the system's? That would make it possible to start it from within the gnome (or whatever) session after pulseaudio.

[NY00123 (ny00)]

Looks like the -B2,8 argument may cause a 40% CPU usage. Could be another cause for the issue.
If it's quite common, then I guess it can simply be removed from the /etc/init.d/timidity script.
People may prefer it to not be run as root, although that's a bit different topic.

[Daniel Ellis (danellisuk)]

I have been testing this on Karmic and so far have come up with the following conclusions (please correct me if any of these are not correct):

- Out of the box timidity and pulse audio cannot play at the same time.
- Restarting timidity (sudo /etc/init.d/timidity restart) gets timidity to work again for a short while, until pulse audio takes control again.
- Timidity does not appear as an application within Sound Preferences.
- Timidity is started with the system
- Timidity runs as the user 'timidity'. It no longer runs as root.
- Pulseaudio runs as the logged in user.
- The 'timidity' user is a member of the 'audio' group and is not a member of the 'pulse-access' group.

I thought that adding the timidity user to the pulse-access group was going to be the answer. Sadly not, as timidity still didn't show up as an application within Sound Preferences.

The command I used was:

  sudo usermod -a -G pulse-access timidity

I then tried running timidity at the command line. So first stopped the timidity daemon and then started it in a shell:

  sudo /etc/init.d/timidity stop
  timidity -Os -iA

Which works. The Sound Preferences window includes the application "ALSA plug-in [timidity]", and both midi and audio from other application play together nicely.

So I then tried to start timidity in the shell as the 'timidity' user to see if that worked:-

  sudo -u timidity timidity -Os -iA

The output of which was:-

======================================
No protocol specified
XOpenDisplay() failed
Home directory /home/daniel not ours.
W: core-util.c: Failed to open configuration file '/home/daniel/.pulse//daemon.conf': Permission denied
W: daemon-conf.c: Failed to open configuration file: Permission denied
Requested buffer size 32768, fragment size 8192
ALSA pcm 'default' set buffer size 30104, period size 3760 bytes
TiMidity starting in ALSA server mode
Opening sequencer port: 128:0 128:1 128:2 128:3
Requested buffer size 32768, fragment size 8192
ALSA pcm 'default' set buffer size 30104, period size 3760 bytes
======================================

This failed to connect to pulseaudio correctly. To resolve the permission denied errors, I added rwx permissions to /home/daniel/.pulse using:

 chmod o+rwx ~/.pulse

Now timidity starts without the permission denied errors, but still fails to connect to pulse audio correctly. I don't understand what else is needed to get a process to connect to pulse audio from a different user id. Any ideas?

[fermulator (fermulator)]

I have tried what Daniel Ellis has suggested (very nice details!), and had the same results on Jaunty.

[Deactivated User (deactivated-user636007-deactivatedaccount)]

Well, just to try things out, I managed to hobble together a pulseaudio output for timidity, based off of the ESD code already present. It works, but as #12 says, pulseaudio kills any connection from a user which does not happen to be the one that starts pulse.

Well, anyways, here's the code for the pulseaudio output.

[Deactivated User (deactivated-user636007-deactivatedaccount)]

Mar 20 18:18:44 fish-laptop pulseaudio[26345]: core-util.c: Home directory /etc/timidity not ours.
Mar 20 18:18:44 fish-laptop pulseaudio[26345]: lock-autospawn.c: Cannot access autospawn lock.
Mar 20 18:18:44 fish-laptop pulseaudio[26345]: main.c: Failed to acquire autospawn lock

And at any rate, it seems that pulseaudio is trying to start it's own instance for timidity, which just changes the problem from timidity and pulseaudio having problems sharing, to pulseaudio and pulseaudio having problems sharing the audio device. (Of course, if the latter case is already possible, then this may work)

[Deactivated User (deactivated-user636007-deactivatedaccount)]

We probably ought to change timidity into a user-mode daemon, and have it autostart on X login. Having it being run on startup seems fine, though having it get killed on logout is another matter altogether.

http://www.linuxquestions.org/questions/linux-desktop-74/gnome-run-script-on-logout-724453/

[Alain Kalker (miki4242)]

I was going to suggest autostarting timidity at login to gnome using a 'wrapper' like alltray (from the package alltray). I use this to start my (proprietary) printer monitor applet.
The idea is that the wrapper (and timidity running within it) will be killed along with all other open applications at logoff.

The big trouble is that timidity doesn't like to be killed that way. One similar way to demonstrate this is as follows:

- Open a gnome terminal
- Open another tab within the terminal
- In that tab, run `timidity -iA -Os`
- Now close the tab with timidity running in it
- A popup should display asking if it is OK to kill running processes. Confirm this.
- In the remaining window, run `ps ax|grep timidity`
- Verify that timidity is still running...

My guess is that timidity does some weird magic to 'detach' itself from its parent process without actually daemonising. Any other program I've tried running in a tab like I described above (like `top`, `mc`, etc.) will get killed when closing the tab.

[Mahendra Tallur (mahen)]

In the PulseAudio wiki, they suggest to switch timidity output mode to "libao"
cf. http://www.pulseaudio.org/wiki/PerfectSetup#TiMidity

However, libao output is not built in the Ubuntu executable.

As of Ubuntu Maverick, I worked around this by starting timidity during the GNOME startup. It seems there is no more timidity maintainer since 2004 :(

What is strange is that, nowadays, when using PA with a dmix capable sound board, there is usually no problem at all mixing PA & alsa apps. I don't understand why, in some cases, the alsa app seems to "lock" the audio device. (the same occurs when using the oss->alsa wrapper).

[Bachsau (bachsau)]

The only clean solution to this is to run pulseaudio in system mode and add the timidity user to pulse-access group. This also fixes some other problems pulseaudio has and effectively stops other apps from grabbing the soundcard.

This is because by default only the current user, which is also running the pulseaudio daemon, can play audio. By switching pulseaudio to system mode, it can be access by every user in the pulse-access group without starting anything before.

[Lastique (andysem)]

As described in bug https://bugs.launchpad.net/ubuntu/+source/timidity/+bug/1799541 starting timidity system daemon can prevent PulseAudio from gaining access to one of the sound cards in ALSA.

I think, a better solution would be to change timidity to run as a user-specific service, instead of system-wide, and depend on pulseaudio or pulseaudio.socket to start first. This way we should have PulseAudio running in user mode and starting before timidity. Timidity will grab the default ALSA device, which is an alias for the pulse loopback when pulseaudio is running.

[william fischer (maxxjvx)]

Upgraded from 18.04 to 18.10 and lost sound. Sound setting showed Dummy Output. alsa force-reload would fix it until reboot. Removed timidity-daemon (apt-get purge) and the problem went away. Apparently pulseaudio and timidity got along in 18.04 and earlier versions, not exactly sure what changed, but I removed timidity after reading https://bugs.launchpad.net/ubuntu/+source/timidity/+bug/1798466
I tried re-install timidity-daemon, but then the problem returned. It's removed for now.

[Daniel van Vugt (vanvugt)]

Hmm, yes the recent duplicates of this bug seem to be from 18.10. So there may be a regression in 18.10, or it might just be because the main person answering bug reports only learnt about this timidity issue this week.

I've only had time to link 18.10 bug reports to this one so far. Certainly the symptoms are very common so I would expect to find 18.04 bug reports too. I'll need more time to be sure.

[Michal Illich (a-list-l)]

Also had this problem (no sound) after upgrade 18.04.1 -> 18.10.

I do *NOT* have timidity installed.

alsa force-reload works as temporary fix.

[Daniel van Vugt (vanvugt)]

Then you are commenting on the wrong bug :)

[Christophe Chisogne (cchisogne)]

There was a regression for me too, from kubuntu 18.04 to kubuntu 18.10, as described here:

https://answers.launchpad.net/ubuntu/+source/alsa-driver/+question/675670

Basically KDE showed only the dummy output even if everything else looked right. trying "sudo alsa force-reload" was not working for me. But killing the timidity service did the trick.

[Daniel van Vugt (vanvugt)]

I've been thinking that since this bug apparently was fixed by 18.04 (and earlier), but then seemingly regressed again in 18.10, that maybe we should instead have closed this old bug and tracked the current problem in bug 1793640 instead...

[Daniel van Vugt (vanvugt)]

Also gutsy and hardy are well past end of life:

https://wiki.ubuntu.com/Releases

So we are now tracking the issue in bug 1793640 instead.