sound choppy with dmix

Thanks for your bug. What distribution do you use? What audiosink do you use?
You can select it with gstreamer-properties

Using current Breezy. I think that's GStreamer0.8-10.1 or so.

I use ALSA, but I changed to OSS and it's the same.

Non-GStreamer applications -- such as madplay -- seem fine.

(In reply to comment #3)
> Non-GStreamer applications -- such as madplay -- seem fine.

Chiming in. I don't know if it is the same bu, but gstreamer-dependent
applications like gdmplay or Rhythmbox loop the sound. Applications directly
accessing ALSA like BMP or XMMS have no such problem. This happens under Hoary
and, to complicate matters, on an IBM T20 with docking station (TP Dock 1). The
sound is fine if the T20 is undocked. I am through bugs 5234, 8358 and 10510, to
no avail.

Next i will try to force ACPI and IRQPOLL together and see what's happening. If
you need any more data, please ask.

Do you have the issue using "gst-launch-0.8 gnomevfssrc
location=/path/to/my/musicfile.ogg ! spider ! volume ! audioscale ! audioconvert
! $(gconftool-2 -g /system/gstreamer/0.8/default /audiosink)"?

With the GStreamer pipeline you suggest (substituting alsasink for the output of
gconftool-2), playback seems pretty smooth. I had to try suspending and
resuming several times to get anything noticable. I might get one skip or a
couple of clicks in the first second or so, but it stabilizes fairly quickly
most of the time.

Rhythmbox seemed to stablize after a few seconds sometimes, but sometimes it
definitely continues choppy playback for the entire song.

After invoking then closing Rhythmbox, gst-launch-0.8 also exhibited similar
problems to Rhythmbox.

It seems it's a timing dependent problem present in both that does not surface
every time.

is your issue specific to some file or happen with all the files? do you use
dmix? can you try with "alsasink device=dmix"?

Yes, I'm using DMix. :-)

Will try without.

Created an attachment (id=3280)
system ALSA configuration with DMix

(From update of attachment 3280)
Fix MIME type.

What if you use alsasink device=plughw:0,0 or alsasink device=plug:dmix instead
of alsasink device=dmix?

Comparing plughw:
gst-launch-0.8 gnomevfssrc location=/pub/music/albums/Radiohead/OK\
Computer/Subterranean\ Homesick\ Alien.mp3 ! spider ! volume ! audioscale !
audioconvert ! alsasink device=plughw:0,0

to dmix:
gst-launch-0.8 gnomevfssrc location=/pub/music/albums/Radiohead/OK\
Computer/Subterranean\ Homesick\ Alien.mp3 ! spider ! volume ! audioscale !
audioconvert ! alsasink device=dmix

Shows the problem exists only with dmix.

There is also a click before audio output starts when using the dmix device that
does not occur with the direct hardware device. I'd never bothered about it,
but this experiment makes it obvious.

This issue is also a problem if the system becomes so busy it can't service the
audio events (or possibly read the input audio file).

The other thing I notice is that dmix plays catchup: sometimes when resuming the
process, a mixture of weird sound is first emitted before normal playback. This
weird sound at the start sounds like semi-random frames from the source file.
Maybe it's all the buffered audio at a much higher rate.

Thanks to Daniel's suggestion, I think we've been able to narrow this down to a
dmix bug.

Setting package to libasound2.

madplay (my example of an unaffected application) does not even seem to be
linked against GStreamer or ALSA.

It is linked against ESound, but I don't have that installed, so I guess it's
using the old style OSS output method.

It seems every application using ALSA with DMix is affected.

% ldd /usr/bin/madplay
        linux-gate.so.1 => (0xffffe000)
        libesd.so.0 => /usr/lib/libesd.so.0 (0xb7ee9000)
        libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0xb7ec8000)
        libmad.so.0 => /usr/lib/libmad.so.0 (0xb7eb1000)
        libid3tag.so.0 => /usr/lib/libid3tag.so.0 (0xb7ea1000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7e8d000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e6a000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d3c000)
        /lib/ld-linux.so.2 (0xb7f02000)

Filed a report upstream. The comments here have been very useful, but feel free
to resolve it as upstream if you think it's a generic DMix problem and we're
done here.

This bug has been marked as a duplicate of bug 17770.