[pulseaudio-discuss] alsa sink latency - how to account for startup delay

[Georg Chini]

On 01.04.2016 03:19, Raymond Yau wrote:
>
>
> >>
> >>> > 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.
> >>
> > OK, I did a few more measurements and the numbers I have given above 
> are not correct.
> > The actual difference in overall latency is 12ms.
> > When I run module-loopback with 40ms configured latency, I will see 
> about 42ms with my
> > code that accounts for the delay and 54ms with the old code.
> > So if an URB holds 1ms of audio, this could match.
> >
> > I think the remaining 2ms are hardware delays, they are slightly 
> different for different
> > combinations of source/sink and by setting small latency offsets 
> (HDA source: 0ms
> > HDA sink: 2.8ms, USB source: 1.0ms and USB sink: 1.8ms) I am at 40ms 
> +/-0.5ms
> > for all combinations.
>
> Do module-loopback have higher latency than hda loopback mixing since 
> most hda codecs have analog mixer which support loopback mixing (e.g. 
> mic playback switch) ?
>
>
Analog loopback has less than 1 usec delay, so yes, there is definitely 
a difference.
I could however find no delay anywhere that fits with the latency 
offsets I mentioned
above.
I tested the time between the sink-input/source-output put() calls and 
also the time
between the put() and the uncork() calls as well as the time to the 
first push() and
pop() calls and no combination of those times matches the latency offsets.
This is why I believe the remaining delay differences must be somewhere 
in the
hardware. They are constant and do not depend on the configured loopback
latency.
BTW, all the time I was wondering, why I see some part of the input 
signal on the
output when using HDA->HDA, now I know ... I was not aware of that loopback
mixing switch and had it accidentally enabled, so thanks for the hint.