Sound goes too fast due to commit 7b3a177b0
in [Kernel]
|
Prev: WARNING: at fs/sysfs/dir.c:451 sysfs_add_one: sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:01.0/slot'
Next: blkdev: pass gfp_mask and flags to blkdev_issue_flush
From: Frank Griffin on 14 Apr 2010 11:40 É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 ! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Takashi Iwai on 14 Apr 2010 12:10 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Takashi Iwai on 14 Apr 2010 12:10 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Éric Piel on 15 Apr 2010 17:20 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Takashi Iwai on 16 Apr 2010 04:00
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |