[alsa-devel] [REGRESSION bisected] Sound goes too fast due to commit 7b3a177b0

[Takashi Iwai]

At Wed, 14 Apr 2010 13:22:14 +0200,
Éric Piel wrote:
> 
> On 14/04/10 08:08, Takashi Iwai wrote:
> > At Tue, 13 Apr 2010 23:54:26 +0200,
> > Éric Piel wrote:
> >>
> >> Hello,
> >>
> >> Since 2.6.34-rc*, I have a regression on alsa which prevents the sound
> >> to be played correctly. When playing, the music goes too fast, skipping
> >> some parts. Typically, it's very easy to reproduce by doing:
> >> time mplayer -endpos 30 sound-file-which-lasts-more-than-thirty-sec.mp3
> >>
> >> If the wall clock is less than 30s, you have the bug. With my intel-hda
> >> (AD1981), it's reliably reproducible: it gives ~27s, instead of the
> >> normal ~31s.
> >>
> >> After bisection, it turns out that it is commit
> >> 7b3a177b0d4f92b3431b8dca777313a07533a710, aka "ALSA: pcm_lib: fix
> >> "something must be really wrong" condition" which caused this
> >> regression. Reverting it on top of 2.6.34-rc3+ fixes the problem.
> > 
> > What happens if you pass position_fix=1 option to snd-hda-intel?
> Oh! Very good remark...
> I've just noticed that I had an option already on the module:
> bdl_pos_adj=0. It seems it's not needed anymore to get my card working
> fine. If I remove every option (leaving bdl_pos_adj to the default value
> 1), it works fine. If I put bdl_pos_adj=0 and position_fix=1, it works
> fine again.
> 
> I don't fully grasp the meaning of bdl_pos_adj, so I don't know if it's
> a bug to not play correctly when forcing it to 0. Is it?

It might be that this was for reducing the load by position
correction mechanism.  You might see the hd-audio kernel thread in a
high CPU usage.  This might be fixed also by position_fix=1, though. 


thanks,

Takashi