PROBLEM: USB isochronous urb leak on EHCI driver

[Michael Tessier]

>> 
>> My configuration:
>> -----------------
>> 
>> Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host controller) 
>> Linux
>> kernel: 2.6.31, using EHCI USB driver
>> Hub: 4-PORT USB 1.1 HUB (Texas Instruments PN: tusb2046b)
>> Devices: 4 USB 1.1 audio codecs (Texas Instruments PN: pcm2901)
>> 
>> Note: each codec is being used in R/W access, so with 4 codecs, I have
>> 4 playback and 4 capture streams.
>> 
>> My problem:
>> -----------
>> 
>> I have usb urb leaks when connecting more than 1 codec to the USB 1.1 Hub.
>> (the result is that some of the audio data is not transferred, part of 
>> the sound is simply missing) No problem when using only 1 of the 4 
>> codecs connected to the hub; When I connect a second codec, the sound 
>> quality starts to degrade. With
>> 3 codecs, we just cannot recognize a speach.
>> 
>> Tests and observations:
>> -----------------------
>> 
>> Since I have 3 usb ports available on the i.MX512, I tried to connect
>> 3 codecs directly on USB ports: the sound is perfect on each of the three ports.
>> 
>> I bought a consumer USB 2.0 Hub: no problem when using 3 codecs 
>> connected to that Hub, however, the audio will completly stop on all 
>> channels when connecting the 4th codec.
>> 
>> I checked the communication between the Hub (USB 1.1) and the Host 
>> controller (USB 2.0) with a scope and concluded that the communication 
>> speed is 1.5 MBytes/s has expected (so the communication is downgraded 
>> to USB 1.1, since codecs and hub are USB
>> 1.1 devices).
>> 
>> Also, I know that there is physically enough bandwidth to transfer the 
>> data for two reasons:
>> 1) I have an older CPU with a USB 1.1 host controller (using the OHCI 
>> driver), using the same hub and the same codecs: works like a champ, 
>> using less than 50% of the available bandwidth (observed with a
>> scope)
>> 2) 1 audio stream is 32khz-mono, 16 bits = 64 kB/s,
>> 4 codecs = 8 streams(R/W) x 64 kB/s = 512 kB/s (out of 1.5MB/s)
>> 
>> I noticed that my sound problem starts happening with only 2 codecs
>> (4 streams, 256 kB/s). I first thought that it was a bandwidth 
>> limitation, so I decided to connect only 1 codec using more bandwidth.
>> I configured it to 48khz-stereo (16-bits), using 384 kB/s for both 
>> read and write
>> streams: no problem. With that configuration, the scope shows about 
>> 30% of total bandwidth usage (300us used out of 1ms periods). Then, I 
>> added a second codec (48khz-stereo-16bits): very strange, now the 
>> total bandwidth usage felt down to about 200us, which seems to keep 
>> the same, whatever the number of codec I add (I also tried 3 and 
>> 4...). So it looks like the scheduler is not able to properly allocate 
>> Isochronous time slots when more than one device is connected to the
>> hub. However, without the hub, it works perfectly.
>> 
>
> I am wonder if it is similar problem I met when using multiple interrupt transfers, when you find you lose the data, try to run 'top' to show cpu utilization, if > it is close to 100%, it means the ehci can't queue request in time, so the host can't send IN token in time.
>
> Using a USB bus analyzer can also verify it.
>
> Peter

Thanks Peter, I did it, the CPU usage varies between 0% and 4% so this is not the case here.