This should be fixed by commit 8815cd030fdd73932a791d1f06194c8db807cde7 "ALSA: hda - Add position_fix quirk for Biostar mobo", currently in the sound-2.6 tree.

Linus has pulled the commit, so this regression should now be fully fixed.

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.

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?

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

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?

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.

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.

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.

(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