[Portaudio] Reported latency

Phil Burk philburk at mobileer.com
Tue Dec 8 11:20:13 EST 2015


Note that the PortAudio loopback test can be used to measure round-trip
latency. It works best with wired (USB) audio interfaces.

https://subversion.assembla.com/svn/portaudio/portaudio/trunk/qa/loopback/

Phil Burk


On Mon, Dec 7, 2015 at 11:40 PM, Erik Ronström <erik.ronstrom at doremir.com>
wrote:

> 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!
>
> Thanks
> Erik
>
>
>
> _______________________________________________
> Portaudio mailing list
> Portaudio at lists.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/portaudio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.columbia.edu/pipermail/portaudio/attachments/20151208/0e653a06/attachment.html>


More information about the Portaudio mailing list