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.
>
> 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}. Again we can calculate for even such optimizations but
only at the cost of readability.
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
