On 29.03.2016 20:59, Raymond Yau wrote: > > > >> > >> The USB driver will submit N silence URBs on startup in the prepare > and you will have to wait for those URBs to retire before the samples > are queued. There is very little 'USB processing'. If you want to > reduce this delay you have to use smaller periods, it'll decrease the > size of the URBs. I guess it could be possible to change the URB size > after the start but that's not implemented atm. > >> > > For loopback, the source capture the same amount of data while you > wait for the retitement of those urbs > Yes, that is exactly the point. > > I don't want to shorten the latency. I only want the latency > reported correctly. To me it still > > looks like the real latency of the driver is not what it reports, > because the time that the > > audio spends in the URB's is not taken into account. What I am > seeing is, that the real > > latency is around 10ms longer than expected. > > The total number of URBs for the endpoint is not allowed to exceed > MAX_URBS (which the patch increases from 8 to 12). > > Do this match with your measurement > > How much audio does one URB hold? The time I measure is between 8 and 9 ms and does not depend much on the configured sink latency as far as I can tell. (I tried latencies between around 10ms and 2s). I did however not check the dependency in detail, most observations are with sink latencies in the range of 10 - 20ms.
