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: Takashi Iwai on 14 Apr 2010 02:10 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 -- 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 14 Apr 2010 07:30 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 -- 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 14 Apr 2010 08:00 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 -- 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 09:40 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 -- 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 14 Apr 2010 10:40
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 -- 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/ |