I'm being hit with a long-standing and very annoying bug in gus_wave.c that
keeps applications from being able to close /dev/dsp - the close() call
never returns.
This is caused by a check in DMAbuf_sync (file dmabuf.c), which waits for
the internal buffers of a soundcard to reach 0. This makes sense, of course.
The problem is, that for GUS (at least my GUS Classic 3.73), the
adev->d->local_qlen(dev) function never returns 0, because the variable in
gus_wave.c, named pcm_qlen, never reaches 0, and oscillates between 1 and 2,
even if there is no more data to be played, probably playing just zeroes
through the card.
The check in DMAbuf_sync always sees the value 2. And the application just
stays forever in the loop, never returning from the close() call, unless
they get some signal, of course (the loop also checks for signal_pending).
Unfortunately I have not been able to track down the real cause of pcm_qlen
never reaching 0 yet, as I have close to none knowledge about how a GUS
works internally.
Can you (or anyone) help me?
Thanks,
Vojtech Pavlik
PS. The bug can be easily triggered by
echo Test > /dev/dsp
... the echo command never returns to command prompt, unless stopped by ^C.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html