>> >>>>> 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 do loopback module assume sink is not running when it start source capture? 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.