[alsa-devel] Delay calculations for USB audio?
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. (!))
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
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 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
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?
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
participants (4)
-
Clemens Ladisch -
David Henningsson -
Gabriel Beddingfield -
Gabriel M. Beddingfield