Re: XMMS (or some other audio player) 'hang' issues with intel8x0 and dmix plugin [u]

[Jan Knutar <jk-lkml@sci.fi>]

On Tuesday 02 November 2004 10:57, Christophe Saout wrote:

> I've tracked this down to what seems to be a bug in the libalsa dmix
> code with mmap emulation. If the sound output was stopped for some
> reason (stream paused or underrun) the library will accept more data
> until the buffer is full but never restart the output.

Strangely, I've observed these kinds of "Hangs" with bmp and mplayer,
without mmap mode enabled in either. Also using dmix as in the other
reports here. Could of course be some third application using alsa in
mmap mode, I suppose.

Unfortunately, I have no strace to offer right now as the bug is happening
randomly and I haven't been able to find any method by which to reproduce
it.

What's strange is that almost always when it happens, either mplayer or
beep-media-player will have an extra forked process. As bmp is threaded
and I shouldn't see more than one bmp in ps aux on NPTL, this seemed a
bit strange. Strace on the process that looked more recent makes it usually
wake up from deep sleep, and then it promptly vanishes after only a few syscalls.
The strace itself seems to wake it up... After the 'extra' process is gone,
sound output usually resumes, but not always. Other times strace only reveals
the app doing nanosleep's and nothing else, and the only solution is to kill
all apps that might've touched sound.

Another dmix+mplayer issue I have is that mplayer's get_delay for alsa seems
to return bogus values for alsa+dmix case, but I digress...