[MPlayer-dev-eng] [PATCH 0/5] various enhancements and bugfixes for the ALSA driver

[Clemens Ladisch]

Jan Knutar wrote:
> mplayer: pcm.c:1054: __snd_pcm_forward: Assertion `frames > 0'
> failed.
>
> > It's not very reproducable for me.

It happens when there is an underrun that is shorter than one period
(which results in snd_pcm_forward being called with 0 frames).

This assertion was considered a bug and removed in version 1.0.8 of
alsa-lib.

> I hadn't gotten any further than writing up the previous email and
> sent it, and was about to unpause MPlayer, when the same thing hit
> again.

I get underruns when unpausing too.  It seems MPlayer begins playing
because there's still some data buffered, but reading more data isn't
fast enough because the drive is still spinning up.

> A bit annoyed, I tried a nasty hack, inserted if(delay)
> before the snd_pcm_forward in get_delay.

This would actually be correct for this version of snd_pcm_forward().

> Well it plays now, but the sound skips a lot, several times per
> second. :-)

Did the old code skip in this situation?

The usual remedy against underruns is increasing the buffer size, but
it seems mplayer.c tries to keep the amount of data in the buffer
between 100 and 250 ms, regardless of the actual buffer size.
You might try to increase these values (0.10 and 0.25).

Another reason for synchronization problems might be that this driver
rounds down all audio transfers to a multiple of the period size.
I'm doing this only because the OSS driver does it, but it seems the
other drivers can get away without it.

Attached is a new version of the third patch that always transfers the
exact amount of data that mplayer.c asks for, and incidentally fixes
the assert in snd_pcm_forward().


Clemens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alsa-patch-3.diff
Type: application/octet-stream
Size: 11278 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20060203/282fbad8/attachment.obj>