Audio stutters and glitches (Karmic, Intel HDA ICH8)

To rule out some further things:
- It does not make a difference if the 3D effects are turned on or off
- I does not make a difference if the proprietary nvidia driver is used or not

I guess the most important thing right now would be to find out if this is actually a process scheduling problem or a problem in the hda-intel driver. But I have run out of ideas how to find out about that...

Thanks for any help, Alex

Hi Alexander and thanks for the effort of trying to trace this bug down! Some thoughts:

* You have these "unusual" lines in dmesg:
hda_intel: probe_mask set to 0x1 for device 17aa:20ac
hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x012f0c00

According to http://www.kernel.org/pub/linux/kernel/people/tiwai/docs/HD-Audio.html , the latter is just a warning but I think it could be related to what you're experiencing. Read the section about Codec-Probing Problem.

* Another monitor to check could be latencytop (sudo apt-get install latencytop), which logs kernel activities.

Thanks for the pointers, David. Going to try digging into both directions.
I got some reading to do it seams, but I find this latencytop really intriguing I have to say.

A cheers to Sweden from the other side of the Baltic,
Alex

If you're using VLC, make sure you're using the pulse output for it and not
the ALSA output.

On Nov 9, 2009 1:25 PM, "Alexander Bethke" <email address hidden>
wrote:

Public bug reported:

I'm having the problem of crackling and stuttering audio since Ubuntu
Karmic (final). Sometimes gstreamer even kills the current playback
stream with an error. I did a fresh install to make sure it is not
caused by any update artefacts. I have not had any audio problems with
this setup since Intrepid: ThinkPad R61, soundcard: 82801H (ICH8 Family)
HD Audio Controller

I opened a new bug as even though the symptoms seem to be similar to
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/376374 . Still I
think this is not a duplicate of that bug for the following reasons:
- As opposed to some people with the above-mentioned bug, the problem is not
fixed by changing the resampling method.
- Also when I kill pulseaudio and let a player use alsa straight, the
problem persists.
Based on that I guess the problem should not be in pulseaudio, but either in
the alsa driver or something else. I somehow have a hunch that there could
be something broken in the process-scheduling/resource-prioritisation. Here
my observations regarding that:

The drop-outs appear irregularly. Sometimes there is around half a minute
between them, sometimes the appear several times a second. It seems to
depend on what happens else in the system, even though I could not make out
any pattern. System and CPU load figures are not proportional to the
problems, neither are net or disk I/O. I could not make out any suspicious
processes in top or system monitor.
Another observation is that there is similar stuttering behaviour in the
mouse movement, that one hangs frequently for a little moment. Sometimes I
can reproduce that by hitting enter in the firefox search box while circling
the mouse pointer, but then sometimes this does not interrupt the
mouse-movement at all.

In lack of an idea how to log on the alsa-level, I made a verbose-log
(attached) of pulse playing back a file (using vlc), producing those
glitches. I gonna attach a log with an output example of vlc and a
corresponding top snapshot corresponding to this case.

I know the information is not very focussed, but this should get you
started to help me to get to the right places for finding out what is
actually wrong.

Regards, Alex

ProblemType: Bug
Architecture: i386
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog]
  Subdevices: 2/2
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/pcmC0D0p: alex 3269 F...m vlc
 /dev/snd/timer: alex 3269 F.... vlc
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xfe220000 irq 17'
  Mixer name : 'Analog Devices AD1984'
  Components : 'HDA:11d41984,17aa20bb,00100400'
  Controls : 29
  Simple ctrls : 18
Date: Mon Nov 9 19:42:18 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
NonfreeKernelModules: nvidia
Package: alsa-base 1.0.20+dfsg-1ubuntu5
PackageArchite...

On Nov 9, 2009 3:10 PM, "David Henningsson" <email address hidden>
wrote:

Hi Alexander and thanks for the effort of trying to trace this bug down!
Some thoughts:

* You have these "unusual" lines in dmesg:
hda_intel: probe_mask set to 0x1 for device 17aa:20ac
hda-intel: azx_get_response timeout, switching to polling mode: last
cmd=0x012f0c00

According to http://www.kernel.org/pub/linux/kernel/people/tiwai/docs
/HD-Audio.html , the latter is just a warning but I think it could be
related to what you're experiencing. Read the section about Codec-
Probing Problem.

* Another monitor to check could be latencytop (sudo apt-get install
latencytop), which logs kernel activities.

-- Audio stutters and glitches (Karmic, Intel HDA ICH8)
https://bugs.launchpad.net/bugs/479375 You...

Those aren't grave errors.

On Nov 9, 2009 3:10 PM, "David Henningsson" <email address hidden>
wrote:

Hi Alexander and thanks for the effort of trying to trace this bug down!
Some thoughts:

* You have these "unusual" lines in dmesg:
hda_intel: probe_mask set to 0x1 for device 17aa:20ac
hda-intel: azx_get_response timeout, switching to polling mode: last
cmd=0x012f0c00

According to http://www.kernel.org/pub/linux/kernel/people/tiwai/docs
/HD-Audio.html , the latter is just a warning but I think it could be
related to what you're experiencing. Read the section about Codec-
Probing Problem.

* Another monitor to check could be latencytop (sudo apt-get install
latencytop), which logs kernel activities.

-- Audio stutters and glitches (Karmic, Intel HDA ICH8)
https://bugs.launchpad.net/bugs/479375 You...

On Mon, Nov 9, 2009 at 1:17 PM, Alexander Bethke
<email address hidden> wrote:
> - Also when I kill pulseaudio and let a player use alsa straight, the problem persists.

Killing pulseaudio is insufficient, because it will autospawn. If you
intend to bypass PA completely for testing, you need also to disable
autospawn:

echo autospawn = no|tee -a ~/.pulse/client.conf

Of course, killall pulseaudio afterward...

@Daniel: They are not grave errors, but can polling mode (which btw was not at boot but a few minutes later) increase the risc of ALSA underrunning? I'm speculating that if there is no correct IRQ coming in at the right time, the computer might decide to do other things for too long.

Btw, did your changes to increase the DMA buffer reach Karmic?

On Tue, Nov 10, 2009 at 7:30 AM, David Henningsson
<email address hidden> wrote:
> @Daniel: They are not grave errors, but can polling mode (which btw was
> not at boot but a few minutes later) increase the risc of ALSA
> underrunning? I'm speculating that if there is no correct IRQ coming in
> at the right time, the computer might decide to do other things for too
> long.

Theoretically, no.

> Btw, did your changes to increase the DMA buffer reach Karmic?

No. They should be targeted for 10.04/Lucid.

@Daniel: Thanks for the tips. Actually I have turned off pulse autospawning before doing any tests for this bug report, and verified that pulseaudio is not in the process list after killing it. (I had read https://wiki.ubuntu.com/PulseAudio/Log before) ;)

Also to make sure there is no confusion about the backend selection, I switched vlc and exaile to use the alsa sink by manual selection, additionally. So I guess it's safe to say that the problem is actually not in pulseaudio. (All my observations I post here will be with pulseaudio off, just to make clear.)

I did some testing with latencytop, but for my perception there is nothing peculiar in the results. The system is mostly waiting for the CPU. I guess that's normal? In the attachment is a pretty exemplary plot from latencytop, perhaps the more experienced eyes amongst us can pick something up from there. Does alsa have a separate process that I could have a special look at? I tried monitoring [hd-audio0], but that one barely said anything in latencytop. Otherwise, would that point to the fact that this would not be a scheduling issue? (Hence the mouse cursor stuttering I experience being unrelated.)

Just to clarify, my sound problems are not the kind of echo/stutter that some ICH9 users have experienced as described e.g. in https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/274424. Mine are plain old irregular dropouts, as if a buffer setting was too low. Would you find an example recording useful for anything?

Speaking of buffer values, I tried finding out if there is any alsa buffer value that I could test around with, but without success. Is there such a thing?
Looking at the hda-intel diver side of things, I skipped through the codec documentation you hinted me to, David. At the current state though I don't know how to relate most of the stuff there to my problem. Of course the model detection might be wrong (even though all the alsa mixer mapping stuff seems to be correct). I could boot into my Ubuntu Studio 9.04 installation where the hda card does work flawlessly with alsa and compare lshw/dmesg outputs...?

On the hda-intel note, I read the alsa hda-intel troubleshooting notes, but none of the stuff really gave me an idea. I installed and ran the hda-analyzer python GUI tool to check the codec's internals, but I would need some pointers what to look for/try out in there.

Thanks a lot for your efforts, Alex

As a correction of my above comment: The attached loggings "some vlc and top example outputs" and "some vlc and top example outputs" are produced playing back on pulseaudio, for the reason that I do not know how to obtain proper verbose logs for the alsa backend. And I wanted to include here some logging that was collected during the time some drop-outs happened.

Please tell me if there is a way to obtain debug logging from alsa that would be more expressive in this situation.

Thanks, Alex

Argh, I meant "some vlc and top example outputs" and "verbose output of pulse" of course.

:) Alex

Ok, did a quick check of the situation in UbuntuStudio 9.04. Thinking about it, the environment there is quite a bit different, especially the 64bit rt-kernel. So I guess it would make more sense to boot into a Jaunty Live-CD and do some comparison there.
But for the time being here my findings about the soundcard in there: The dmesg is NOT showing the funky warning about hda-intel going to polling mode. For those messages, and the output of "lshw -C multimedia" refer to the attachment.

Regards, Alex

Right, -rt and -generic are very different kernels. I can't test -rt
on this hardware because of stability issues, so I have to concentrate
on the latter.

@Daniel: Of course. Next free minute I have I will boot into a Jaunty Live-CD and make apport send the information pack to this bug as well. Then we can compare what has changed since then regarding the sound card. Since it worked out-of-the-box in Jaunty, this might lead us to the culprit change.

Regards, Alex

Architecture: i386
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog]
   Subdevices: 2/2
   Subdevice #0: subdevice #0
   Subdevice #1: subdevice #1
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: ubuntu 5371 F.... mixer_applet2
 /dev/snd/pcmC0D0p: ubuntu 6323 F...m totem
 /dev/snd/timer: ubuntu 6323 F.... totem
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xfe220000 irq 17'
   Mixer name : 'Analog Devices AD1984'
   Components : 'HDA:11d41984,17aa20bb,00100400'
   Controls : 29
   Simple ctrls : 18
CurrentDmesg: [ 113.136069] eth0: no IPv6 routers present
DistroRelease: Ubuntu 9.04
MediaBuild: Ubuntu 9.04 "Jaunty Jackalope" - Release i386 (20090420.1)
Package: alsa-driver
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
Uname: Linux 2.6.28-11-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Uff, wow, that was harder than necessary, trying to add an apport report to this bug. apport-collect didn't do more than the above comment and then aborted. And I first had to find out that I have to update apport from ubuntu-updates to fix a bug with the apport-cli offline mode in Jaunty.
But here finally the report from running the Ubuntu 9.04 32bit desktop live-cd. The sound works out of the box without glitches. So perhaps we can find some pointers from the difference of how the card is recognized / set up in Jaunty as compared to Karmic.

In hope things can advance a bit now...
Regards, Alex

Hm, somehow I got rid of the problem.
After playing around with the power_save value in /etc/modprobe.d/alsa-base.conf. I changed it to 60 and the dropouts disappear. However when I temporarily switch back now to a value 10, it is very difficult to reproduce the dropouts. I did otherwise not change anything in the system. Can anybody confirm that? What about you, David Finch?

It seems a bit of a mystery. But I guess it's safe to say, even though my symptoms are somewhat different, that this is related to the power-management setup issues that people had e.g. here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/381201 .
It's also obvious that it's not related to the hardware detection of the codec, as there seems to be no difference between Jaunty and Karmic.

Would you want me to try to dig deeper and find out more about the problem?
Anyway, thanks for your help to self-help, guys. Especially thanks to David Henningsson for pointing me to the latencytop tool.
Regards, Alex

Same problem here with amd 64 - karmic 2.6.31-15:
[ 191.090021] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x10490000

removing pulseaudio gave no benefict
It seems related to the driver but till to two days ago was going good enough
Regards,
David

I have had exactly the same bug and following the advice in that thread fixed it perfectly for me, my audio works with no flaws whatsoever since I changed the power_save value to 0.

" Alexander Bethke wrote on 2009-11-15: #21
 Hm, somehow I got rid of the problem.
 After playing around with the power_save value in /etc/modprobe.d/alsa-base.conf. I changed it to 60 and the dropouts disappear. However when I temporarily switch back now to a value 10, it is very difficult to reproduce the dropouts. I did otherwise not change anything in the system. Can anybody confirm that? What about you, David Finch?

It seems a bit of a mystery. But I guess it's safe to say, even though my symptoms are somewhat different, that this is related to the power-management setup issues that people had e.g. here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/381201 ."

Ok, after an evening of perfect sound and no glitching, including a number of reboots which didn't change that, this morning I boot up and the sound problem has returned. Checked the alsa-base.conf file and it's the same as I left it when I changed it, and which immediately stopped the glitching, so not sure where it is occurring now.

Yes, it's funny. I actually have had problems with power_save=0, a value of 60 or higher has worked better for me. Even though I actually experience those pops that are described in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/381201 with those higher values. This is definitely related to be above.

The power alsa management for my hardware seems to be a mess currently really.

Regards, Alex

I have something I thought could be useful.

To avoid confusion, I've found a workaround and I'm only posting here in case it helps you guys who work on ubuntu. I'm trying to get into linux but just don't have the time.

Thus, excuse amateur posting, and let me know if I can provide more info.

I use Xubuntu 9.10 and needed to rip a cd. I apt-got soundjuicer, it also installed
gnome-media
pulseaudio-module-udev
pulseaudio
libgnome-media0
libpulse-mainloop-glib0
gnome-media-common
pulseaudio-module-x11
pulseaudio-utils
libpulse-browse0
pulseaudio-esound-compat
libspeexdsp1
sound-juicer

One of these must be the mixer that suddenly appeared in the systray. Anyway, one of these caused the stuttering and glitches. I removed soundjuicer and autoremoved the rest of the stuff and my sound is back to normal, and I'll just get KDE and lame next time I need to rip.

My computer is a hp pavilion ze5700, ze5702ea to be more accurate. You might want some logs and things off me, I' busy and can't promise I'll be able to help much or respond promptly, but I'll try.

Excuse me if it's a pointless or offtopic post, once again, I only posted out of good will, and not to ask for help or complain.

Hi Alexander,

Please, if you are still having issues, test with the latest development release of Ubuntu. ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p alsa-base 479375

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds .

Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

Please let us know your results.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

Hi Brad,

I tested the most current Lucid beta release on the machine. The problems do not persist there. Audio and system in general run smoothly already since the alpha phase.
So this is a bug in Karmic only, not in Jaunty nor in Lucid.

Do you still need me to test the upstream kernel?

Regards, Alex