Re: [Cooker] Totem playing videos at fast-forward speed ?

[Takashi Iwai <tiwai@suse.de>]

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@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel