On Tue, Aug 26, 2014 at 11:07 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> 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.
>
OK.
>> > 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.
>
Hmm... yeah, frame-unaligned packets may mess up audio in case of
packet drops. Thanks.
>> 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.
>
:) that is applicable against argument for readability for any subsystem.
Anyways, Daniel is doing the patch, I think he has the final call as
long we get best functionality.
Thanks
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
