Delay calculations for USB audio?

[David Henningsson <david.henningsson@canonical.com>]

Hi,

While researching some crackling audio problem, I noticed that I got 
these messages in my dmesg:

delay: estimated 0, actual 384
delay: estimated 384, actual 768

They come at every start of playback. I want to understand this stuff, 
so I tried to dig a little. It looks like the endpoint is started in the 
prepare stage, so between prepare and trigger, silence data will be sent.

First question: Isn't this messing up the delay calculations? If you 
fill some "urb buffer" [1] with silence, depending on the urb buffer 
size, delay calculation should take this into account for proper 
lipsync. I mean, the USB audio device would first have to play all the 
silence data before it could start the audio data, right?
(And how big is this buffer anyway?)

Second question: This also means that some of the silence packets will 
go through retire_playback_urb, right? Isn't this also messing with the 
delay calculation?

(Oh, and btw, if you have an idea of the crackling/distorted USB audio, 
let me know. I'm using a standard Logitech USB Headset, using
speaker-test -c 2 -D plughw:Headset -t sine -r 48000
I can make the problem go away using any of these options:
  * Booting a 3.2 kernel - I've tried 3.5, 3.6-rc7 and 3.2
  * Choosing the 44100 sample rate instead of the default of 48000
  * Selecting the outer USB port instead of the inner one. Yes, there 
are two USB ports next to each other, and this only happens on one of 
them. (!))

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

[1] maybe there's a better name for it?