Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[REGRESSION bisected] Sound goes too fast due to commit 7b3a177b0

1 view
Skip to first unread message

Éric Piel

unread,
Apr 13, 2010, 6:00:02 PM4/13/10
to
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.

Let me know if you need more info,
Cheers,
Eric

PS: For the info, the bisection was especially hard to do because about
80 alsa commits around the faulty one were all applied on kernel
versions which did not boot on my laptop. On top of the first known bad
I had to revert all of them, and run an "invert bisection" on it...
Enjoy the bisection result ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Takashi Iwai

unread,
Apr 14, 2010, 2:10:02 AM4/14/10
to
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?
Is it via PulseAudio or other backend?


thanks,

Takashi

Éric Piel

unread,
Apr 14, 2010, 7:30:02 AM4/14/10
to
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?

I'll ask to another reporter who had the same problem if bdl_pos_adj is
also set to 0...

> Is it via PulseAudio or other backend?

This happens both with pulseaudio, oss and alsa (in which case it plays
the 30s clip in 12s).

Eric

Éric Piel

unread,
Apr 14, 2010, 8:00:02 AM4/14/10
to
On 14/04/10 13:22, Éric Piel wrote:
:

> 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?
>
> I'll ask to another reporter who had the same problem if bdl_pos_adj is
> also set to 0...
Frank (cc'd here) has the same problem of music going too fast (on a
2.6.33 kernel with the "culprit" commit applied). On his system "cat
/sys/module/snd_hda_intel/parameters/bdl_pos_adj" gives:
32,32,-1,-1,-1,-1,-1,-1

He also mentioned that on another system also using snd_hda_intel, with
the same bdl_pos_adj, it works fine.

Takashi Iwai

unread,
Apr 14, 2010, 9:40:01 AM4/14/10
to
At Wed, 14 Apr 2010 13:54:48 +0200,

Éric Piel wrote:
>
> On 14/04/10 13:22, Éric Piel wrote:
> :
> > 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?
> >
> > I'll ask to another reporter who had the same problem if bdl_pos_adj is
> > also set to 0...
> Frank (cc'd here) has the same problem of music going too fast (on a
> 2.6.33 kernel with the "culprit" commit applied). On his system "cat
> /sys/module/snd_hda_intel/parameters/bdl_pos_adj" gives:
> 32,32,-1,-1,-1,-1,-1,-1
>
> He also mentioned that on another system also using snd_hda_intel, with
> the same bdl_pos_adj, it works fine.

bdl_pos_adj is really a workaround for devices that report wrong DMA
position (or at the wrong timing). I guess position_fix=1 may fix
better.

Although the driver already has a dynamic switching of position_fix
method, it checks only the very first read. If it gives a (more or
less) sane value, it prefers the position-buffer method (corresponding
to position_fix=2) rather than reading LPIB register
(position_fix=1).

It seems, however, that more devices work sanely with LPIB reg
nowdays. This wasn't the case formerly. So, it might be better to
use position_fix=1 as default for modern systems...


Takashi

Éric Piel

unread,
Apr 14, 2010, 10:40:03 AM4/14/10
to
On 14/04/10 15:39, Takashi Iwai wrote:
:

>
> bdl_pos_adj is really a workaround for devices that report wrong DMA
> position (or at the wrong timing). I guess position_fix=1 may fix
> better.
>
> Although the driver already has a dynamic switching of position_fix
> method, it checks only the very first read. If it gives a (more or
> less) sane value, it prefers the position-buffer method (corresponding
> to position_fix=2) rather than reading LPIB register
> (position_fix=1).
>
> It seems, however, that more devices work sanely with LPIB reg
> nowdays. This wasn't the case formerly. So, it might be better to
> use position_fix=1 as default for modern systems...
Frank,
Could you check that for you too adding "position_fix=1" fixes the problem?

To do so, edit /etc/modprobe.conf and add this line at end:
options snd-hda-intel position_fix=1

You need to reboot for this to be taken into account.

Cheers,
Eric

Frank Griffin

unread,
Apr 14, 2010, 11:40:01 AM4/14/10
to
Éric Piel wrote:
> Frank,
> Could you check that for you too adding "position_fix=1" fixes the problem?
>
> To do so, edit /etc/modprobe.conf and add this line at end:
> options snd-hda-intel position_fix=1
>
> You need to reboot for this to be taken into account.
>
>
That fixes not only the playback speed, but also the fact that the
failing system had no sound since the problem started (the acceleration
was noticed in movie playback).

Thanks !

Takashi Iwai

unread,
Apr 14, 2010, 12:10:02 PM4/14/10
to
At Wed, 14 Apr 2010 13:22:14 +0200,

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

Takashi Iwai

unread,
Apr 14, 2010, 12:10:03 PM4/14/10
to
At Wed, 14 Apr 2010 11:39:08 -0400,

Frank Griffin wrote:
>
> Éric Piel wrote:
> > Frank,
> > Could you check that for you too adding "position_fix=1" fixes the problem?
> >
> > To do so, edit /etc/modprobe.conf and add this line at end:
> > options snd-hda-intel position_fix=1
> >
> > You need to reboot for this to be taken into account.
> >
> >
> That fixes not only the playback speed, but also the fact that the
> failing system had no sound since the problem started (the acceleration
> was noticed in movie playback).

OK, so position_fix=1 seems mandatory for your device.

Could you give alsa-info.sh output (run with --no-upload option) so
that I can add a quirk entry for your machine?


thanks,

Takashi

Éric Piel

unread,
Apr 15, 2010, 5:20:02 PM4/15/10
to
Op 14-04-10 18:01, Takashi Iwai schreef:
:

>>
>> 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.
Yes, I had added this option after a regression in the previous kernel
which causes the hd-audio thread to take 50% of a CPU. Eventually, it
was fixed and not needed anymore. So I guess in the case of my laptop,
this is not really a regression, because everything is fine with the
default values.

In the case of Frank, this looks more like a regression, or at least a
bug to solve, because this happens with the default options. However,
this report should be taken with care, because this happens on a
2.6.33.2 kernel made by Mandriva, containing many alsa patches of
2.6.34. Frank, how possible would it be to test a 2.6.34-rc4 kernel from
Linus?

If this bug is confirmed, Takashi, do you know any way to choose
automatically position_fix=1 when needed?

See you,
Eric

Message has been deleted

Frank Griffin

unread,
Apr 16, 2010, 6:40:02 AM4/16/10
to
Takashi Iwai wrote:
> There is a quirk table in sound/pci/hda_intel.c to check PCI SSID.
> I already added an entry for Frank's machine on sound git tree which
> will be included in the pull request I'm going to send soon.
> (Sorry the mail went outside since Frank's reply was private.)
>
Not a problem, I just didn't want to spam the others with the rather
large command output :)

Frank Griffin

unread,
Apr 16, 2010, 6:50:02 AM4/16/10
to
Éric Piel wrote:
> In the case of Frank, this looks more like a regression, or at least a
> bug to solve, because this happens with the default options. However,
> this report should be taken with care, because this happens on a
> 2.6.33.2 kernel made by Mandriva, containing many alsa patches of
> 2.6.34. Frank, how possible would it be to test a 2.6.34-rc4 kernel from
> Linus?
>
>
I'll try to do this over the weekend...

Maciej Rutecki

unread,
Apr 16, 2010, 11:00:02 AM4/16/10
to
On wtorek, 13 kwietnia 2010 o 23:54:26 �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
>

I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=15796
for your bug report, please add your address to the CC list in there, thanks!

--
Maciej Rutecki
http://www.maciek.unixy.pl

Frank Griffin

unread,
Apr 17, 2010, 11:30:02 AM4/17/10
to
Éric Piel wrote:
> In the case of Frank, this looks more like a regression, or at least a
> bug to solve, because this happens with the default options. However,
> this report should be taken with care, because this happens on a
> 2.6.33.2 kernel made by Mandriva, containing many alsa patches of
> 2.6.34. Frank, how possible would it be to test a 2.6.34-rc4 kernel from
> Linus?
>
>

Done. 2.6.34-rc4 compiled with standard configuration and without
"options snd-hda-intel position_fix=1" in modprobe.conf works perfectly:
normal sound and normal playback speed.

Mirix

unread,
Jun 18, 2010, 5:00:02 AM6/18/10
to
Hello,

I have a similar problem with hda-intel ALC883 since kernel 2.6.33 (problems are
identical with kernel 2.6.34). There are quick short gaps with the default
options. In turn, bdl_pos_adj=0 results in fast sound as reported here.
position_fix=1 does not fix it.

The card worked fine with previous kernels.

lspci :

00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller
(rev 03)

aplay -l :

**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC883 Analog [ALC883 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 6: Si3054 Modem [Si3054 Modem]
Subdevices: 1/1
Subdevice #0: subdevice #0

dmesg:

[ 199.222813] hda-intel: IRQ timing workaround is activated for card #0.
Suggest a bigger bdl_pos_adj.

Takashi Iwai

unread,
Jun 18, 2010, 8:20:02 AM6/18/10
to
At Thu, 17 Jun 2010 20:17:50 +0000 (UTC),

Mirix wrote:
>
> Hello,
>
> I have a similar problem with hda-intel ALC883 since kernel 2.6.33 (problems are
> identical with kernel 2.6.34). There are quick short gaps with the default
> options. In turn, bdl_pos_adj=0 results in fast sound as reported here.
> position_fix=1 does not fix it.
>
> The card worked fine with previous kernels.

How about 2.6.35-rc3? Another adjustment mechanism was introduced
in 2.6.35, so this might work better...


Takashi

Miro Moman

unread,
Jun 18, 2010, 11:30:02 AM6/18/10
to
Hi Takashi,

Thanks for the advice. However, I have just built 2.6.35-rc3 and it
did not help at all.

Linux solaina 2.6.35-rc3-core2 #1 SMP PREEMPT Fri Jun 18 15:33:37 CEST
2010 x86_64 GNU/Linux

On Fri, Jun 18, 2010 at 2:11 PM, Takashi Iwai <ti...@suse.de> wrote:
> At Thu, 17 Jun 2010 20:17:50 +0000 (UTC),
> Mirix wrote:
>>
>> Hello,
>>
>> I have a similar problem with hda-intel ALC883 since kernel 2.6.33 (problems are
>> identical with kernel 2.6.34). There are quick short gaps with the default
>> options. In turn, bdl_pos_adj=0 results in fast sound as reported here.
>> position_fix=1 does not fix it.
>>
>> The card worked fine with previous kernels.
>
> How about 2.6.35-rc3?  Another adjustment mechanism was introduced
> in 2.6.35, so this might work better...
>
>
> Takashi
>

--
http://www.edelmiromoman.eu/

0 new messages