[alsa-devel] [REGRESSION bisected] Sound goes too fast due to commit 7b3a177b0
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 ;-)
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
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
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
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
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
É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 !
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
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
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
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
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 :)
É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...
É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.
participants (3)
-
Frank Griffin -
Takashi Iwai -
Éric Piel