lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 14 Apr 2010 18:01:24 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Éric Piel <eric.piel@...mplin-utc.net>
Cc:	Jaroslav Kysela <perex@...ex.cz>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	alsa-devel@...a-project.org
Subject: Re: [REGRESSION bisected] Sound goes too fast due to commit 7b3a177b0

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists