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

From: Martin Schlemmer [c]
Date: Tue Nov 02 2004 - 20:56:54 EST


On Tue, 2004-11-02 at 13:40 +0200, Jan Knutar wrote:
> 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.
>

I cannot say that I have seen this. It always just resumes fine if I
click on play again, and I cannot remember it having an extra process.
But then I mostly tried it with mmap enabled (as without it also had
this issue), so I will have a look without mmap, and report if similar
issues happens this side.


Thanks,

--
Martin Schlemmer

Attachment: signature.asc
Description: This is a digitally signed message part