Audio has occasional skips/dropouts

Bug #476702 reported by Vanessa Dannenberg
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

I haven't been able to determine a pattern to this yet, but ever since loading two of my machines with Karmic, I've been having audio drop-outs.

I am *not* using Pulseaudio.

It affects all music players - Audacious, Exaile, even the command-line 'play' utility that comes with SoX - and probably other audio sources as well. The symptoms are simple: I get little "hiccups" in the sound now and again, either the audio is skipping forward by some small, random amount, like listening to a cassette player with someone tapping the "fast forward" button now and again, or by dropping out entirely, as in silence for a brief period.

In its worst case, audio dropped out for several *seconds*, during which time one of the two CPU cores was pegged at 100%.

I have examined my system logs, dmesg, and watched for errors on the command line. I have found nothing at all except for a single clue: On a *completely idle* machine, SoX kept warning me of buffer underruns while experiencing these audio hiccups:

abe@cardinal:~$ play [filename hidden]

 File Size: 1.56M Bit Rate: 102k
  Encoding: MPEG audio Info: 1962
  Channels: 2 @ 16-bit Track: 6
Samplerate: 44100Hz Album: [hidden]
Replaygain: off Artist: [hidden]
  Duration: 00:02:01.70 Title: [hidden]

In:0.15% 00:00:00.19 [00:02:01.52] Out:4.10k [ | ] Clip:0 play WARN alsa: under-run
In:0.15% 00:00:00.19 [00:02:01.52] Out:4.44k [ | ] Clip:0 play WARN alsa: under-run
In:3.82% 00:00:04.64 [00:01:57.06] Out:218k [ ==|== ] Clip:0 play WARN alsa: under-run
In:21.7% 00:00:26.38 [00:01:35.33] Out:1.26M [ -=|=- ] Clip:0 play WARN alsa: under-run
In:42.1% 00:00:51.27 [00:01:10.43] Out:2.45M [ | ] Clip:0 play WARN alsa: under-run

The machines in question both carry a Gigabyte K8U-939 mainboard with an Athlon 64x2 3800+ processor and 1GB RAM. One machine has a Creative SB Live! sound card, the other is using on-board audio. Both have reasonably fast SATA hard disks and onboard RTL-8139-based ethernet devices. Clearly, they have more than sufficient computing power for the tack at hand.

Both machines were running Jaunty before, without any problems. Both received a fresh install of the final/official release of Karmic - that is, I did not "upgrade" them directly from Jaunty.

ProblemType: Bug
Architecture: i386
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Live [Dell Sound Blaster Live!], device 0: emu10k1x [EMU10K1X Front]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'Live'/'Dell Sound Blaster Live! at 0xc000 irq 21'
   Mixer name : 'SigmaTel STAC9708,11'
   Components : 'AC97a:83847608'
   Controls : 44
   Simple ctrls : 26
Date: Fri Nov 6 10:45:19 2009
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=3454cf9f-970c-4a77-8100-686006e1475e
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
IwConfig:
 lo no wireless extensions.

 eth0 no wireless extensions.

 vboxnet0 no wireless extensions.
NonfreeKernelModules: nvidia
Package: linux-image (not installed)
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-14-generic root=UUID=bd79cec3-fb97-42f9-bf27-e6cae2943847 ro crashkernel=384M-2G:64M,2G-:128M splash
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
RelatedPackageVersions:
 linux-backports-modules-2.6.31-14-generic N/A
 linux-firmware 1.24
RfKill:

SourcePackage: linux-meta
Uname: Linux 2.6.31-14-generic i686
XsessionErrors:
 (polkit-gnome-authentication-agent-1:2539): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (xfce4-terminal:2584): Terminal-WARNING **: Unable to load terminal preferences.
 (xfce4-terminal:2584): Gdk-WARNING **: XID collision, trouble ahead
dmi.bios.date: 12/01/2005
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F3
dmi.board.name: M1689D
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF3:bd12/01/2005:svn:pn:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnM1689D:rvrx.x:cvn:ct3:cvr:

Revision history for this message
Vanessa Dannenberg (vanessadannenberg) wrote :
Revision history for this message
Andy Whitcroft (apw) wrote :

[This is an automated message. Apologies if it has reached you inappropriately.]

This bug was reported against the linux-meta package when it likely should have been reported against the linux package instead. We are automatically transitioning this to the linux kernel package so that the appropriate teams are notified and made aware of this issue.

If this bug really is a bug in the linux-meta package you can move it back to linux-meta and set the Status to Confirmed, or contact us on the #ubuntu-kernel channel on the FreeNode IRC server. Thanks.

affects: linux-meta (Ubuntu) → linux (Ubuntu)
Revision history for this message
Vanessa Dannenberg (vanessadannenberg) wrote :

Update: both machines are now running 2.6.31-15 as supplied by the Ubuntu repository. The problem persists.

Revision history for this message
smurf (luca-dgh) wrote :

I have the same problem.
I use sox to redirect the audio from mi tv tuner card, using SAA7134 drivers, both cpus are under strong charge and periodically the sound skips and I find some warning ALSA under-run or ALSA over-run as well.
I do use Pulseaudio.

Revision history for this message
Robert K. Wright (wright-cems) wrote :

Using Audacity to transcribe from audio tape to disc, the created files show short skips/dropouts. I can get a run of two or three in 30 seconds followed by several minutes without any. I'm running Intrepid (8.10) kernel 2.6.27-16-generic, 3.2 Gib ram, dual core intel E7400 @ 2.8 Ghz, about 300 GiB HD available.The input and output devices for Audacity are ALSA: HDA Intel: ALC888 Analog(hw:0.0) . The above posts convince me the problem is likely not with Audacity, so I report it here in hopes that it will get checked and resolved.

Revision history for this message
Randall Ross (randall) wrote :

This bug can be reproduced on my system as follows:

1. On Karmic, install sox by:
sudo apt-get install sox

2. Use the 'play' command in a terminal:
play /usr/share/sounds/KDE-Im-Message-In.ogg
(use any sound file. the one above should be present by default though.)

3. Observe output from above command:

/usr/share/sounds/KDE-Im-Message-In.ogg:

 File Size: 22.7k Bit Rate: 177k
  Encoding: Vorbis
  Channels: 2 @ 16-bit
Samplerate: 48000Hz
Replaygain: off
  Duration: 00:00:01.03

In:33.3% 00:00:00.34 [00:00:00.68] Out:12.3k [ -==|= ] Clip:0 play WARN alsa: under-run
In:33.3% 00:00:00.34 [00:00:00.68] Out:16.4k [ | ] Clip:0 play WARN alsa: under-run
In:100% 00:00:01.03 [00:00:00.00] Out:49.2k [ | ] Clip:0
Done.

This is repeatable, though the number of "play WARN alsa: under-run" error messages varies.

Revision history for this message
Randall Ross (randall) wrote :

re, my previous comment, including sound controller info.

$ lspci | grep Audio
00:04.0 Multimedia audio controller: ALi Corporation M5455 PCI AC-Link Controller Audio Device (rev 03)

Revision history for this message
Robert K. Wright (wright-cems) wrote :

Re my comment #5 on 2009-12-26: Rythmbox, Exaile, and Totem all are able to play perfectly the .wav file which I made using Audacity on vista. Audacity on intrepid can't play it without many dropouts. Looking at system monitors processes during playback with Audacity on intrepid I note that dropouts usually, not always coincide with changes in CPU percent for Audacity.

Revision history for this message
isme (moonsoup) wrote :

I can reproduce this bug when I play a sound through sox in my karmic i686 laptop.

Funny, though.. the first time it worked with no error, then it got progressively worse on each play.
play -n -c1 synth sin %-12 sin %-9 sin %-5 sin %-2 fade h 0.1 1 0.1

  Encoding: n/a
  Channels: 4 @ 32-bit
Samplerate: 48000Hz
Replaygain: off
  Duration: unknown

In:0.00% 00:00:01.02 [00:00:00.00] Out:48.0k [ =====|===== ] Hd:0.0 Clip:0
Done.
---------------------then....
moonsoup@isme:~$ play -n -c1 synth sin %-12 sin %-9 sin %-5 sin %-2 fade h 0.1 1 0.1

  Encoding: n/a
  Channels: 4 @ 32-bit
Samplerate: 48000Hz
Replaygain: off
  Duration: unknown

In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0 play WARN alsa: under-run
play WARN alsa: under-run
play WARN alsa: under-run
play WARN alsa: under-run
play WARN alsa: under-run
In:0.00% 00:00:01.02 [00:00:00.00] Out:48.0k [!=====|=====!] Clip:0
Done.

and it gets longer, with more under-runs each time I run it.
It sounds like attaching a comb to a mic and using it to scratch with. ick!

Revision history for this message
Shuren (michele-barbiero) wrote :

Using sox to get audio from my tv card, I also known this behaviour. Change sox buffer value, I always get warnings in terminal, but noise goes away, not hear anymore, or better than before!

Command that I use is: sox --single-thread --buffer 512 -s -r 32000 -c 2 -t alsa hw:4,0 -s -r 48000 -c 2 -t alsa &

Revision history for this message
Vanessa Dannenberg (vanessadannenberg) wrote :

I'm using Gentoo now, and this bug persists even with vanilla kernel 2.6.33.2 (the current stable version as of this post) It affects every kernel I've tried up to this version, under both Ubuntu and Gentoo, so obviously is isn't Ubuntu's fault.

It seems to have gotten somewhat better with the more recent kernels - the skips aren't nearly as severe or as likely to happen. There also seems to be a pattern emerging, in that CPU load clearly makes the problem worse. Continuous heavy CPU load (such as an ongoing build) generally causes repeated, large (maybe 0.1 to 0.2 second) skips every few seconds, while sudden spikes (such as rendering a page in Firefox) might just cause a single, brief hiccup. It's still an intermittent problem - whatever condition it is that makes the skips possible doesn't always seems to be in place, but I still haven't figured out what that is.

High network activity, or spikes in network activity may also make the problem worse, but I haven't been able to pin that down yet either. I mention this only because the affected machine gets most of its music data from an NFS share on another machine, and on many occasions, a CPU spike on that machine is accompanied by a natural spike in network load (download a web page, then render it, for example).

Revision history for this message
Vanessa Dannenberg (vanessadannenberg) wrote :

I hate when I have to reply to my own posts to make a correction... In my last sentence:

"...a CPU spike on that machine is accompanied..."

should read:

"...a CPU spike on _the_affected_ machine is accompanied..."

Revision history for this message
Vanessa Dannenberg (vanessadannenberg) wrote :

Ok, finally got a new piece of info, if it will help, from Audacious this time:

alsa-gapless: snd_device_name_hint failed: Invalid argument.
vis in tabs
alsa-gapless: snd_pcm_pause failed: Input/output error.
ALSA lib pcm.c:7234:(snd_pcm_recover) underrun occured
ALSA lib pcm.c:7234:(snd_pcm_recover) underrun occured
alsa-gapless: snd_pcm_pause failed: Input/output error.
ALSA lib pcm.c:7234:(snd_pcm_recover) underrun occured
ALSA lib pcm.c:7234:(snd_pcm_recover) underrun occured

I don't know what the "gapless" message actually mean, but each time I hear a skip in the audio, I can see one of the "underrun" messages get added to the output on the controlling terminal at that moment. The total CPU load was about 65% at the time (average of two cores), with skips and these messages happening every 5 seconds or so.

Brad Figg (brad-figg)
tags: added: kj-triage
Revision history for this message
Reverend Entity (reverendentity) wrote :

I have been experiencing this problem ever since I upgraded to 10.04. My main music player is Rhythmbox, but I find that I have this issue with Banshee as well. After I play a few tracks, I will unexpectedly have a dropout of about 10-25 seconds, after which playback resumes farther along in the music and the player's timer has to speed up to reach the appropriate point.

Brad Figg (brad-figg)
tags: added: acpi-method-return
Brad Figg (brad-figg)
Changed in linux (Ubuntu):
status: New → Confirmed
tags: added: b73a1py79
Revision history for this message
Brad Figg (brad-figg) wrote : Unsupported series, setting status to "Won't Fix".

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.