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. (!))