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

[Georg Chini]

On 03.04.2016 03:47, Raymond Yau wrote:
>
>
> >>
> >>>>> 5) The pulseaudio sink code takes the first 10ms of audio out of the
> >>>>> loopback buffer,
> >>>>> writes it to the alsa buffer and calls snd_pcm_start().
> >>>>
> >>>> If the sink takes something from the loopback buffer, this means that
> >>>> the first pop() call has been made. Assuming no time has passed since
> >>>> the previous step, the USB bus is still full, and so is the ring
> >>>> buffer. Expected delay: 20 ms.
> >>>
> >>> Reported delay is exactly the amount of audio that was written to
> >>> the buffer.
> >>
> >> That's the bug that I think should be fixed in alsa if possible (and if
> >> it's impossible, I don't see how it could be fixed in pulseaudio
> >> either).
> >
> > It can be fixed (or at least be worked around). If you take a time stamp
> > at the moment when snd_pcm_start() is called and another when
> > the first audio has definitely been played (delay < write_count), then
> > the difference between the time stamps corrected by the amount
> > of audio that has already been played, gives you exactly that
> > missing bit of latency.
> > That was what my original question was about - what should I do with
> > this extra latency? Currently I am just adding it as an offset to the
> > "normal" latency. This however means, that if you configure let's say
> > 10ms, you will get in fact around 22ms. (You would get 22ms anyway,
> > but the reports would show 10ms with the old code.)
> > For HDA the reported delay is even slightly negative, probably because
> > the card already starts during the preparation step. Negative delays
> > are truncated by my code, no real audio should have been played
> > before snd_pcm_start().
> >
>
> This is because pulseaudio use -1 as start threshold instead of buffer 
> size/boundary, write may start just after first write, some plugin 
> (e.g. multi plugin) return EBADFD when pulseaudio call snd_pcm_start 
> because pcm has already started
>
Does that mean, that the negative delay (usually 20 - 60 usec) for HDA 
should also be
taken into account and not truncated?

> do loopback module assume sink is not running when it start source 
> capture?
>
Sink and source are started independently. Source data is discarded 
until the sink-input has
called pop() the first time. The memblockq of module-loopback is filled 
with silence before
starting the sink, so if the source starts up late, silence from the 
memblockq will be played.

> you are using scope to measure the latency, how about the input and 
> output delay from HDA link and the hda codec pins
>
> Some hda codecs (e.g. idt codecs) which have high pass filter, low 
> pass filter, EQ have delays defined in hda audio specification
>
> Input Delay is a 4-bit value representing the number of samples 
> between when the sample is received as an analog signal at the pin and 
> when the digital representation is transmitted on the High Definition 
> Audio Link. This may be a “typical” value. If this is 0, the widgets 
> along the critical path should be queried, and each individual widget 
> must report its individual delay.
>
> Output Delay is a four bit value representing the number of samples 
> between when the sample is received from the Link and when it appears 
> as an analog signal at the pin.
>
> “typical” value. If this is 0, the widgets along the critical path 
> should be queried, and each individual widget must report its 
> individual delay.
>
>
How can I query those values? Input delay seems to be 0 for HDA, the 
source starts
capturing samples immediately after snd_pcm_start().