alsa sink latency - how to account for startup delay

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux