Daniel Griscom wrote:
We are using a bInterval value of 1 (on a high-speed device). We've recently tried bumping this up to 2, and the problem was no longer evident
This might indicate that the controller has problems reading the packet data from memory; there's a considerable overhead for each memory transaction, and the controller needs to update the DMA lists. (The pattern might be caused by some data, which arrives too late, interfering with the reading of the next packet.)
If 2 is the first save interval, consider using 4. For that matter, full-speed devices work fine with one packet per frame. There isn't a problem with buffering one millisecond of data in the device, is it?
(The only reason to use smaller intervals is if you really require sub- millisecond latencies, or if the bigger packets would eat up too much bandwidth in one of the microframes. The cost of smaller intervals is more overhead on the host, on the bus, and in the device.)
Regards, Clemens