The problem is well-known; when playing PCM audio
with a GUS (classic at least), the playing app
never quits unless explicitly killed and strace
usually tells us that the hang is in the middle
of close() that closes /dev/dsp. Playing as such
works just fine, just the final clean-up sucks.
At some phase I noticed that a) midi and mod playing
work just fine (sure, they mostly rely on /dev/sequencer).
b) stalled mp3 playing processes were
able to finish if strace was attached to 'em. When playing
raw PCM audio with vplay, the process tells me to go
fly a kite when I try to attach strace to it and exits
immediately. c) if the mp3 player is stopped with ctrl-z
and brought to foreground, it exits normally. Somehow b)
and c) made me think pretty negatively about finding a fix. The
behavior is just bizarre, at least to me. When I did the
suspend-foreground sequence, strace claimed that the close()
on /dev/dsp had succeeded (returned zero) and the SIGSTP
would have happened after that. Right after the stopping
signal, strace finds an _exit(). When the process is straced
from the very beginning, it won't finish playing.
If needed, I can do more tricks to the driver, but
I won't be able to get it working without a little
help from someone who is more familiar with the
sound code. If I try to find a fix, I'll have to
take wild guesses all the time and just come up with
a crazy-idea-of-the-week until I find the problematic
piece, but that's really not that productive and I do
have some other things to do. :D
-VJV-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu