USB driver / protocol strategy

Hi all, after some discussion with Dieter and Christian, the following strategy has been selected for USB driver/protocol development: 0) Implement a composite USB Audio and CDC-ACM (serial) device to the OS, where USB audio is used for complex xamples in S16_LE format, and CDC-ACM is used for control of the device (tuning, etc.) 1) use USB audio with 1Ms/s, maybe even 2Ms/s for Linux. 2) offer the highest possible sample rate that windows supports as alternative sample rate in the descriptor (96 or 128 kHz) * implement a factor 10 decimation and low-pass inside the FPGA to avoid folding of the spectrum, as the E4000 has a minimum filter width of 1 MHz 3) implement a libusb-win32 (libusb-0.1) driver for windows for the higher baud rates. To make sure this driver can bind to the device (and not the standard windows usb audi driver), we can implement a control command sent over the serial port, which causes the device to re-enumerate and no longer identify itself as a 'usb audio class'. The next steps in the direction of the firmware will be: * creating the dual sample rate USB audio descriptors and verify they are accepted by Linux and Windows (with dieters help) * creating the descriptors for the composite device, validating them on Linux and Windows, as well as operation of the virtual serial port * experiments with the NuttX port for sam3u (might be nice, but I doubt we will need it, given the single-purpose nature of the device) Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)