Android OpenSL ES кристальная частота

Question

У нас есть приложение с мобильными аудиоклиентами, написанными на низкоуровневом OpenSL ES, для достижения низкого уровня задержки ввода с микрофона Затем мы отправляем на сервер кадры 10 мс, инкапсулированные в дейтаграмму UDP.

На сервере мы выполняем некоторую постобработку, которая в зависимости от обстоятельств зависит от предположения, что кадры от мобильных клиентов поступают через фиксированные интервалы (например, 10 мс на кадр), поэтому мы можем выровнять их.

Кажется, что внутренние частоты кристаллов на мобильных телефонах могут сильно различаться, и из-за этого мы получаем идеальное выравнивание в начале, но плохое выравнивание через несколько минут.

Я знаю, что ALSA в Linux может сказать вам точную частоту кристалла - так что вы можете исправить свои подсчеты на основе этого. К сожалению, я не знаю, как получить эту информацию в Android.

Спасибо за помощь

Answer 1

Суть проблемы, с которой вы сталкиваетесь, заключается в том, что у вас есть АЦП и ЦАП в отдельных системах с разными локальными генераторами. Вы, вероятно, синхронизируете свои пакеты с 3-й (и, возможно, 4-й) тактовой частотой процессора.

Правильным решением этой проблемы является какой-то алгоритм восстановления часов. Чтобы сделать это должным образом, вам нужны некоторые средства точной отметки времени (например, битовой точности) передаваемых пакетов, а затем использовать PLL для управления тактовой частотой тактовой частоты выборки получателя. Это именно тот подход, который используют как аудио IEEE1394, так и транспортные потоки MPEG2.

Поскольку, вероятно, невозможно выполнить ни одно из этих действий, ваш подход, скорее всего, будет включать периодическое удаление или повторение выборок (или даже целых пакетов) периодически, чтобы сохранить ваш буфер приема от недостаточного или избыточного переполнения.

У USB Audio аналогичная нехватка аппаратной поддержки для восстановления тактового сигнала, и используемые там подходы могут быть применимы к вашей ситуации.

Полагаться на время передачи и приема сетевых пакетов - ужасная идея. Дрожание во времени доставки ужасно - особенно с Wi-Fi или сотовой связью. Рекомендуем использовать не полагаться на него вообще, а вместо этого делать то же самое, что и IEEE1394 audio, и MPEG 2 TS, что позволяет отделить передачу аудиоданных от потребления с использованием модели FIFO, в которой данные используются с постоянной скоростью. и доставлены к нему в пакетах ненадежного времени.

Что касается ALSA, все, что он может сделать (если только не имеет точной внешней временной привязки), это измерить дрейф между тактовой частотой дискретизации аудиоинтерфейса и тактовой частотой процессора. Это не дает "точную частоту" чего-либо, так как ни один из осцилляторов не может быть точным, и оба могут дрейфовать в зависимости от температуры.