usbaudio - Stream start causes multiple urbs to be sent rapidly to isosynchronous and sync endpoints

Phil Quinton <dampstudios@xxxxxxxxxxxxxx> · Sat, 12 Sep 2015 10:06:05 +0100

Hi,

I'm currently building a DIY High speed usb audio device and have come across some stange behaviour. When an audio stream starts (play), 12 urbs get sent (very close together) to the main isosynchronous end point, 4 urbs get sent to the sync endpoint. This is causing a buffer overrun on my DIY usb audio device. Using wireshark I've captured the traffic against my DIY device and also against an E-MU 0404 USB ( which handles the condition fine ) and the linux side behaves the same regardless of which device is used.

I enabled debugging on the usb audio module ( Kernel 3.16.7 ) and get the following output (E-MU 0404):

---cut---
[  227.363434] [2474] usb 9-1.1.4: Setting params for ep #1 (type 0, 12 urbs), ret=0
[  227.363440] [2474] usb 9-1.1.4: Setting params for ep #81 (type 1, 4 urbs), ret=0
---cut---

As you can see 12 urbs are allocated for endpoint 1, and 4 urbs for the sync (81). The wireshark output looks like this, after which it calms down and sends urbs at the correct interval.

No.     Time           Source                Destination           Protocol Length Info
     13 15.783563000   host                  6.0                   USB      64     SET INTERFACE Request
     14 15.783971000   6.0                   host                  USB      64     SET INTERFACE Response
     15 15.784085000   host                  6.0                   USB      65     URB_CONTROL out
     16 15.784603000   6.0                   host                  USB      64     URB_CONTROL out
     17 15.784707000   host                  6.1                   USB      344    URB_ISOCHRONOUS out
     18 15.784720000   host                  6.1                   USB      344    URB_ISOCHRONOUS out
     19 15.784725000   host                  6.1                   USB      344    URB_ISOCHRONOUS out
     20 15.784729000   host                  6.1                   USB      344    URB_ISOCHRONOUS out
     21 15.784735000   host                  6.1                   USB      344    URB_ISOCHRONOUS out
     22 15.784740000   host                  6.1                   USB      344    URB_ISOCHRONOUS out
     23 15.784744000   host                  6.1                   USB      344    URB_ISOCHRONOUS out
     24 15.784749000   host                  6.1                   USB      344    URB_ISOCHRONOUS out
     25 15.784754000   host                  6.1                   USB      344    URB_ISOCHRONOUS out
     26 15.784758000   host                  6.1                   USB      344    URB_ISOCHRONOUS out
     27 15.784763000   host                  6.1                   USB      350    URB_ISOCHRONOUS out
     28 15.784767000   host                  6.1                   USB      344    URB_ISOCHRONOUS out
     29 15.784775000   host                  6.1                   USB      80     URB_ISOCHRONOUS in
     30 15.784780000   host                  6.1                   USB      80     URB_ISOCHRONOUS in
     31 15.784785000   host                  6.1                   USB      80     URB_ISOCHRONOUS in
     32 15.784789000   host                  6.1                   USB      80     URB_ISOCHRONOUS in

The payload on these urbs are all zero's. It seems to match up with the buffers allocated (setting params debug output above). You'll also notice that they are *very* close together. At this point it's not honouring the correct interval, but is honouring the correct packet size. It's almost like a buffer flush of some sort.

So my question is:
1. Why does the driver do this?
2. Is there anything I can adjust in the USB descriptors to convince the driver NOT to do this with my DIY device. I've done a quick look through the driver code and I can't easily find where the logic is for where these 12 + 4 urbs are queued out.. As mentioned, it's only when a stream is initially started, such as right after a cold OS boot etc...

Thanks,
Phil.

------------------------------------------------------------------------------
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user