Re: [alsa-devel] [Cooker] Totem playing videos at fast-forward speed ?
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
See you, Eric
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
participants (2)
-
Herton Ronaldo Krzesinski -
Takashi Iwai