On Thu, 2009-10-08 at 09:26 +0200, Clemens Ladisch wrote: > This is handled by the USB protocol: the host controller retries sending > a data packet until the device acknowledges it. In other words, the > driver can blast away at the device with lots of packets, but the actual > rate is never higher than the device can handle, so the driver doesn't > need to specifically know about your device. >
Has this changed in the ALSA implementation? Because I remember that in order to double the transfer rate to the BCR2000 I had to edit some driver file (which one? I do not recall right now ...) Also, wouldn't it be so that the USB interface in the device may acknowledge that the package has arrived, but the device itself might not have the compute power to deal with it and gives up because of internal buffer overflows and errors? IIRC I was at first "blasting away" at 16x using a sysex reflash of the prom as a speed test - which fortunately did not brick the device, but neither did it show the rotating "transfer in progress" pattern that it does otherwise[*]. Switching leds on/off at that speed did not work as expected either. By settling for 2x instead I could then consistently display two red dots on each of ten (rather than five) rotary controllers - one bright, one dimmed - for, say showing course frequency as well as detune. For several reasons though, I have since then abandoned that line of thought ... [*] At the start of the transfer it would show progress, but then after a few seconds or so the display would just go blank ... > > Best regards, > Clemens _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
