Bug 15912 - Audio/video sync and crackling issues with snd-hda-intel (AD1981 codec)
Audio/video sync and crackling issues with snd-hda-intel (AD1981 codec)
Status: RESOLVED INSUFFICIENT_DATA
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA)
All Linux
: P1 normal
Assigned To: Jaroslav Kysela
:
Depends on:
Blocks: 15310
  Show dependency treegraph
 
Reported: 2010-05-05 16:20 UTC by Øyvind Stegard
Modified: 2015-02-19 15:45 UTC (History)
16 users (show)

See Also:
Kernel Version: 3.12
Tree: Mainline
Regression: Yes


Attachments
Log xrun_debug 29, MPlayer 60 seconds of movie clip (147.71 KB, application/x-gzip)
2010-05-05 16:20 UTC, Øyvind Stegard
Details
Log xrun_debug 29, Totem 60 seconds of movie clip (269.94 KB, application/x-gzip)
2010-05-05 16:21 UTC, Øyvind Stegard
Details
Log xrun_debug 29, (Adobe)Flash video streaming (349.00 KB, application/x-gzip)
2010-05-05 16:22 UTC, Øyvind Stegard
Details
Log xrun_debug 29, MPlayer 60 seconds of movie clip, MSI disabled (147.71 KB, application/x-gzip)
2010-05-05 16:23 UTC, Øyvind Stegard
Details
Log xrun_debug 29, Totem 60 seconds of movie clip, MSI disabled (269.94 KB, application/x-gzip)
2010-05-05 16:24 UTC, Øyvind Stegard
Details
Log xrun_debug 29, (Adobe)Flash video streaming, MSI disabled (349.00 KB, application/x-gzip)
2010-05-05 16:25 UTC, Øyvind Stegard
Details
Use wall clock to check for too early interrupts (2.94 KB, patch)
2010-05-06 11:41 UTC, Jaroslav Kysela
Details | Diff
Log xrun_debug 29, mplayer, no snd-hda-intel options (137.12 KB, application/x-gzip)
2010-05-06 15:07 UTC, Øyvind Stegard
Details
Use wall clock to check for too early interrupts (2nd version) (3.28 KB, patch)
2010-05-10 06:04 UTC, Jaroslav Kysela
Details | Diff
Log xrun_debug 29, Flash fullscreen+gstaudiotestsrc, crackling, no snd-hda-intel options (322.87 KB, application/x-gzip)
2010-05-10 07:56 UTC, Øyvind Stegard
Details
Use wall clock to check for too early interrupts (3nd version) (3.28 KB, patch)
2010-05-10 08:13 UTC, Jaroslav Kysela
Details | Diff
xrun_debug 29, MPlayer, wall clock patch 3 (87.68 KB, application/x-gzip)
2010-05-10 10:21 UTC, Øyvind Stegard
Details
Use wall clock to check for too early interrupts (4rd version) (3.63 KB, patch)
2010-05-10 10:38 UTC, Jaroslav Kysela
Details | Diff
Use wall clock to check for too early interrupts (5th version) (4.23 KB, patch)
2010-05-10 14:19 UTC, Jaroslav Kysela
Details | Diff

Description Øyvind Stegard 2010-05-05 16:20:42 UTC
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
Comment 1 Øyvind Stegard 2010-05-05 16:21:31 UTC
Created attachment 26237 [details]
Log xrun_debug 29, Totem 60 seconds of movie clip
Comment 2 Øyvind Stegard 2010-05-05 16:22:27 UTC
Created attachment 26238 [details]
Log xrun_debug 29, (Adobe)Flash video streaming
Comment 3 Øyvind Stegard 2010-05-05 16:23:52 UTC
Created attachment 26239 [details]
Log xrun_debug 29, MPlayer 60 seconds of movie clip, MSI disabled
Comment 4 Øyvind Stegard 2010-05-05 16:24:22 UTC
Created attachment 26240 [details]
Log xrun_debug 29, Totem 60 seconds of movie clip, MSI disabled
Comment 5 Øyvind Stegard 2010-05-05 16:25:25 UTC
Created attachment 26241 [details]
Log xrun_debug 29, (Adobe)Flash video streaming, MSI disabled
Comment 6 Jaroslav Kysela 2010-05-05 18:27:36 UTC
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?
Comment 7 Øyvind Stegard 2010-05-05 18:57:37 UTC
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..
Comment 8 Øyvind Stegard 2010-05-05 19:19:45 UTC
Nope, bdl_pos_adj does not help, even tried as high as 512.
Comment 9 Jaroslav Kysela 2010-05-06 11:41:28 UTC
Created attachment 26257 [details]
Use wall clock to check for too early interrupts
Comment 10 Jaroslav Kysela 2010-05-06 11:43:29 UTC
Please, try patch in comment#9 in setup where you noticed this problem.
Comment 11 Øyvind Stegard 2010-05-06 13:41:39 UTC
(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.
Comment 12 Jaroslav Kysela 2010-05-06 13:49:05 UTC
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).
Comment 13 Øyvind Stegard 2010-05-06 15:07:44 UTC
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.
Comment 14 Øyvind Stegard 2010-05-07 13:57:23 UTC
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.
Comment 15 Jaroslav Kysela 2010-05-07 15:54:36 UTC
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.
Comment 16 Jaroslav Kysela 2010-05-10 06:04:39 UTC
Created attachment 26306 [details]
Use wall clock to check for too early interrupts (2nd version)

Please, test this patch.
Comment 17 Øyvind Stegard 2010-05-10 07:52:08 UTC
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.
Comment 18 Øyvind Stegard 2010-05-10 07:56:20 UTC
Created attachment 26309 [details]
Log xrun_debug 29, Flash fullscreen+gstaudiotestsrc, crackling, no snd-hda-intel options
Comment 19 Jaroslav Kysela 2010-05-10 08:13:34 UTC
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.
Comment 20 Øyvind Stegard 2010-05-10 10:21:09 UTC
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.
Comment 21 Øyvind Stegard 2010-05-10 10:24:50 UTC
Bugzilla.kernel.org is really slow again.
Comment 22 Øyvind Stegard 2010-05-10 10:36:22 UTC
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.
Comment 23 Jaroslav Kysela 2010-05-10 10:38:44 UTC
Created attachment 26314 [details]
Use wall clock to check for too early interrupts (4rd version)

Please, test this.
Comment 24 Øyvind Stegard 2010-05-10 11:51:07 UTC
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.
Comment 25 Jaroslav Kysela 2010-05-10 14:09:42 UTC
Have you tried to play with 'enable_msi' module parameter?
Comment 26 Jaroslav Kysela 2010-05-10 14:19:06 UTC
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.
Comment 27 Øyvind Stegard 2010-05-10 16:34:53 UTC
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..
Comment 28 Jaroslav Kysela 2010-05-10 17:06:31 UTC
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).
Comment 29 Øyvind Stegard 2010-05-10 17:31:29 UTC
(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.
Comment 30 Øyvind Stegard 2010-05-10 18:04:20 UTC
[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.]
Comment 31 Maarten Fonville 2010-05-12 19:59:16 UTC
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?
Comment 32 Jaroslav Kysela 2010-05-12 20:26:14 UTC
I would suggest to post a question about this problem on LKML.
Comment 33 Jason Porter 2010-05-14 14:08:02 UTC
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
Comment 34 Miro Moman 2010-06-23 09:32:54 UTC
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
Comment 35 Artem S. Tashkinov 2010-07-01 18:17:44 UTC
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.
Comment 36 Rafael J. Wysocki 2010-07-09 22:41:20 UTC
Handled-By : Jaroslav Kysela <perex@perex.cz>
Comment 37 Miro Moman 2010-10-26 22:18:39 UTC
Crackling issues persist with kernel 2.6.36 even if they are somehow milder than there were with kernels 33-35.
Comment 38 Miro Moman 2010-10-27 01:35:05 UTC
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.
Comment 39 Miro Moman 2010-10-27 12:31:03 UTC
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.
Comment 40 Miro Moman 2010-10-27 14:34:03 UTC
power_save=0 and power_save_controller=N also help
Comment 41 Florian Mickler 2010-12-22 09:16:26 UTC
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
Comment 42 Miro Moman 2011-03-19 12:59:44 UTC
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.
Comment 43 Jason Porter 2011-05-06 20:09:09 UTC
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)
Comment 44 Øyvind Stegard 2011-07-13 21:32:01 UTC
(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.
Comment 45 Stephen E. Baker 2012-09-07 16:43:25 UTC
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.
Comment 46 Ivan Matylitski 2012-09-15 08:15:14 UTC
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).
Comment 47 Alan 2012-09-15 14:03:06 UTC
Different machine, different codec

Therefore please file a different bug!

Thanks
Comment 48 Ivan Matylitski 2012-09-15 20:39:48 UTC
Sorry for inconvinience. I'll file it ASAP.
Comment 49 Emanuel Negromonte 2012-10-02 14:02:18 UTC
Problem still not solved. But being checked, we need a good number of affected users send the error details.
Comment 50 Takashi Iwai 2013-11-27 17:18:15 UTC
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.
Comment 51 Stephen E. Baker 2013-12-07 16:59:32 UTC
@Takashi lwai: Yes this bug still exists as of 3.12
Comment 52 Takashi Iwai 2013-12-13 13:28:59 UTC
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.
Comment 53 Stephen E. Baker 2013-12-16 21:35:32 UTC
The crackling sound issue.  I am testing with PulseAudio (though in the past it hasn't made a difference).
Comment 54 Takashi Iwai 2013-12-17 07:04:50 UTC
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.
Comment 55 Raymond 2013-12-18 00:38:27 UTC
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

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