Jens M Andreasen wrote: > 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 ...) In the latest driver version (ALSA 1.0.21 or kernel 2.6.32), the driver now can submit multiple packets at the same time. > 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? The device's firmware controls when to ACK a packet, so this should not happen. However, it is possible that USB support was later bolted on to a device (or that the firmware writer is incompetent), and that the USB chip communicates with the rest of the device over a line that has a higher bandwidth than the main CPU can handle, and that nobody implemented busy feedback. In that case, it woule be possible to lose data after it has been correctly received over USB. Best regards, Clemens _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
