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().
