On Thu, 4 Jul 2013, Ming Lei wrote: > >> If so, your coming change may break ABI because as you described > >> that "the flag should be set in the first URB of a new stream", but > >> some user-space drivers may not set it before. Even USB audio driver > >> doesn't set it in current -next tree. > > > > Really? I thought Clemens's changes were already merged. In any case, > > Looks the change isn't found in linux-next-20130701. You are right. I was thinking of commit c75c5ab575af (ALSA: USB: adjust for changed 3.8 USB API). It turns off URB_ISO_ASAP completely, but now we will need it to be turned on for the first URB in a stream. > > User programs probably don't matter much. In general, the practice is > > to leave the interface on altsetting 0 when nothing is running and then > > change to a different altsetting when starting an isochronous stream. > > Changing the altsetting is another way to tell the HCD that a stream is > > starting fresh. > > Yes, it might work, but many details need to be payed attention to, such > as, changing altsetting may not be done during suspend/resume. Hmmm. I don't know how snd-usb-audio handles a suspend/resume in the middle of playback or recording. HCDs may need to be smart enough to realize that all isochronous streams must be restarted following a root-hub suspend. > According to the discussion, URB_ISO_ASAP should be set on the first URB > of one audio stream, and keep unset on all other URBs, which looks a new usage, > IMO. It's the same as the current usage. I didn't realize that the audio driver wasn't setting URB_ISO_ASAP on the first URB of a stream -- it's not necessary with the current API. But it will be needed with the new API; that will have to be fixed. Here's a short explanation, in case the reasoning isn't clear to everyone. Suppose an isochronous stream is started, then stopped, and then restarted. If URB_ISO_ASAP isn't set in the URB that restarts the stream, then the HCD will think the stream was running all along -- the gap will look like a _very_ large underrun. Consequently, the restart will get messed up. With the old code, the HCD could tell the difference between an underrun and a genuine gap. With an underrun, the pipeline would never empty out, because each URB would be resubmitted _before_ its completion was finished. With tasklets that is no longer true; a sufficiently bad underrun could cause the pipeline to become completely empty. 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
