On Sat, 27 Aug 2005, Istvan De wrote: > Hello, > > I'm developing a USB2.0/Full Speed (12MBit) audio device for Linux which > needs high speed (>256Kbyes/sec)/low delay bidirectional data transfer.
Don't refer to that as "high speed". In USB, "high speed" means 480 Mb/s. The data rate you want is easily achievable using a "full speed" connection, as supported by your device. It seems very strange to hear someone say their full speed device needs to support high speed transfers. > To > ease development I'd prefer to skip driver development by implementing > some > device class, which already has a driver. > > Currently I've made a preliminary firmware for implementing the CDC-ACM > interface, however as Pavel kindly pointed out for me, currently only > 64Kbyte/sec is achieveable with this driver. I've read the archives and > from the discussions, I suspect that this is connected to the NO_FSBR > flag.. Why use the CDC-ACM class? It's not a Communications Class device. > Questions which popped out of my mind: > 1. Is there some standard way to allow for >64Kbytes/sec using the > 2.6.x > CDC-ACM driver? (I mean without modification of the sources, but setting > some > #defines or such) I'd not mind a reasonably slower PCI bus.. I don't know. I've never heard about a 64 KB/s limitation for CDC-ACM. > 2. The audio device I'm developing will not output/request raw audio > data > (what is directly playable on speakers), so until now, I've not > considered > implementing the Audio class interface instead of CDC-ACM, but what do > you > think? Isochronous transfers would be okay for me (no problem in case of > frame > drops), but is it much harder to implement that compared to CDC? I've > got only > 3 endpoints.. Iso isn't (or at least, should not be) any harder to implement than bulk. The main difference lies in latency and reliability: iso is low latency and low reliability whereas bulk is not. Which do you really need? If your device doesn't match the assumptions underlying the Audio device class, then you shouldn't try to force it into that category. > 3. In case no standard class driver works out, which kernel driver do > you > recommend for study? I'd need a high speed/low delay IN and OUT channel > and > some way to give commands/retrieve status info from the device.. Study the usb-skeleton driver. Depending on whether or not you want the commands/statuses to be out-of-band from the data, you might prefer to send them over endpoint 0. > Would the NO_FSBR flag also pose a limitation in this case, or it only > affects > the CDC driver? NO_FSBR is not connected in any way with particular device classes. In general, drivers should not use it (and host controller drivers are always free to ignore it). About the only time you would want to set NO_FSBR is if you expect the device to take a long time (1 second or more) to respond to a control or bulk transfer. Alan Stern ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
