How to measure Round-Trip Latency (RTL) in Duplex Mode

[LSXAxeller]

I am working on a VoIP project that requires real-time audio processing and extremely low latency. I am currently using miniaudio in duplex mode to capture audio from a microphone and play it back through speakers.

While the basic audio routing is working as expected (similar to the duplex example), I am perceiving a delay in the playback of the captured audio, which is a concern for VoIP applications. To quantify and minimize this latency, I need to accurately measure the round-trip latency (RTL) from the input device (microphone) to processing to the output device (speaker).

I have attempted to measure RTL using the RTL Utility. However, I am encountering inconsistent and unreliable results. Often the utility reports "audio glitch" and fails to provide a measurement. When it does provide a result, it seems inconsistent across multiple runs, making it difficult to rely on.

I also briefly experimented with injecting timestamps or measuring time within the data_callback function in my miniaudio code, but this approach didn't seem to provide a meaningful measurement of the end-to-end RTL.

My Questions are:

1. What is the recommended and most reliable method for accurately measuring the true round-trip latency (RTL) in a miniaudio duplex setup? Are there specific techniques or tools you would suggest for use with miniaudio?

2. Are there specific miniaudio settings or configurations that are known to significantly impact duplex latency? I am currently using ma_performance_profile_low_latency, ma_share_mode_exclusive and deviceConfig.wasapi.noAutoConvertSRC = true; (on Windows), but are there other options I should explore to minimize latency?

3. Beyond measurement, do you have any general best practices or recommendations for minimizing latency in a real-time duplex audio application using miniaudio, especially for VoIP scenarios?

My Environment:

• Operating System: Windows 11 Pro - Build 22631.5039
• miniaudio Version: 0.11.22
• Compiler: CMake - MinGW - GCC
• Audio Devices (Example):
  • Playback Devices:
    0: Speakers (Realtek(R) Audio)
    1: CABLE In 16ch (VB-Audio Virtual Cable)
    2: CABLE Input (VB-Audio Virtual Cable)
    3: Virtual Speakers (Virtual Speakers for AudioRelay)
    4: FxSound Speakers (FxSound Audio Enhancer) (Default)
    5: VG242Y P (NVIDIA High Definition Audio)
  • Capture Devices:
    0: CABLE Output (VB-Audio Virtual Cable)
    1: Virtual Mic (Virtual Mic for AudioRelay) (Default)

Thank you for your time and assistance. I appreciate any guidance you can provide on accurately measuring and minimizing latency in my project.

[mackron]

Sorry for taking so long to get this. Was just focusing my attention on another project.

What is the recommended and most reliable method for accurately measuring the true round-trip latency (RTL) in a miniaudio duplex setup?

Unfortunately I'm not going to have a satisfying answer for you. Off the top of my head I think the best bet would be to look at the playback.internalPeriodSizeInFrames and capture.internalPeriodSizeInFrames members of your ma_device object. I can't think of anything better than that.

Are there specific miniaudio settings or configurations that are known to significantly impact duplex latency?

Your best option is periodSizeInFrames/Milliseconds in your device config. However, keep in mind that this is technically just a hint. miniaudio will tell the backend what you want, but what you actually get is up to the backend. By default miniaudio will use an intermediary buffer to ensure the data callback is always fired with the period size you specified with the aforementioned properties. You can disable this with noFixedSizedCallback, but then you won't guaranteed that the data callback will be fired with a consistent frame count.

Beyond measurement, do you have any general best practices or recommendations for minimizing latency in a real-time duplex audio application using miniaudio, especially for VoIP scenarios?

Not really, no. Duplex support in miniaudio is actually quite basic - it just takes takes data from the input device and pumps it through to the playback device with the necessary data conversion. If I remember correctly, I don't think I ever got around to do any dynamic re-synchronization to account for drift between capture and playback, which is something I need to get on top of.