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