On Tue, 27 Aug 2013, Clemens Ladisch wrote: > Alan Stern wrote: > > On Tue, 27 Aug 2013, Clemens Ladisch wrote: > >> The current algorithm uses very short capture URBs to ensure that _some_ > >> URB is completed as soon as possible after a period ends. > >> [...] > >> I'd suggest to keep the old calculation for capture URBs. It would > >> make sense to use longer capture URBs only if the period size is > >> relatively large. > > > > Okay. What about playback endpoints with implicit sync? The current > > driver treats them the same as capture endpoints. Is that really the > > right thing to do? > > The only reason to not have an interrupt after each packet is to avoid > the interrupt overhead (for both CPU and power); shorter URBs would > result in a more precise DMA position reported to user space. If there > is already an interrupt for some capture URB (or for the feedback packet > in case of explicit feedback), we might as well handle the playback > packets so far. I don't quite understand. Are you saying that playback endpoints with implicit sync may as well use the same values for urb_packs and ep->nurbs as other playback endpoints, rather than using the values calculated for capture endpoints (which is what the current driver does)? 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
