USB Audio Input recording 3.3x too slow, playback 3.3x too fast, and garbled

Question

I'm developing a USB audio device that acts like a microphone. It produces an isochronous (USB-talk for real-time) audio stream at 8000 Hz, 16-bit PCM. With Ubuntu 13.10 the recording takes place about 3.3x too slow. That is, recording for 10 seconds produces a 3-second WAV file, that plays back much too fast. (Best measurement of the ratio is 3.27.) The playback is worse than speeded up, it's garbled too. For example counting "one.....two.....three" sounds like "bzt..bzt..bzzt". I tried 3 different audio programs (arecord, ocenaudio, Audacity) and two different computers. Confoundedly, telling arecord to limit the recording to 10 seconds (--duration=10) actually takes about 33 seconds, and results in a 10-second WAV file. It's as if the driver is in a time warp.

Recording from the mic in a USB Logitech headset produces a good file, with the correct speed and understandable audio. I know this sounds like a bad audio input USB device on my part, but recording from it works fine in Windows (via GoldWave). My gut says there is a bug in the Ubuntu audio driver when the isochronous data is coming in at only 8000 Hz, which is unique. Most microphones offer through the USB enumeration to sample for you at a variety of rates, e.g. 44100, 22050, 8000, etc. For extraneous reasons I'm confined to 8000 Hz.

Anyone else see anything like a buggy audio USB driver? Any ideas how to gain evidence incriminating or exonerating Ubuntu drivers?

Answer 1

Turns out Linux needs uniform packets in USB audio input. It matters how many sound samples are in each packet.

In my application at 8000 Hz sampling, with the standard 1ms polling intervals of USB "full speed", that averages 8 samples per packet. Due to a quirk I was sending my samples bunched up, 32 audio samples in one packet, then 0, 0, 0, 32, 0, 0, 0, 32, .... Nothing wrong with that bandwidth-wise, there's plenty of room. Windows processes fine, but Linux chokes.

When I sent the samples evenly: 8, 8, 8, 8, ... the audio got through fine. I am guessing something at a low level in the USB audio drivers in Linux is making wrong assumptions. But my workaround is clear.