On Tue, Aug 26, 2014 at 9:18 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 26 Aug 2014, Daniel Mack wrote: > >> On 08/26/2014 05:08 PM, Alan Stern wrote: >> > The normal approach is to perform a simple runtime calculation (no >> > pre-allocated pattern). It's not complex. >> > >> > Let S be the number of samples per second at the nominal transfer rate >> > (for example, S = 44100). Let R be the number of packets per second >> > (1000 because you transfer one packet every millisecond). >> >> [...] >> >> Yes, I thought about that too. The pre-allocated approach is not much >> code either, and it also gives accurate values for all common audio >> sample rates, but maybe the runtime calculation nicer and easier to read >> in the end. I'll give that a try later. > > It has the advantage of working for all audio rates, not just the > common ones. And it doesn't require preallocation of quite so many > transfer buffers (although they are generally small enough not to > matter much). > I was indeed aware we could do the calculations in runtime, but I am not sure one formula can get us optimal result for all scenarios. I think we want to play with bInterval as well. For ex, on extreme end, for 5512Hz we may want to double packet size (from 22 bytes) in favor of halving ISO polls or even better. Similarly for 192000Hz, we don't want to reject only because wMaxPacketSize is 512... because we are likely running HS, so we could set bInterval to 0.5ms and do 384 bytes packet. I am still aware this all could be calculated and decided in runtime, but I don't think many readers will find that easier to understand than a static table. BTW, we can do without increasing allocated usb requests. Regards, Jassi -- 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
