Search code examples
iphoneiosaudiocore-audiomicrophone

iOS: Bad Mic input latency measurement result

I'm running a test to measure the basic latency of my iPhone app, and the result was disappointing: 50ms for a play-through test app. The app just picks up mic input and plays it out using the same render callback, no other audio units or processing involved. Therefore, the results seemed too bad for such a basic scenario. I need some pointers to see if the result makes sense or I had design flaws in my test.

The basic idea of the test was to have three roles:

  1. My finger snap as the reference sound source.
  2. A simple iOS play-thru app (using built-in mic) as the first listener to #1.
  3. A Mac (with a USB mic and Audacity) as the second listener to #1 and the only listener to the iOS output (through a speaker connected via iOS headphone jack).

Then, with Audacity in recording mode, the Mac would pick up both the sound from my fingers and its "clone" from the iOS speaker in close range. Finally I simply visually observe the waveform in Audacity's recorded track and measure the time interval between the peaks of the two recorded snaps.

This was by no means a super accurate measurement, but at least the innate latency of the Mac recording pipeline should have been cancelled out this way. So that the error should mainly come from the peak distance measurement, which I assume should be much smaller than the audio pipeline latency and can be ignored.

I was expecting 20ms or lower latency, but clearly the result gave me 50~60ms. My ASBD uses kAudioFormatFlagsCanonical and kAudioFormatLinearPCM as format.

Solution

  • I'll summarize Paul R's comments as the answer, which has solved my problem:

    50 ms corresponds to a total buffer size of around 2048 at a 44.1 kHz sample rate, which doesn't seem unreasonable given that you have both a record and a playback path.

    I don't know that the buffer size is 2048, and there may be more than one buffer in your record-playback loopback test, but it seems that the effective total buffer size in you test is probably of the order of 2048, which doesn't seem unreasonable. Of course if you're only interested in record latency, as the title of your question suggests, then you'll need to find a way to tease that out separately from playback latency.