On Wed, 13 Feb 2002 [EMAIL PROTECTED] wrote: > transfers for incoming data. I've already reported here performance > problems with BULK IN on UHCI chipsets. These performance problems do > not go away with the 2.4.18.pre9 build. Can anyone comment on the > maturity/robustness of the ISO handling code for UHCI (for either UHCI > driver)? I don't want to go down the path of implementing ISO if I'm > going to have to deal with lots of driver issues at this point?
I experience somewhat similar performance problems in ISOC mode on UHCI controllers. I wrote a driver for a telephony device that uses ISOC transfers to transfer audio data. It is supposed to tx/rx 1000 times a second a 16 byte (8 16bit slinear samples) quantity of data in each transfer (8 * 1000 = 8000hz, or 8000 16bit slinear samples of data). I developed it originally on a UHCI bus (my motherboard's built in controller). The way it was originally done was a single tx urb and a single rx urb. Each of these in turn would kick another urb off in the completion routine. However, when doing this, I would get awful throughput (probably half of my 1000 transfers a second) on these transfers, so I began to ponder. I noticed that the USB audio driver used a sort of "double buffering" of URBs, and so I tried to implement this. I bumped the number of tx urbs and rx urbs up to two each, and magically I got normal throughput. (all of this is background for what I'm about to say) Now, my only significant problem now is this: Using the UHCI controllers, I get pops and gaps in the audio data I'm transferring, like it's dropping urbs, or not getting the ISOC transfer requests sent out onto the bus 1000 times a second, kind of like it's skipping sending out a transfer on one of the host controller interrupts or something crazy like that. However: On OHCI controllers, I have none of these problems. Sound is clear as a crystal (in a manner of speaking :-) ). More data: IIRC, on the vanilla uhci.c driver, ISOC sucks. Sucks really badly. Kind of funny though, 'cause I was helping somebody with writing a driver for something that used BULK transfers, and the usb-uhci driver kept on Oops!'ing his system (dereferencing a NULL pointer in the host controller code) whenever he tried to initiate his transfer. Switching to the uhci.c driver corrected this. Go Figure. So both drivers are good/bad at different things, though the usb-uhci driver seems to perform/behave better for most cases I've seen. I have not as yet tested the new hcd stuff in 2.5, so that is still unknown for me (mostly because whenever I tried 2.5, something important that I needed to boot or operate somewhat normally seemed to be broken so I quickly rebooted back into 2.4.17). However, I suspect if I did quite a bit of looking through the usb-uhci code and did a little bit of tweaking, I could eliminate the gaps and pops from occuring with my device. Probably some timing issue in the driver somewhere. Anyway, hope this helps. By the time I get done with emails like this, I always seem to forget something important I intended to put in, so if this seems incomplete, or you have any questions, feel free to reply :-) Matthew Fredrickson _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
