dosbox and timidity daemon don't play nice

[Daan Willems]

When running dosbox on a system where a timidity daemon is running (default behavior), programs started in dosbox detect the general midi hardware (port 330) but upon playback, nothing is heard.

After stopping the timidity daemon (init script) and starting timidity manually as the same user that will run dosbox (i.e. using: /usr/bin/timidity -Os -iAD) midi playback is perfectly fine.

Notice that it is possible to play midi using for example: pmidi -p 128:0 test.mid in both situations (daemon or user started timidity).
Therefore, this issue seems dosbox related.

I have tried adding myself to the audio and timidity groups, but that didn't solve this issue.

midi related dosbox.conf:
mpu401=intelligent
mididevice=default
midiconfig=128:0

After starting dosbox, it reports the midi hardware correctly in both situations:
ALSA:Client initialised [128:0]
MIDI:Opened device:alsa

For reference:
Ubuntu 12:04 LTS x64
dosbox 0.74-2
timidity 2.13.2-40build2
timidity-daemon 2.13.2-40build2

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[shankao (shankao)]

timidity can be interacting with the libsdl-sound1.2 library (SDL_Sound, a dependency of dosbox) installed in your system. Can you check other games/apps that use SDL_Sound while timidity is installed to see if they work?

If they don't work, it could be a problem on libsdl-sound1.2 package; it they work, it can be about the way dosbox uses SDL_Sound

[shankao (shankao)]

I have being looking at the latest dosbox sources and found this commit:

r3370 | qbix79 | 2009-04-28 01:33:12 +0800 (Tue, 28 Apr 2009) | 2 lines
Changed paths:
   M /dosbox/trunk/src/gui/midi_alsa.h

disable timidity port by default. timiditys default configuration on Ubuntu gives a high load when used with dosbox in idle mode ( -B2,8 )

So, it's an upstream decision. If anybody wants to try to fix this, I suggest to download the latest source for dosbox, revert that commit and try to debug the problem there.

[Launchpad Janitor (janitor)]

[Expired for dosbox (Ubuntu) because there has been no activity for 60 days.]

[shankao (shankao)]

Please fill up a bug report in the dosbox bugtracker and report the bug number here. This is not a problem in Ubuntu, but in dosbox (see comment #3)

[mmaurer (mbfmaurer)]

I have changed the status from expired back to confirmed because kubuntu 14.10 still shows this bug.

Also as far as I can tell the commit mentioned in comment #3 (https://bugs.launchpad.net/ubuntu/+source/dosbox/+bug/997325/comments/3) is not responsible for this behavior.

Unless there are some weird side effects, the commit[r3370] just prevents dosbox from using timidity in its default configuration, but does not stop the user from explicitly specifying it in the configuration file 'dosbox.conf'.

[mmaurer (mbfmaurer)]

Just to confirm that commit[r3370] is not the culprit here, I reverted that commit in the latest svn version of dosbox, and as expected, it only changes whether the midi ports have to be manually configured or not.
The buggy behavior described here is completely unchanged.

[mmaurer (mbfmaurer)]

This does not seem to be a dosbox problem, but rather a remnant of the problems introduced by the introduction of pulseaudio.
Since pulseaudio is not run as a system service by default (cf. /etc/init/pulseaudio.conf) timidity probably shoud not either.

This entry in the Arch wiki seems to describe the same issue:
https://wiki.archlinux.org/index.php/timidity#Daemon

It might be better to just autostart something like "/usr/bin/timidity -Os -iAD" when the user logs in, instead of starting a system wide daemon at boot time.

But maybe someone with a deeper knowledge of how the ubuntu audio stack is supposed to work could weigh in on this.