On Wed, Feb 13, 2002, Matthew Fredrickson <[EMAIL PROTECTED]> wrote: > 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)
Yes, you *must* double buffer if you want Isochronous to be seamless. Isochronous transfers occur at the beginning of the frame and if you're scheduling for the next frame at the end of the previous, you'be already lost. > 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 :-) ). Have you tried more than 2 frames in your double buffer. I wouldn't trust a 2 frame double buffer. > 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. Define "sucks badly". > 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. Probably a timing issue. Please try buffering more than 1 frame. > 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 :-) JE _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
