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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu Oct 8 12:15:03 2009
This archive was generated by hypermail 2.1.8 : Thu Oct 08 2009 - 12:15:03 EEST