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