Created attachment 26236 [details] Log xrun_debug 29, MPlayer 60 seconds of movie clip Problem originally described in https://bugzilla.kernel.org/show_bug.cgi?id=15796#c3 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. As per requested in https://bugzilla.kernel.org/show_bug.cgi?id=15796#c9 I have created a new bug report here. I've done the xrun testing, and I'm seeing something obscure.. 1) When I set xrun_debug to 29 the movie starts playing smoothly, sync is OK, lots of debug is logged (see attached log files). Same goes for Totem, it can play the file normally when xrun_debug is set to 29. 2) When I set xrun_debug back to 0 the movie starts to stutter again in MPlayer, like originally described. I can toggle this while the movie is playing, and behaviour of MPlayer alters itself accordingly. Accordingly, Totem starts playing faster and skips if I set xrun_debug back to 0. 3) Flash randomly drops parts of audio (probably trying to sync) in video streaming with xrun_debug 0, but seems OK when xrun_debug is set to 29, although the audio definitely crackles here and seems a bit worse with MSI enabled. I've tried listening carefully, and I think I can hear audio crackling sometimes with MPlayer and Totem as well, though not 100% sure. All tests have been done with position_fix=1 and msi either disabled or enabled, no other kernel module parameters were touched. Xrun log file names reflect parameter values. I've compressed the files since they turn out on the larger side. All audio output goes through Pulseaudio in all tests (except for the kernel, audio stack is standard Ubuntu Lucid). http://folk.uio.no/oyvinst/linux/hda-codec.txt http://folk.uio.no/oyvinst/linux/lspci.txt
Created attachment 26237 [details] Log xrun_debug 29, Totem 60 seconds of movie clip
Created attachment 26238 [details] Log xrun_debug 29, (Adobe)Flash video streaming
Created attachment 26239 [details] Log xrun_debug 29, MPlayer 60 seconds of movie clip, MSI disabled
Created attachment 26240 [details] Log xrun_debug 29, Totem 60 seconds of movie clip, MSI disabled
Created attachment 26241 [details] Log xrun_debug 29, (Adobe)Flash video streaming, MSI disabled
Here is the issue: May 5 17:22:13 blackelf kernel: [ 1324.352643] hwptr_update: pcmC0D0p:0: pos=7335/8192/16384, hwptr=0/72871/72871/65536 May 5 17:22:13 blackelf kernel: [ 1324.372076] period_update: pcmC0D0p:0: pos=8192/8192/16384, hwptr=857/72871/73728/65536 May 5 17:22:13 blackelf kernel: [ 1324.385036] hwptr_update: pcmC0D0p:0: pos=8764/8192/16384, hwptr=572/73728/74300/65536 May 5 17:22:13 blackelf kernel: [ 1324.386796] hwptr_update: pcmC0D0p:0: pos=8824/8192/16384, hwptr=60/74300/74360/65536 May 5 17:22:13 blackelf kernel: [ 1324.386814] period_update: pcmC0D0p:0: pos=8824/8192/16384, hwptr=16384/74360/90744/65536 May 5 17:22:13 blackelf kernel: [ 1324.386819] PCM: hw_ptr skipping! [Q] (pos=8824, delta=16384, period=8192, jdelta=0/92/0, hw_ptr=74360/74360) May 5 17:22:13 blackelf kernel: [ 1324.386832] hwptr_update: pcmC0D0p:0: pos=8825/8192/16384, hwptr=1/74360/74361/65536 The period_update is called twice with wrong timing with ring buffer positions 8192 and 8824. The delay between these two calls must be >= period_size. It's clearly lowlevel driver problem (snd-hda-intel). Have you tried to set bdl_pos_adj module paramter to some highter values like 32 or 64?
I have tested different bdl_pos_adj values, including 0, 1, 32 and 64. Will test it again, just to be sure. On another note, disabling Radeon Kernel Modesetting seems to resolve the issue, no clue why of course. Video playback works, Flash streaming works with no audio gaps, couldn't hear any crackling, etc. Also, xrun_debug contains no hw_ptr skipping errors after disabling KMS. So maybe some bad interaction between snd-hda-intel and radeon..
Nope, bdl_pos_adj does not help, even tried as high as 512.
Created attachment 26257 [details] Use wall clock to check for too early interrupts
Please, try patch in comment#9 in setup where you noticed this problem.
(In reply to comment #10) > Please, try patch in comment#9 in setup where you noticed this problem. Does not resolve the issue, unfortunately. Perhaps it's slightly better if I use position_fix=1 than without patch, but that might as well be placebo. It all seems very sensitive graphics operations. Totem plays video OK in fullscreen, but speeds it up significantly in normal window size. MPlayer stutters in windowed mode, but plays more or less OK, though with some stuttering, when in fullscreen. Also, the audio crackling problem is still here. If I do: $ gst-launch-0.10 audiotestsrc ! pulsesink to genereate a pure sound which easily reveals crackling, and then play a movie in fullscreen with no sound at all, pops and crackles in the test sound appears. The system/CPU is nowhere near overloaded during test, however I don't know about the GPU/KMS. Test video seems to not matter here, even a very small-sized silent video played back in fullscreen, and even without Compiz enabled, causes audio troubles with this test.
Please, attach the xrun_debug 29 log (only one) for most broken situation with the patch from comment#9 applied. Also, don't use any snd-hda-intel module options (to know the test method).
Created attachment 26259 [details] Log xrun_debug 29, mplayer, no snd-hda-intel options As before, playback becomes smoother when xrun_debug is set to 29 ... Tested with wall clock patch applied.
Bugzilla was very slow to respond when I uploaded the last attachment, so no email notification seems to have been sent. But the upload itself looks OK.
Bad thing from log: May 6 16:52:37 blackelf kernel: [ 153.789070] hwptr_update: pcmC0D0p:0: pos=13936/8192/16384, hwptr=8/357992/358000/344064 May 6 16:52:37 blackelf kernel: [ 153.791316] period_update: pcmC0D0p:0: pos=14016/8192/16384, hwptr=16464/358000/374464/344064 May 6 16:52:37 blackelf kernel: [ 153.791323] PCM: hw_ptr skipping! [Q] (pos=14016, delta=16464, period=8192, jdelta=0/93/0, hw_ ptr=358000/358000) May 6 16:52:37 blackelf kernel: [ 153.791442] hwptr_update: pcmC0D0p:0: pos=14024/8192/16384, hwptr=88/358000/358088/344064 The period_update must be around 0 (zero) in this case. It seems that more complicated condition using the wallclk must be implemented in snd-hda-intel driver to avoid wrong snd_pcm_elapsed() calls.
Created attachment 26306 [details] Use wall clock to check for too early interrupts (2nd version) Please, test this patch.
Version 2 wall clock patch seems to resolve the A/V sync and speed issues with MPlayer/Totem and video playback. No snd-hda-intel options used, KMS enabled. The crackling noise issue persists, however. When testing with pure sound generated with gstreamer audiotestsrc and playing fullscreen movie with -nosound simultaneously, I got a couple of these at one point: [...] May 10 09:29:46 blackelf kernel: [ 1111.890852] period_update: pcmC0D0p:0: pos=16337/8192/16384, hwptr=12802/658895/671697/655360 May 10 09:29:46 blackelf kernel: [ 1111.890862] PCM: Lost interrupts? [Q] (stream=0, delta=12802, new_hw_ptr=671697, old_hw_ptr=658895) [...] However, I think that was with bdl_pos_adj=0. So, to eliminate errors in testing parameters, I've done an xrun debug with fullscreen Flash playback which consistently produces crackling noise in background test sound, with no snd-hda-intel parameters. I'm going to attach that xrun debug log, even though it does not contain hw pointer skipping errors.
Created attachment 26309 [details] Log xrun_debug 29, Flash fullscreen+gstaudiotestsrc, crackling, no snd-hda-intel options
Created attachment 26310 [details] Use wall clock to check for too early interrupts (3nd version) Thank you. I've added another correction. Please, test this in same way.
Created attachment 26312 [details] xrun_debug 29, MPlayer, wall clock patch 3 3rd wall clock patch gives A/V sync problems again. Crackling is slightly more audible in that the skips are longer and more pronounced, rather than just a series of random small pops. Setting xrun_debug to 29 again alters behaviour of video playback (becomes smoother). Attachment is xrun debug log from 15 seconds of MPlayer playback. Now at kernel 2.6.34-rc7 (last time I pulled from mainline tree). I get kernel log message about snd-hda-intel IRQ work-around being activated (and suggesting bigger bdl_pos_adj). Did not test any options to snd-hda-intel module.
Bugzilla.kernel.org is really slow again.
One additional note: even though wall clock v3 patch does not resolve A/V sync problems, it is still better than no patch, or wall clock patch v1.
Created attachment 26314 [details] Use wall clock to check for too early interrupts (4rd version) Please, test this.
Wall clock patch v4 again seems to resolve most A/V sync issues, but not the crackling. I noticed the kernel thread [hd-audio0] is using quite a bit of CPU (up to 40-50% on a Core Duo 2GHz system) when pops occur in audio, even for simple test audio stream. It's erratic and comes and goes, even while playing fullscreen video with no sound together with background test sound. Increasing bdl_pos_adj seemed to help only a little. However, the [hd-audio0] CPU usage is also a problem on the standard 2.6.32-based Ubuntu kernel on my system (which I have reported as a bug to Ubuntu). Summary: the pops/crackles have always been there with KMS on Ubuntu 10.04, however, A/V sync issues with kernel >= 2.6.34-rc6 seems to be fixed by either wall clock patch v2 or v4 in this bug report. The only workaround I have found so far to remove crackling is to disable KMS. Also, removing Pulseaudio from the equation (output directly to ALSA) does not help in any case IIRC.
Have you tried to play with 'enable_msi' module parameter?
Created attachment 26315 [details] Use wall clock to check for too early interrupts (5th version) This version might reduce hd-audio thread usage. Please, test it.
Tested v5, A/V sync OK. Looks like CPU usage of [hd-audio0] thread is also reduced. Didn't see any ~40-50% CPU spikes now. But still pops in audio when running for instance fullscreen Flash video, or fullscreen MPlayer video, even though system is not overloaded (according to top). If I run fullscreen MPlayer video (with perhaps ~45% CPU utilization total), and drag a small window over it, more pops in audio test sound occur (graphical ops and movie are smooth, though). What's your thoughts about radeon KMS somehow affecting snd-hda-intel (IRQs) or system timing ? Since it all goes away when I disable KMS, for whatever reason. Problems described in this bug report seem largely unaffected by MSI-setting (enable_msi=0 or enable_msi=1) as well as position_fix and bdl_pos_adj. I'm sorry, it's hard to conclude, but at least looks like A/V sync issue is fixed..
Thank you for testing. Appearently, there might be a clash in the PCI device or bus configuration. Unfortunately, I'm not expert in this area. It might be a good idea to check the PCI device setup using lspci (compare good and bad behaviour).
(In reply to comment #28) > Thank you for testing. Appearently, there might be a clash in the PCI device > or > bus configuration. Unfortunately, I'm not expert in this area. It might be a > good idea to check the PCI device setup using lspci (compare good and bad > behaviour). Indeed, the PCI configuration for radeon is different under KMS (bad) compared to UMS (good): --- lspci-radeon-good.txt 2010-05-10 19:13:21.003538070 +0200 +++ lspci-radeon-bad.txt 2010-05-10 19:19:45.254230183 +0200 [...] - Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ [...] - Interrupt: pin A routed to IRQ 16 + Interrupt: pin A routed to IRQ 30 [...] - Capabilities: [80] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- - Address: 0000000000000000 Data: 0000 + Capabilities: [80] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+ + Address: 00000000fee0100c Data: 41b9 + Kernel driver in use: radeon There is no difference for the HDA Intel PCI configuration. Also, KMS causes problems for my wireless PCI network controller/driver iwl3945 (drops connection during Flash fullscreen video streaming, when snd-hda-intel crackling is at its worst :). So, my system probably has issues out of scope for this bug report, wrt. to KMS. Thank you for all help.
[I disabled radeon MSI by editing drivers/gpu/drm/radeon/radeon_irq_kms.c. System worked OK, no longer diff between KMS/UMS lspci, however, it did not resolve audio issues. So probably too much speculation on cause of error from my side here.]
I have the same problem here on my girlfriend's laptop. The hardware is slightly different but almost the same (Radeon Xpress 200M, Realtek ALC660) The problem was exactly the same, latest did resolve the sync issue, but the crackling does stay. I suspect that more people are going to be hit by this problem since hda-intel cards are quite common and more distributions are now moving to Radeon KMS by default (and users are upgrading). Who is going to further investigate this bug, or to which bugzilla should this problem otherwise be reported?
I would suggest to post a question about this problem on LKML.
There are several similar bug reports on Launchpad, and I've created a bug report on freedesktop.org for the X.org radeon driver team. https://bugs.launchpad.net/xserver-xorg-driver-ati/+bug/564376 https://bugs.launchpad.net/xserver-xorg-driver-ati/+bug/578342 https://bugs.launchpad.net/xserver-xorg-driver-ati/+bug/571770 https://bugs.freedesktop.org/show_bug.cgi?id=28106
Hello, I have a similar problem with hda-intel ALC883 since kernel 2.6.33 (problems are identical with kernel 2.6.34 and 2.6.35-rc3). There are quick short gaps with the default options. In turn, bdl_pos_adj=0 results in fast sound. position_fix=1 does not fix it. I have tried several other options to no avail. The card worked fine with previous kernels (2.6.32 and previous ones). In fact, I compiled kernel 2.6.32 with the same compiler and kernel parameters I had used for 2.6.34. Next I copied all .ko files from sound/pci/hda/ (2.6.32) into /lib/modules/2.6.34-whatever/kernel/sound/pci/hda/. Then I rebooted into the new kernel and recompiled alsa. This workaround appeared to have solved the issue for a while. Then problems reappeared (possibly after a system update). lspci: 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) I have a Nvida card here. And problems are identical with both the nouveau and the proprietary drivers. Therefore I guess this is an alsa issue and it is unrelated to the radeon driver. Best regards, Miro
This bug is very easy to trigger on my emu10k1 sound card: (which is 04:00.0 Generic system peripheral [0841]: Creative Labs SB Live! EMU10k1 (rev 07) Subsystem: Creative Labs CT4830 SBLive! Value Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32 (500ns min, 5000ns max) Interrupt: pin A routed to IRQ 21 Region 0: I/O ports at e800 [size=32] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: EMU10K1_Audigy Kernel modules: snd-emu10k1 ) It happens immediately when playing certain FLAC audio files and it happens on _all_ other audio and video files as soon as you quickly hit pause/unpause in mplayer (sometimes it happens immediately, sometimes after 2-5 seconds of playing), and then, voilа! everything goes awry.
Handled-By : Jaroslav Kysela <perex@perex.cz>
Crackling issues persist with kernel 2.6.36 even if they are somehow milder than there were with kernels 33-35.
I have compiled alsa-driver-1.0.23.83.gd4453.783.g952c6.tar.bz2 and added "options snd-hda-intel model=clevo-m540r" to /etc/modprobe.d/alsa-base.conf This does not entirely prevent the crackling, but makes it less annoying.
From the models I have tried this far model=alc883-6stack-dig is the one which best palliates the crackling. It is not yet perfect, but it is bearable.
power_save=0 and power_save_controller=N also help
The patch from comment #26 was merged for 2.6.35-rc1 as: ---- commit e54637205b00837bf00de916b0ae361c6aa0b139 Author: Jaroslav Kysela <perex@perex.cz> Date: Tue May 11 10:21:46 2010 +0200 [ALSA] snd-hda-intel: use WALLCLK register to check for early irqs ---- and fixes part of this issue. Audio crackling and iwl3945 connection drops on some (high?) gpu loads still persist, as far as I understand. References: https://bugs.launchpad.net/xserver-xorg-driver-ati/+bug/564376 References: https://bugs.launchpad.net/xserver-xorg-driver-ati/+bug/578342 References: https://bugs.launchpad.net/xserver-xorg-driver-ati/+bug/571770 References: https://bugs.freedesktop.org/show_bug.cgi?id=28106
The crackling issue improved with 2.6.37 (kind of usable) and worsened with 2.6.38 (completely unbearable). I have purchased an external USB sound card (which works very well) and completely disabled the built-in ALC883. One could think that there is an issue with my laptop. However, the problems are specific to certain Linux kernels. Windows, FreeBSD and Solarix systems work fine with this card as well as Linux kernels =< 2.6.32. Even Debian with the FreeBSD kernel works fine.
This is still a problem on the latest Ubuntu 11.04 updates, and still seems (for me) confined to the use of Radeon kernel modesetting. When kms is off, the problem seems to lessen or disappear. With kms on, audio crackles and iwl3945 becomes unstable when GPU load increases. There has been no real activity on the upstream radeon bug report on freedesktop.org. Does anyone have any ideas? (FYI I'm currently running ubuntu x86-64 kernel 2.6.38.8.22, xorg 7.6, radeon 6.14.99+git20110504, and mesa 7.11.0+git20110504)
(In reply to comment #43) > This is still a problem on the latest Ubuntu 11.04 updates, and still seems > (for me) confined to the use of Radeon kernel modesetting. > > When kms is off, the problem seems to lessen or disappear. With kms on, > audio > crackles and iwl3945 becomes unstable when GPU load increases. Confirming that this is still a very real problem in latest Ubuntu 11.04 running kernel 2.6.38 on Thinkpad Z61m laptop. Fullscreen Youtube videos run great, but audio is distorted/crackling. I've yet to find any combination of options to radeon or snd-hda-intel modules which rectifies this issue.
Hasn't been any comment in a year, so I'll add that it's still a problem in 3.5.3. I'm on a Thinkpad T60 with radeon and sna-hda-intel. Comment 44 describes issue exactly.
I have Acer Extenza 5620Z. There is problem with crackling on ALC268 codec. Problem exists on 3.2 and 3.5 Ubuntu kernels. But bug with crackling sound is reproducible only for some "magic" case: The trick is that issue reproducible only after full power-off of freshly installed system (or even kernel, the magic is that issue dissappeared after I install 6.5 and reboot my system, but it appeared again after full power-off).
Different machine, different codec Therefore please file a different bug! Thanks
Sorry for inconvinience. I'll file it ASAP.
Problem still not solved. But being checked, we need a good number of affected users send the error details.
Does the problem still exist? Here I'm interested in *only* the original bug, i.e. AD1981 codec on Thinkpad. The other machines have other controllers and codecs, so they are basically different issues.
@Takashi lwai: Yes this bug still exists as of 3.12
Do you mean the crackling sound issue, or A/V sync issue? Supposing the former, are you testing with PulseAudio or without? In the case of recent PA, the missing interrupts shouldn't be a big issue because the update timing is controlled by PA using the POSIX timer without irq updates. But, this relies on the accurate position reporting from the driver. That is, if PA is still producing the bad sound, the position report from the hardware (thus the calculation in the driver) is still inaccurate.
The crackling sound issue. I am testing with PulseAudio (though in the past it hasn't made a difference).
OK, then try to gather some tracepoints data by activating /sys/kernel/debug/tracing/events/hda_intel/enable while the crackling sound happens. Also, please give alsa-info.sh output on your machine. Run it with --no-upload option and attach the output to this bugzilla.
if the purpose of adding loopback mixing playback switch is to save power by turn off the unused aamix paths, why the driver did not setup the power widget ? Node 0x14 [Power Widget] wcaps 0x500500: Mono Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 13 0x0d 0x0e 0x0f 0x10 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1d