Comment 9 for bug 574137

This bug is similar to that of bug #551949. The sound goes bad.... but... if one waits a few seconds, with no audio playing, it will then be fine for a while. If it goes bad (popping, distorted), it will not cure itself unless all sound apps are turned off for a while. For me, playing a system sound a few times will make it go bad. The author of bug #551949 said he cured it by adding model=3stack-dig to the options snd-hda-intel line in /etc/modprobe.d/alsa-base.conf. This does not cure the problem for me.

BUT... I get the following in /var/log/syslog when I play a sound (good or bad sound).

May 4 18:09:28 jim-nb kernel: [ 9629.058423] ALSA hda_intel.c:1665: azx_pcm_prepare: bufsize=0x3700, format=0x4011
May 4 18:09:28 jim-nb kernel: [ 9629.058453] ALSA hda_codec.c:1158: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011
May 4 18:09:28 jim-nb kernel: [ 9629.065698] ALSA hda_codec.c:1158: hda_codec_setup_stream: NID=0x3, stream=0x5, channel=0, format=0x4011
May 4 18:09:28 jim-nb kernel: [ 9629.073872] ALSA hda_intel.c:1665: azx_pcm_prepare: bufsize=0x3700, format=0x4011
May 4 18:09:28 jim-nb kernel: [ 9629.073902] ALSA hda_codec.c:1158: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011
May 4 18:09:28 jim-nb kernel: [ 9629.081712] ALSA hda_codec.c:1158: hda_codec_setup_stream: NID=0x3, stream=0x5, channel=0, format=0x4011
May 4 18:09:35 jim-nb kernel: [ 9635.626236] ALSA hda_codec.c:1176: hda_codec_cleanup_stream: NID=0x2
May 4 18:09:35 jim-nb kernel: [ 9635.626260] ALSA hda_codec.c:1176: hda_codec_cleanup_stream: NID=0x3
May 4 18:09:35 jim-nb kernel: [ 9635.626346] ALSA hda_codec.c:1176: hda_codec_cleanup_stream: NID=0x2
May 4 18:09:35 jim-nb kernel: [ 9635.626362] ALSA hda_codec.c:1176: hda_codec_cleanup_stream: NID=0x3

I do not get this on another machine running pulseaudio on Lucid.

The author of Bug #551949 also reported similar log messages.

On a fresh boot the user.log contains...

May 4 19:29:37 jim-nb pulseaudio[1147]: alsa-util.c: Disabling timer-based scheduling because high-resolution timers are not available from the kernel.
May 4 19:29:37 jim-nb pulseaudio[1147]: alsa-util.c: Disabling timer-based scheduling because high-resolution timers are not available from the kernel.
May 4 19:29:38 jim-nb pulseaudio[1173]: pid.c: Daemon already running.
May 4 19:29:38 jim-nb pulseaudio[1147]: alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write!
May 4 19:29:38 jim-nb pulseaudio[1147]: alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
May 4 19:29:38 jim-nb pulseaudio[1147]: alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.

Similar things were seen in the previous bug's log...

Does any of this help point to a possible area for investigation?