Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756234Ab0DNQB1 (ORCPT ); Wed, 14 Apr 2010 12:01:27 -0400 Received: from cantor2.suse.de ([195.135.220.15]:47948 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756202Ab0DNQB0 (ORCPT ); Wed, 14 Apr 2010 12:01:26 -0400 Date: Wed, 14 Apr 2010 18:01:24 +0200 Message-ID: From: Takashi Iwai To: =?UTF-8?B?w4lyaWM=?= Piel Cc: Jaroslav Kysela , "Rafael J. Wysocki" , Linux Kernel Mailing List , alsa-devel@alsa-project.org Subject: Re: [REGRESSION bisected] Sound goes too fast due to commit 7b3a177b0 In-Reply-To: <4BC5A566.8060106@tremplin-utc.net> References: <4BC4E812.6050602@tremplin-utc.net> <4BC5A566.8060106@tremplin-utc.net> User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.7 Emacs/23.1 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1917 Lines: 47 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/