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

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

[Éric Piel]

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 ;-)

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

[Takashi Iwai]

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

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

[Éric Piel]

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

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

[Éric Piel]

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.

Eric

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

[Takashi Iwai]

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

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

[Éric Piel]

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

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

[Frank Griffin]

É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 !

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

[Takashi Iwai]

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

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

[Takashi Iwai]

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

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

[Éric Piel]

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

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

[Takashi Iwai]

At Thu, 15 Apr 2010 23:19:33 +0200,
Éric Piel wrote:
> 
> 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?

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.)


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

[Frank Griffin]

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 :)

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

[Frank Griffin]

É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...

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

[Frank Griffin]

É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.