Sorry for the delay.

Daniel Griscom wrote:

I'd like to conclude this thread if I could. It seems clear that configuring our USB audio card's descriptor with a bInterval value of 1 (a packet every microframe) was too aggressive, and was part of what caused the packet stuttering issue. (Right?)

Yes.

We almost certainly should increase bInterval; I'll try 2, and if that seems stable will probably go to 3 (4 microframes) for some margin. However, I'm still concerned that the symptoms don't sound like a simple starvation issue, where I'd expect to have a missing frame every once in a while. Instead, we were seeing reliable operation interspersed with periods where lots of packets were being consistently omitted. To me, this suggests that there's some other issue going on, either in the USB stack or in the USB hardware itself.

The starvation seems to be in either the memory controller or in the coherence traffic between the MC and the CPU cache. I'd guess that something else does enough I/O to affect this.

As I've already said, the pattern could be explained by some memory read packet arriving too late at the USB controller, thus not only making it impossible to send the current packet, but also delaying the memory accesses of the next packet.

Given that, I'm worried that increasing bInterval will just move the symptoms around, making it harder to duplicate but not truly becoming robust.

You could try to trigger the problem by doing many memory access (more than fit into the cache), or by doing I/O through other PCI devices.

But if increasing bInterval works, you can be sure that some effect of the increased USB transaction management is responsible for the problem.

Regards, Clemens