Alan Stern wrote: > 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)? Sorry, what I said applies more to explicit sync endpoints. When using implicit sync, a playback URB is submitted for each completed capture URB, with the number of samples per packet identical to the corresponding capture packet, so the parameters must be identical. 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
