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? 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
