Bug 15796 - [REGRESSION bisected] Sound goes too fast due to commit 7b3a177b0
Summary: [REGRESSION bisected] Sound goes too fast due to commit 7b3a177b0
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks: 15310
  Show dependency tree
 
Reported: 2010-04-16 14:53 UTC by Maciej Rutecki
Modified: 2010-07-01 18:02 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.34-rc
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description Maciej Rutecki 2010-04-16 14:53:56 UTC
Subject    : [REGRESSION bisected] Sound goes too fast due to commit 7b3a177b0
Submitter  : Éric Piel <Eric.Piel@tremplin-utc.net>
Date       : 2010-04-13 21:54
Message-ID : 4BC4E812.6050602@tremplin-utc.net
References : http://marc.info/?l=linux-kernel&m=127119569009790&w=2
Handled-By : Takashi Iwai <tiwai@suse.de>

This entry is being used for tracking a regression from 2.6.33.  Please don't
close it until the problem is fixed in the mainline.

Caused by:

commit 7b3a177b0d4f92b3431b8dca777313a07533a710
Author: Jaroslav Kysela <perex@perex.cz>
Date:   Fri, 8 Jan 2010 07:43:01 +0000

    ALSA: pcm_lib: fix "something must be really wrong" condition

    Signed-off-by: Jaroslav Kysela <perex@perex.cz>

First-Bad-Commit : 7b3a177b0d4f92b3431b8dca777313a07533a710
Comment 1 Éric Piel 2010-04-18 18:39:39 UTC
This should be fixed by commit 8815cd030fdd73932a791d1f06194c8db807cde7 "ALSA: hda - Add position_fix quirk for Biostar mobo", currently in the sound-2.6 tree.
Comment 2 Éric Piel 2010-04-23 11:48:12 UTC
Linus has pulled the commit, so this regression should now be fully fixed.
Comment 3 Øyvind Stegard 2010-05-04 21:11:29 UTC
I'm having audio and video playback issues with kernel 2.6.34-rc6 (compiled on Ubuntu Lucid x86), and I have an AD1981 HDA codec (Thinkpad Z61m laptop, codec info here: http://folk.uio.no/oyvinst/linux/hda-codec.txt, lspci here: http://folk.uio.no/oyvinst/linux/lspci.txt). MPlayer seems to have a hard time sycing audio/video, pulseaudio issues ratelimit warnings to syslog, and video goes too fast. Totem plays video even faster than MPlayer. VLC is also no-go. 

Tried many permutations of different values for parameters position_fix, enable_msi and bdl_pos_adj of the snd_hda_intel kernel module, but to no avail. The only thing that did work was to revert commit 7b3a177b0d4f92b3431b8dca777313a07533a710 from the kernel source.
Comment 4 Éric Piel 2010-05-04 21:17:10 UTC
Same codec as on my laptop (hp 2510p), but for me it works if I don't put any options.

Have you tried just position_fix=1 and nothing else?
Comment 5 Øyvind Stegard 2010-05-04 21:52:16 UTC
Yes, now verified by values under /sys/module/snd_hda_intel/parameters:
$ cat position_fix 
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
$ cat bdl_pos_adj 
1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1

With these values, I have a video clip that doesn't play properly (don't know if 48KHz audio is causing it, or the audio codec, or pulseaudio in combination with all that). Also, when this clip is played simultaneously with audio in some other app, that audio will also start skipping, and pulseaudio issues ratelimit warnings about "X events suppressed" in syslog all the time. With the commit mentioned in this bug reverted, the clip plays fine (then also with position_fix=1 parameter only). Seems like it affects only certain videos, thus I would assume certain pulseaudio+ALSA usage patterns (don't really know what factor plays a role here).
Comment 6 Éric Piel 2010-05-04 22:02:26 UTC
Have you tried with simple mp3's? In my case, I was doing:
time mplayer -endpos 30 sound-file-which-lasts-more-than-thirty-sec.mp3

And it was apparent that it happened with any file if the total wall clock time was slightly less than 30s. (The first run doesn't count, everything needs to be in the cache.) Is it different for you?
Comment 7 Øyvind Stegard 2010-05-04 23:10:19 UTC
The simple 30 second MP3 playback test is OK with standard 2.6.34-rc6, both with and without position_fix=1. Real time is about 31 seconds with -endpos 30, which seems fair enough. So my video problems are perhaps somewhat different, but I know one fact: reverting the commit here makes the video playback work, suggesting that something is still wrong somewhere. Perhaps a different bug report is suitable.
Comment 8 Øyvind Stegard 2010-05-05 01:27:57 UTC
In addition to the problematic video clip I mentioned, Flash-plugin also has A/V synchronization problems with streaming video content (parts of the audio is randomly chopped away). Never seen Flash behave like that before. Again it works much better with the commit reverted.
Comment 9 Jaroslav Kysela 2010-05-05 05:57:28 UTC
Please, could you open new bug and follow http://www.alsa-project.org/main/index.php/XRUN_Debug to check what low-level driver returns (attach full log from time when problem occurs) - use value 29.
Comment 10 Øyvind Stegard 2010-05-05 16:27:44 UTC
(In reply to comment #9)
> Please, could you open new bug and follow
> http://www.alsa-project.org/main/index.php/XRUN_Debug to check what low-level
> driver returns (attach full log from time when problem occurs) - use value
> 29.

Done: https://bugzilla.kernel.org/show_bug.cgi?id=15912

Note You need to log in before you can comment on or make changes to this bug.