iOS: результат измерения задержки входного сигнала Bad Mic

Question

Я запускаю тест, чтобы измерить базовую задержку моего iPhone-приложения, и результат был разочаровывающим: 50 мс для тестового приложения для воспроизведения. Приложение просто подбирает микрофонный вход и воспроизводит его, используя тот же обратный вызов рендеринга, никаких других аудиоустройств или обработки. Поэтому результаты оказались слишком плохими для такого базового сценария. Мне нужны некоторые указатели, чтобы увидеть, имеет ли смысл смысл, или у меня были недостатки дизайна в моем тесте.

Основная идея теста была иметь три роли:

1. Мой палец оснастки в качестве эталонного источника звука.
2. Простой iOS play-thru приложение (с использованием встроенного микрофона) в качестве первого слушателя на # 1.
3. Mac (с USB-микрофоном и Audacity) в качестве второго прослушивателя для # 1 и единственным слушателем выхода iOS (через динамик, подключенный через гнездо для наушников iOS).

Затем, с Audacity в режиме записи, Mac будет подбирать звук из моих пальцев и его «клон» из динамика iOS в близком расстоянии. Наконец, я просто визуально наблюдаю за формой сигнала в записанной дорожке Audacity и измеряю временной интервал между пиками двух записанных снимков.

Это было отнюдь не суперточное измерение, но по крайней мере врожденная латентность конвейера записи Mac должна была быть отменена таким образом. Таким образом, ошибка должна в основном исходить из измерения максимального расстояния, которое, как я полагаю, должно быть намного меньше, чем латентность звукового конвейера, и его можно игнорировать.

Я ожидал 20 мс или ниже латентность, но, очевидно, результат дал мне 50 ~ 60 мс. В моем ASBD используется формат kAudioFormatFlagsCanonical и kAudioFormatLinearPCM.

Answer 1

Я резюмировать комментарии Paul R в качестве ответа, который решил мою проблему:

50 мс соответствует общему размеру буфера около 2048 с частотой дискретизации 44,1 кГц, что не кажется неразумным с учетом что у вас есть как запись, так и путь воспроизведения.

Я не знаю, что размер буфера 2048, и может быть более одного буфера в тестовом цикле проверки воспроизведения, но кажется, что эффективный общий размер буфера в вашем тесте, вероятно, имеет порядок 2048, что не кажется необоснованным. Конечно, если вас интересует только латентность записи, как говорит название вашего вопроса, тогда вам нужно будет найти способ дразнить это отдельно от латентности воспроизведения.

Answer 2

50 мС составляет около 4 мс больше, чем продолжительность двух звуковых буферов (один выход, один вход) размером 1024 при частоте дискретизации 44,1 кГц.

17 мСм составляет около 5 мСм больше, чем продолжительность 2 буферов длины 256.

Так выглядит как аудио задержки IOS, составляет около 5 мс плюс длительность двух буферов (выход длительность буфера аудио плюс время, необходимое для заполнения входного буфера) ... на вашем конкретном устройстве iOS.

Несколько устройств iOS могут поддерживать даже более короткие размеры буфера аудио из 128 образцов.

Answer 3

Вы можете использовать основной звук и настроить аудио сессию на очень низкую задержку. Вы можете установить buffer size to be smaller с помощью AudioSessionSetProperty(kAudioSessionProperty_PreferredHardwareIOBufferDuration,...

Использования меньшего размера буфера приводит к аудио обратного вызова происходить чаще во время захвата меньших кусков аудио. Имейте в виду, что это всего лишь предложение к аудиосистеме. IOS будет использовать подходящее значение времени обратного вызова на основе вашей частоты дискретизации и целых степени 2.

После того, как вы установите длительность буфера, вы можете получить фактическую продолжительность буфера, что система будет использовать с помощью AudioSessionGetProperty(kAudioSessionProperty_CurrentHardwareIOBufferDuration,...