ContextQMD
Back to Audacity

Portaudio Reported Playback Capture Latency

docs/portaudio-reported-playback-capture-latency.md

latest3.7 KB
Original Source

Imagine there were an audio cable plugged from your output back to your input. You press play, and at some stage, the project audio will reach back the input and become recorded. Latency compensation simply consists of discarding all incoming audio until the project audio arrives. Then users could play their project, record themselves on the fly and the incoming audio would be in sync without further manual adjustment required.

Audacity already has a latency-compensation setting for the user to adjust manually. Automatically adjusting this setting optimally would be trivial as soon as we knew the round-trip latency of the audio device.

PortAudio reports these latencies, but experiments showed that they weren't reliable. Here I make an experiment that I believe to provide exact estimates of round-trip latency.

Description of experiment

  • Connect the selected output device to the selected input device with an audio cable.
  • Before recording starts, create a wav file.
  • In the audio IO callback (on the audio driver thread)
    • overwrite the output buffer with one second of silence, then with a sine wave
    • write the samples of the input buffer to the wav file.
  • When recording stops, close the wav file.
  • Open the file in Audacity and observe the latency.

Results

OSHostrequested buffer size (ms) (*)PA-reported output buffer size (ms) (**)PA-reported input buffer size (ms)Measured round-trip (ms)error (reported - actual) (ms)
WinWASAPI25027026075455
WinWASAPI10012011075155
WinWASAPI20403075-5
WinDirectSound25025062.5420-107.5
WinDirectSound1001002511510
WinDirectSound20didn't workdidn't workdidn't workdidn't work
WinASIO50050.547.9100-1.6
WinASIO10050.547.9100-1.6
WinASIO2026.524.754-2.8

(*) applies to both input and output, e.g. 250 means 250 for the input + 250 for the output, in total 500. (**) for one same requested size, may differ wildly depending on whether only playback is active or playback and recording. Here we write the values obtained when both are active.