It is a rather strange problem.. When I start Timidity++ using: /etc/init.d/timidity start --or-- sudo timidity -iA -oS And I do: pmidi hello.mid & aoss mpg123 test.mp3 <<<<- this doesn't work (mpg123 waits forever) .. it seems Timidity locks /dev/dsp (probably no use of dmix?) But when I start it as a user: timidity -iA -oS I can then successfully do: pmidi hello.mid & aoss mpg123 test.mp3 ... and the songs play simultaneously. So, would it be a better idea to: - start Timidity as non-root ? - or tell Timidity to drop root priviledged (but how??) When I launch Timidity with "su myuser -c" from root, it works. For reference my ALSA dmix config is: -= cat /etc/asound.conf =- pcm.!default { type plug slave.pcm "swmix" } pcm.dsp0 { type plug slave.pcm "swmix" } pcm.swmix { type dmix ipc_key 888 slave { pcm "hw:0,0" period_time 0 period_size 1024 buffer_size 8192 rate 48000 } }
I have had THE worst luck getting dmix to work correctly with my test system... but I did get it to work, and timidity played nice with it... I'm guessing that your sound card doesn't have friendly dmix support or something, but the root/non-root issue is really puzzling... what about adding your user to the 'audio' group (don't forget to logout/login after)?
I agree it's quite strange.. the whole point of dmix was to compensate for those soundcards by mixing in software :-) Yes, my user already belongs to group 'audio'. Clearly, there's something strange when Timidity is started as root. Should I add root to the 'audio' group too ?
what happens when you start xmms as root and run mpgq23 as root (not through aoss)?
If I run xmms as root, it hangs until pmidi is stopped. Whether I run timidity as root or user, doesn't matter in this case. If I run xmms as user, it does work simultaneously with pmidi, but *only* if I started timidity as user too.
You're going to have to talk to the alsa devs upstream to get this straightened out. I can't reproduce this problem. dmix is very touch-and-go, so I am betting that is the problem rather than timidity.
