Alan Stern wrote: > On Mon, 3 Sep 2012, Clemens Ladisch wrote: >> The audio driver wouldn't care. Logically, it starts a new stream. > > Really? Why not just skip a few packets and carry on with the existing > stream? > Logically, the situation isn't very different from what happens when > packets are lost in transit (except for the fact that outgoing packets > can be lost without the host's knowledge). A few lost packets do not affect the timing of completion interrupts/ callbacks. However, when the queuing is broken, the completions arrive in a way that makes the stream to appear to slow down, and then to speed up when the HCD is trying to resynchronize. Some jitter in the reported stream progress is acceptable (and USB audio already is infamous for that, due to the 1 ms frame granularity and the fact that URBs often span many frames). But when the timing errors become too big, synchronization with other real-time events gets lost. Where exactly the boundary between small errors to be ignored and big fatal errors lies is of course rather fuzzy. However, by selecting a particular queue length, drivers have control over this boundary. > Does the behavior vary (or need to vary) according to the stream's > direction? Oh well. There are no sample counters, so if any capture packet is dropped, we do not know how many samples are missing. (I've never heard of this happening in practice though.) > My reason for bringing this up is because I want to improve the way > ehci-hcd handles such things. Right now it doesn't do a very good job; > when faced with delays longer than the built-in "slop" setting > (currently 10 ms) it completely loses track of what's happening. It > thinks the late submissions are actually far too early (it's dealing > with a hardware schedule arranged as a ring buffer with length 512 or > 1024 ms) and never gets back on track. > > I've got a patch ready for testing that improves this behavior, but it > fixes only part of the problem. Resynchronization afterward remains an > issue. >From the audio driver's point of view, resynchronization by the HCD is not even necessary. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
