>> >> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
