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().
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
