[Portaudio] Reported latency

Erik Ronström erik.ronstrom at doremir.com
Tue Dec 8 02:40:20 EST 2015

Hi Ross,

Thanks for your answers!

> Each host API has to implement their own timing mechanisms. You should definitely test against all of your targets.

Yeah, that makes sense.

> (In theory) the PaStreamInfo latencies are as close as PA is able to statically report (which varies in accuracy) based on allocated buffers and any additional info provided by the native API (often not much).
> inputBufferAdcTime and outputBufferDacTime are functions of the current buffer fill levels, and the time at which buffers were captured. It stands to reason that these calculations could be more accurate, but also suggests that in your case there might be an error in the calculation of the PaStreamInfo input latency with the particular host API that you are testing.

Ok, that seams reasonable. I guess I have to test it on other host APIs before drawing any conclusions. It just seems odd to me that since the inputBufferAdcTime and outputBufferDacTime values are provided by PA, it is obvious that some underlying information is available, and that same information would be the base of the latency values in PaStreamInfo, but yielding completely different values. This suggests a bug.

>> These are the values of one test (input/output, rounded to ms):
> Are these observations with different hardware?

No, both were recorded using Internal Microphone and Internal Speakers on my MacBook Pro. The only difference in the setup (between these two tests) was changing the suggested latency.

> To clarify: Is the "Diff ADC/DAC" derived from inputBufferAdcTime and outputBufferDacTime?

Yes, I simply set a global variable from the PaStreamCallback, subtracting inputBufferAdcTime from outputBufferDacTime, and poll that variable from another thread.

>> the input latency cannot possibly be 59 ms when the recorded ”echo” starts 44 ms into the file?!
> True. It's possible that there is a bug either in the buffer phase handling or in the calculation of the latency. This code is different for each host API.

Thanks, then at least I won’t be chasing ghosts in my own code until I have some test results from other platforms.

Suppose there is really a bug in the Core Audio backend in PA – how do I take it forward?

> In the case of PA/CoreAudio this is further complicated by the fact that there are two full-duplex code paths depending on whether the input and output are on the same CoreAudio device, or on two separate devices (the latter case also applies to drivers that expose their audio as two separate sub-devices). In the latter case, PA/CoreAudio introduces an extra ring-buffer to adapt the two half-duplex streams into a single stream. This code path is likely to be used if one of your inputs is the microphone.

Ok, I didn’t know that. That would increase overall latency, but the increase would be of a known size, so the *accuracy* of the latecy calculation shouldn’t need to be affected, right?

> To reduce the number of moving parts, are you able to test your code with a full-duplex device (e.g. a pro audio interface)?

Good idea, I have a MOTU interface that I can test with. I’ll post the results later today.

> That would make sense to me. inputBufferAdcTime and outputBufferDacTime are calculated from all available information including buffer fill levels, whereas the static PaStreamInfo latencies don't take this into account (and may also be mis-calculated in this case).

> In theory there are two options: (1) PaStreamInfo or (2) inputBufferAdcTime and outputBufferDacTime. For your case I'd use PaStreamInfo.

Yeah, that would be my preferred option, if I could trust the values being accurate (enough).

> Also, for your use-case would it be reasonable to require users to use a synchronised full-duplex device, or do you absolutely need time alignment from two arbitrary devices (like internal mic)?

Unfortunately, I cannot make that requirement, as this is not a ”pro” app in that sense. OTOH, I’m not making a DAW, so I don’t need precision to the frame: if audio recordings are off by a few milliseconds, it would still be acceptable. But 50 ms or more is way too much!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.columbia.edu/pipermail/portaudio/attachments/20151208/58cadefb/attachment-0001.html>

More information about the Portaudio mailing list