Here are the promised samples.
Asus EEEPC 701 Linux 220.127.116.11-smp, running at 115.2 Mhz, to demonstrate that CPU power isn't a factor in getting good audio.
Raspberry Pi "B", 2012-07-15-wheezy-raspbian, generic 4GB Kingston SD card >16MB/s read speed.
Bus 001 Device 008: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter (From Koss, but it's a bog-standard chip). No USB hub was used, the same dongle was connected directly to both machines.
Here's a sample from the EEEPC: http://soundcloud.com/odokemono/mscg_from_eeepc701_115
And the same from the RPI: http://soundcloud.com/odokemono/mscg_fr ... i_700mhz_k
In both there's a bit of analog hum because the cable I used to record is a bit flimsy and long, but the stuttering is clearly evident from the RPI.
In both cases, ALSA's aplay was used to play a .wav file that was sampled directly from a CD. No form of compression was used.
Here are three oscilloscope images of the stuttering from the RPI: http://imgur.com/a/rVR99
The first two are from the soundcloud track, the third is from SOX's play: play -n -c2 synth 100 sine 1000 vol 0.25
It's clear from those flat sections that there's something wrong that makes the USB Audio dongle starve and lag when used on the Pi. I've tried with another dongle from a different manufacturer and got the same results; it uses the same C-Media Electronics chip, but I don't think the problem lies in the USB Audio driver nor the dongle. I've used it on many many different configurations of Linux machines and kernel versions. The only time I got this problem is with the Pi and, interestingly, a BeagleBone (also an ARM board).
Since the 1Khz sample also produced stuttering, any interference from the SD card access can be eliminated as a culprit, since while SOX's play produces the sound, there's no disk I/O going on.
So a bunch of variables are eliminated. Test your audio gear with these commands:
apt-get install sox
play -n -c2 synth 100 sine 1000 vol 0.25
Where XXXXX is the correct playback device listed from aplay -L.