Alan Stern wrote: > On Thu, 1 Aug 2013, Clemens Ladisch wrote: >>> It seems likely that the error is caused by an SMI taking too much >>> time. At least, we seem to have ruled out everything else. Besides, >>> this change has to be made eventually in any case -- underruns can >>> occur at any time, in principle, and they shouldn't cause the audio >>> driver to fail. >> >> Well, the failure is a bug in snd-usb-audio: when usb_submit_urb fails, >> it should report the underrun so that the stream can be stopped and >> restarted cleanly. This would be done by the snd_pcm_stop() call in >> endpoint.c which is currently commented out because of locking problems. > > Should we have some sort of threshold for how long an underrun can be > before it causes a submission failure? > > Presumably an underrun of a few ms should not cause the stream to be > stopped and restarted. An underrun of 100 ms or more probably should. > Where do we put the cutoff? This is policy which should not be decided by the HCD; the driver can decide whether to stop the stream when it sees the error in the completion callback. If there was an underrun, packets will fail+complete faster until the queue has caught up to the actual schedule. When the length of the underrun is longer than ALSA's ring buffer, that fast draining of data will result in an underrun of the ring buffer. The policy for these underruns (stop or ignore) can be set by ALSA applications. So a longer cutoff allows drivers and applications to ignore longer underruns, if they choose to do so, or to treat them as errors anyway. So there is no reason for HCDs to make the cutoff smaller than required for technical reasons. 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
