At Wed, 14 Apr 2010 16:12:58 -0300, Herton Ronaldo Krzesinski wrote: > > Em Ter 13 Abr 2010, às 18:57:51, Éric Piel escreveu: > > Op 07-04-10 00:23, Herton Ronaldo Krzesinski schreef: > > > Em Ter 06 Abr 2010, às 18:52:08, Éric Piel escreveu: > > >> Op 06-04-10 22:29, Frank Griffin schreef: > > >>> Anssi Hannula wrote: > > >>>> Try mplayer: > > >>>> mplayer file > > >>>> > > >>> > > >>> Same speedup symptom as Totem > > >>> > > >>>> and mplayer without audio: > > >>>> mplayer -ao null file > > >>>> > > >>> > > >>> Back to normal speed. > > >>> > > >> > > >> Hi, > > >> I'm experiencing a similar problem on a machine with an intel HDA. It > > >> happens only with a kernel 2.6.34-rc*. With a vanilla 2.6.33, everything > > >> is fine. Is your kernel the normal cooker kernel? > > >> > > >> Does anyone know if there are some update to alsa in this kernel > > >> compared to the vanilla kernel? > > > > > > yes, there is some pcm_lib changes applied from 2.6.34-rc* because of > > > pulseaudio. Would be good to know if reverting these changes on 2.6.34 fixes > > > the problem: > > > ALSA: pcm_lib - fix xrun functionality > > > ALSA: pcm_native - fix runtime->boundary calculation > > > ALSA: pcm_lib - return back hw_ptr_interrupt > > > ALSA: pcm_core: Fix wake_up() optimization > > > ALSA: pcm_lib - fix wrong delta print for jiffies check > > > ALSA: pcm_lib: fix "something must be really wrong" condition > > > ALSA: pcm_lib - optimize wake_up() calls for PCM I/O > > > ALSA: pcm_lib - cleanup & merge hw_ptr update functions > > > ALSA: pcm_lib - add possibility to log last 10 DMA ring buffer positions > > > ALSA: pcm_lib.c - convert second xrun_debug() parameter to use defines > > Hi, > > I've done a bisection on a vanilla kernel, and it turned out to be > > 7b3a177b0d4f92b3431b8dca777313a07533a710, aka ALSA: pcm_lib: fix > > "something must be really wrong" condition . > > > > So I'd recommend to drop it from the mandriva kernel, and get confirmed > > it is fixed. > > Ok adding alsa-devel to CC, may be the issue is known. > > Eric, from later messages you only experience the problem when bdl_pos_adj > isn't set to 1 right? > > Anyway Frank said that his bdl_pos_adj is set to 32 on two machines (hda-intel), > and on one of them the problem happens, while in the other not. I guess we > could have a problem then on commit > 7b3a177b0d4f92b3431b8dca777313a07533a710 The problem is likely the device returning a wrong DMA position by some reason. The commit above tries to fix an issue with nperiods=1, but this makes the check more strict for such wrong DMA positions. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel