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

[ message continues ]

At Tue, 13 Apr 2010 23:54:26 +0200,

What happens if you pass position_fix=1 option to snd-hda-intel?
Is it via PulseAudio or other backend?


thanks,

Takashi
--

[ message continues ]

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
This happens both with pulseaudio, oss and alsa (in which case it plays
the 30s clip in 12s).

Eric
--

[ message continues ]

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

[ message continues ]

At Wed, 14 Apr 2010 13:54:48 +0200,

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

[ message continues ]

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

[ message continues ]

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

[ message continues ]

At Wed, 14 Apr 2010 11:39:08 -0400,

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

[ message continues ]

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

[ message continues ]

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 continues ]

At Thu, 15 Apr 2010 23:19:33 +0200,

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

[ message continues ]

Not a problem, I just didn't want to spam the others with the rather 
large command output :)
--

[ message continues ]

I'll try to do this over the weekend...
--

[ message continues ]

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

[ message continues ]

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.


--

[ message continues ]

At Thu, 17 Jun 2010 20:17:50 +0000 (UTC),

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


Takashi
--

[ message continues ]

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






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

[ message continues ]

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

[ message continues ]