On Tue, 26 Aug 2014, Jassi Brar wrote:
> On Tue, Aug 26, 2014 at 10:00 PM, Jassi Brar <jassisinghbrar@xxxxxxxxx> wrote:
> > 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.
That's a separate matter. Selecting the sample rate and the polling
interval... You can put those things in a static table or decide them
at runtime. Either way, once you have settled on those parameters, the
computation I outlined earlier shows how to pack the samples into
packets.
> > 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.
> >
> Another example, for 44100Hz, calculations suggest synchronizing over
> 10ms as {9x176 + 1x180}, however we can keep better sync over 5ms as
> {4x176+1x178}.
No, that's not good because it ends up splitting samples between
packets. You'd put 44 samples in the first four packets, then 44+(1/2)
in the fifth, then (1/2)+43+(1/2) in the next four, and (1/2)+44 in the
tenth (as opposed to 44 in nine packets and 45 in the tenth).
Maybe UAC2 allows such things (I haven't read the spec), but in general
it seems like a bad idea. And IIRC, the USB-2 spec disallows it.
> Again we can calculate for even such optimizations but
> only at the cost of readability.
Anybody accustomed to audio programming will immediately recognize the
pattern of the computation I outlined.
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
