USB 2.0 Streaming MPEG - Best way to queue request?

We have a USB 2.0 device that outputs small multiples of MPEG2 TS
packets(188 bytes), and therefore need to queue
up multiple BULK requests to the USB bus driver(USBD) in order to keep the
MPEG2 video flowing without
dropping packets. Since in BULK mode our requests are not aligned on 512
byte boundaries, submitting a
large buffer to the USBD does not help, since in BULK mode a transaction of
less than 512 bytes ends the session.


So the question is: What is the best way to queue up multiple BULK
requests with small buffers in the driver?
Are System Work Items a way to go, queue up multiple initially, then requeue
in the callback?
The DDK docs indicate that the System thread pool is a shared resource and
should be used sparingly...

Any suggestions would be appreciated.

Thanks
-decoder

Tim
Thu May 01 23:55:27 CDT 2008

"decoder" <rcg_golf@verizon.net> wrote:
>
>We have a USB 2.0 device that outputs small multiples of MPEG2 TS
>packets(188 bytes), and therefore need to queue
>up multiple BULK requests to the USB bus driver(USBD) in order to keep the
>MPEG2 video flowing without
>dropping packets. Since in BULK mode our requests are not aligned on 512
>byte boundaries, submitting a
>large buffer to the USBD does not help, since in BULK mode a transaction of
>less than 512 bytes ends the session.
>
>So the question is: What is the best way to queue up multiple BULK
>requests with small buffers in the driver?

The solution is to change your device to send a continuous stream of
512-byte packets. Don't commit packets 188 bytes at a time. Otherwise,
you'll never be able to keep up.

Alternatively, you could switch to an isochronous pipe and set the max
packet size to 188.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

decoder
Fri May 02 12:25:20 CDT 2008

> The solution is to change your device to send a continuous stream of
> 512-byte packets. Don't commit packets 188 bytes at a time. Otherwise,
> you'll never be able to keep up.
>
> Alternatively, you could switch to an isochronous pipe and set the max
> packet size to 188.

Your points are well taken, and as a future modification we may be able to
modify the device...

But since the device modification is not trivial, and we need to use BULK
mode
in addition to ISO with the current device, the question is:

Besides using System Work Items in the driver, is there a better way or
recommended technique
that does not involve using the Work Items( queuing/re-queuing) etc.?


Thanks
-decoder


"

Tim
Sat May 03 22:35:02 CDT 2008

"decoder" <rcg_golf@verizon.net> wrote:
>
>Your points are well taken, and as a future modification we may be able to
>modify the device...
>
>But since the device modification is not trivial, and we need to use BULK
>mode
>in addition to ISO with the current device, the question is:
>
>Besides using System Work Items in the driver, is there a better way or
>recommended technique
>that does not involve using the Work Items( queuing/re-queuing) etc.?

You don't need work items. You can queue up two dozen URBs with 512 bytes
each, then resubmit them in the completion routine, but the throughput will
never be as good as the other options.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.