Delay calculations for USB audio?

Delay calculations for USB audio?

[David Henningsson]

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?

Re: Delay calculations for USB audio?

[Gabriel M. Beddingfield]

On 09/28/2012 06:00 AM, David Henningsson wrote:
> (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. (!))

The last statement sounds like you're sharing a hub with another device 
that has reserved bandwidth.  For example, a USB webcam will often do 
this.  Audio will work for a while and then get pre-empted.

Use 'lsusb -t' to view your USB layout.

-gabriel

Re: Delay calculations for USB audio?

[David Henningsson]

On 09/28/2012 01:23 PM, Gabriel M. Beddingfield wrote:
> On 09/28/2012 06:00 AM, David Henningsson wrote:
>> (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. (!))
>
> The last statement sounds like you're sharing a hub with another device
> that has reserved bandwidth.  For example, a USB webcam will often do
> this.  Audio will work for a while and then get pre-empted.
>
> Use 'lsusb -t' to view your USB layout.

Thanks! Indeed, when deactivating bluetooth (in both kernel 3.2 and 3.5) 
the sound is back to normal, so this time I could actually get the 
distortion out of 3.2 as well.

Question is - is this an actual hardware limitation, or is it actually 
fixable if we wrote better drivers?


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

Re: Delay calculations for USB audio?

[Clemens Ladisch]

David Henningsson wrote:
> On 09/28/2012 01:23 PM, Gabriel M. Beddingfield wrote:
>> On 09/28/2012 06:00 AM, David Henningsson wrote:
>>>   * 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. (!))
>>
>> The last statement sounds like you're sharing a hub with another device
>> that has reserved bandwidth.  For example, a USB webcam will often do
>> this.  Audio will work for a while and then get pre-empted.

For A/V devices, USB bandwidth is reserved in advance; it is not possible
to have other device interfere (as long as the controller driver is
written correctly ...).

> Thanks! Indeed, when deactivating bluetooth (in both kernel 3.2 and 3.5)
> the sound is back to normal

I'd guess that that particular USB port and the bluetooth controller
share an interrupt.

> is it actually fixable if we wrote better drivers?

Apparently, yes.


Regards,
Clemens

Re: Delay calculations for USB audio?

[David Henningsson]

On 09/28/2012 02:30 PM, Clemens Ladisch wrote:
> David Henningsson wrote:
>> On 09/28/2012 01:23 PM, Gabriel M. Beddingfield wrote:
>>> On 09/28/2012 06:00 AM, David Henningsson wrote:
>>>>    * 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. (!))
>>>
>>> The last statement sounds like you're sharing a hub with another device
>>> that has reserved bandwidth.  For example, a USB webcam will often do
>>> this.  Audio will work for a while and then get pre-empted.
>
> For A/V devices, USB bandwidth is reserved in advance; it is not possible
> to have other device interfere (as long as the controller driver is
> written correctly ...).
>
>> Thanks! Indeed, when deactivating bluetooth (in both kernel 3.2 and 3.5)
>> the sound is back to normal
>
> I'd guess that that particular USB port and the bluetooth controller
> share an interrupt.

In this case, actually the bluetooth controller is on the same USB bus, 
so that's why they're sharing the interrupt. And when I click the rfkill 
button, it disappears from the bus, just as if it were an external 
bluetooth adapter that I unplugged.

>> is it actually fixable if we wrote better drivers?
> Apparently, yes.

Okay, so if I get some time to dig deeper into this, where should I 
start looking? Maybe in the bluetooth controller driver, if that's 
what's interfering?

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

Re: Delay calculations for USB audio?

[Gabriel Beddingfield]

On Fri, Sep 28, 2012 at 12:29 PM, David Henningsson
<david.henningsson@canonical.com> wrote:
> Okay, so if I get some time to dig deeper into this, where should I start
> looking? Maybe in the bluetooth controller driver, if that's what's
> interfering?

My guess is that either the bluetooth driver is reserving bandwidth
(and didn't before), or the USB host controller is /enforcing/ the
bandwidth (and didn't before).

-gabriel