What is wrong with FreeBSD and USB Support
mrechberger at gmail.com
Mon Mar 6 10:37:24 UTC 2017
On Mon, Mar 6, 2017 at 11:30 AM, Hans Petter Selasky <hps at selasky.org> wrote:
> On 03/06/17 09:53, Markus Rechberger wrote:
>> Just to clarify this issue it's hardware and software related.
>> In the linux libusb20 wrapper there's some code in it in the bulk
>> callback function
>> if (xfer == xfer0)
>> xfer = xfer1
>> xfer = xfer0
>> why should someone toggle the other transfer and not the same one that
>> is returning or required to set up?
> This is to be able to setup double-buffering of USB transfers.
>> I would like to set up multiple requests at the same time and not only
>> 2 of them (since 2 of them are not fast enough in our case).
> Do do this correctly for a BULK endpoint, allocate two USB transfers, and
> then subdivide these two using the FreeBSD USB frames feature.
> Divide 1x USB transfers into 32x frames which then equals 32 transfers in
> one completion event. Linux/MacOS/Windows doesn't have this feature and
> instead they allow setting up a bunch of wMaxPacketSize sized jobs which
> then in turn generate an enormous completion event traffic, which is not
> very intelligent.
Are you sure? As from some of my signal analyzer dumps I do think that
all those systems support
multiple transfers within one completion event. I always request
multiple frames within one request on those systems and they complete
at once. And they only complete once all the buffers are filled.
>> This is about resolving an active bug and misconception of the freebsd
>> userspace usb API usage.
>> Some hardware just need a lower latency.
More information about the freebsd-multimedia