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

[Jan Knutar]

On Friday 03 February 2006 19:25, Clemens Ladisch wrote:

> > Well it plays now, but the sound skips a lot, several times per
> > second. :-)
> 
> Did the old code skip in this situation?

No, but with the old code, the video was jittery instead of the audio.
Actually it seems to have more jitter with the new code too, compared
to oss.

> 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).

Hm.

> Another reason for synchronization problems might be that this driver
> rounds down all audio transfers to a multiple of the period size.

Was this the case with the old driver too? I seem to remember trying
to debug another patch (that incidentally changed the 0.1/0.25 behaviour),
this patch however either made MPlayer consume 100% CPU thinking
the audio buffer needed to be refilled constantly, or then the video would
run in stop-and-go, with a few hundred frames played at once, then half
a second freeze, etc. 

So it seems a bit counterintuitive to have a large granularity... I wonder why
it's there in the OSS driver.

> 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().

It doesn't crash, but occasionally I get the skips. It's maybe better
described as a jitter, sounds like several dozens of skips per second.
Pausing and unpausing seems to magically cure it, sometimes.

I tried changing the values to 1.25 and 0.2. I seem unable to trigger the
audio skips anymore, despite abusing the spacebar for pausing and
unpausing.

For curiosity's sake, I added. an fprintf of the delay value in get_delay
(new patch), delay seems to always be a multiple of 2048.

If I use -ao alsa:device=hw=0.0, then it's no longer a multiple of 2048,
and the video is atleast as smooth as with -ao oss (via alsa's oss emulation).
Video via default device, both with old code, oldpatch and newpatch
was always somewhat jittery.

I think default device points to dmix. I guess there's just no way to get
this to work with dmix in Alsa 1.0.6?

On a sidenote, when going direct to hw:0,0, I don't get any skips at all, not
even at the start of playback.

I seem to remember people saying dmix has been improved alot lately, maybe
it would be time for upgrade for me, so this is possibly only something that
affects users like me who haven't had the courage and a weekend to upgrade
to the latest verison of their distro of choice yet? :-)