On Mon, 3 Sep 2012, Clemens Ladisch wrote:
> 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.
...
> From the audio driver's point of view, resynchronization by the HCD is
> not even necessary.
There are two possibilities to consider when an URB containing several
packets of data is submitted:
1. The slots for the first few packets have already expired, but
the remaining packets will be transferred okay.
2. The slots for all the packets in the URB have expired.
In case 1 there is data loss but the queuing remains intact. In case 2
the queuing is broken.
It sounds like you're saying that case 1 submissions should succeed
(and return -EXDEV status for the statuses of the missed packets),
whereas case 2 submissions should fail outright (say with an -EXDEV
error, which is currently not used for URB submission). Then
resynchronization becomes the audio driver's problem entirely.
Would that be okay?
Alan Stern
--
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
