Подтвердить что ты не робот

Воспроизведение аудио с низкой задержкой на Android

В настоящее время я пытаюсь свести к минимуму задержку звука для простого приложения:

У меня есть видео на ПК, и я передаю видео аудио через RTP мобильному клиенту. С очень похожим алгоритмом буферизации я могу достичь 90 мс латентности на iOS, но ужасно ± 180 мс на Android.

Я предполагаю, что отличия от известных задержек на Android.

Однако после прочтения немного, я столкнулся с этой статьей, в которой говорится, что:

У меня есть 2 вопроса, непосредственно связанных с этими 2 утверждениями:

  • Где я могу найти дополнительную информацию о новом аудио с низкой задержкой в ​​Jellybean? Это все, что я могу найти, но в нем не хватает конкретной информации. Должны ли изменения быть прозрачными для меня или есть какие-то новые вызовы класса /API, которые я должен реализовать для меня, чтобы заметить какие-либо изменения в моем приложении? Я использую API AudioTrack, и я даже не уверен, что он должен извлечь выгоду из этого улучшения или если я должен смотреть на какой-то другой механизм воспроизведения звука.

  • Должен ли я изучать использование libpd? Мне кажется, что это единственный шанс добиться меньших латентностей, но поскольку я всегда думал о PD как утилите для синтеза звука, действительно ли это подходит для проекта, который просто захватывает кадры из сетевого потока и воспроизводит их? Я вообще не синтезирую. Я следую за неправильным следом?

В качестве дополнительной заметки, прежде чем кто-то упоминает OpenSL ES, в этой статье совершенно ясно, что от ее использования не следует ожидать улучшения латентности:

"Поскольку OpenSL ES является родным API C API, не-Dalvik-приложениями, которые вызов OpenSL ES не имеет связанных с Dalvik накладных расходов, таких как мусор паузы коллекции. Однако нет дополнительных преимуществ в плане производительности к использованию OpenSL ES, кроме этого. В частности, использование OpenSL ES не приводит к более низкой задержке звука, более высокому приоритету планирования, и т.д., чем обычно предоставляет платформа.

4b9b3361

Ответ 1

Для минимальной задержки на Android с версии 4.2.2 вы должны сделать следующее, упорядоченное от наименьшего к самому очевидному:

  • Выберите устройство, поддерживающее FEATURE_AUDIO_PRO, если это возможно, или FEATURE_AUDIO_LOW_LATENCY, если нет. ( "Низкая латентность" составляет 50 мс в одну сторону, а "за" - 20 мс.)

  • Используйте OpenSL. У батареи Dalvik минимальная амортизированная стоимость, но при ее запуске требуется больше времени, чем может обеспечить звук с низкой задержкой.

  • Обработать аудио в обратном вызове очереди буфера. Система запускает обратные вызовы очереди буфера в потоке, который имеет более благоприятное планирование, чем обычные потоки пользовательского режима.

  • Сделайте свой размер буфера кратным AudioManager.getProperty(PROPERTY_OUTPUT_FRAMES_PER_BUFFER). В противном случае ваш обратный вызов будет иногда получать два вызова за один раз, а не один. Если ваше использование ЦП действительно не светло, это, вероятно, закончится срывом. (В Android M очень важно использовать ТОЧНО размер системного буфера из-за ошибки в коде обработки буфера.)

  • Используйте частоту дискретизации, предоставленную AudioManager.getProperty(PROPERTY_OUTPUT_SAMPLE_RATE). В противном случае ваши буферы будут перемещаться через системный ресамплер.

  • Никогда не выполняйте syscall или блокируйте объект синхронизации внутри обратного вызова буфера. Если вы должны синхронизировать, используйте блокирующую структуру. Для достижения наилучших результатов используйте абсолютно бессрочную структуру, такую ​​как кольцевой буфер с одним считывателем. Нагрузки разработчиков ошибочны и заканчиваются ошибками, которые непредсказуемы и трудно отлаживаются.

  • Используйте векторные инструкции, такие как NEON, SSE или что-то еще, что эквивалентный набор инструкций находится на вашем целевом процессоре.

  • Протестируйте и измерьте свой код. Отслеживайте, сколько времени требуется для запуска, и помните, что вам нужно знать производительность наихудшего случая, а не среднее, потому что худший случай - это то, что вызывает глюки. И быть консервативным. Вы уже знаете, что если для воспроизведения вашего аудио требуется больше времени, чем для его воспроизведения, вы никогда не получите низкой латентности. Но на Android это еще более важно, потому что частота процессора колеблется так сильно. Вы можете использовать, возможно, 60-70% процессора для аудио, но имейте в виду, что это изменится по мере того, как устройство станет более горячим или более холодным, или когда начнутся и прекратятся радиоприемники Wi-Fi или LTE и т.д.

Звук с низкой задержкой больше не является новой функцией для Android, но по-прежнему требуются изменения в аппаратном обеспечении, драйверах, ядре и фреймворке для устройства. Это означает, что существует множество вариаций в латентности, которые вы можете ожидать от разных устройств, и учитывая, сколько разных телефонов с ценами на телефоны Android продается, вероятно, всегда будут различия. Найдите FEATURE_AUDIO_PRO или FEATURE_AUDIO_LOW_LATENCY, чтобы идентифицировать устройства, соответствующие критериям задержки, требуемым вашим приложением.

Ответ 2

При использовании OpenSL ES вы должны выполнить следующие требования, чтобы получить результат с низкой задержкой на Jellybean и более поздних версиях Android:

  • Звук должен быть моно или стерео, линейный PCM.

  • Частота выборки аудио должна быть той же самой частоты дискретизации, что и исходная скорость вывода (на некоторых устройствах это может фактически не потребоваться, поскольку FastMixer способна передискретизировать, если поставщик настраивает ее таким образом Но в моих тестах я получил очень заметные артефакты при повышении частоты дискретизации от 44,1 до 48 кГц в FastMixer).

  • В вашем BufferQueue должно быть не менее 2 буферов. (Это требование с тех пор было расслабленным. См. этот коммит от Glenn Kasten. Я не уверен, в какой версии Android это впервые появилось, но угадайте будет 4.4).

  • Вы не можете использовать определенные эффекты (например, реверберация, усиление басов, выравнивание, виртуализация,...).

Класс SoundPool также попытается использовать быструю AudioTrack внутренне, когда это возможно (применяются те же критерии, что и выше, за исключением части BufferQueue).

Ответ 3

Из ссылки в вашей точке 1:

"Звук с низкой задержкой

Android 4.2 улучшает поддержку воспроизведения звука с низкой задержкой, начиная от улучшений, сделанных в версии Android 4.1 для аудиовыхода с использованием OpenSL ES, Soundpool и API-интерфейсов тонового генератора. Эти улучшения зависят от аппаратной поддержки - устройства, которые предлагают эти аудио-функции с низкой задержкой могут рекламировать свою поддержку приложений через константа аппаратного обеспечения."

Ваша цитата в полной форме:

"Производительность

Поскольку OpenSL ES является родным C API-интерфейсом, отличным от Dalvik, который вызов OpenSL ES не имеет связанных с Dalvik накладных расходов, таких как мусор паузы коллекции. Однако нет дополнительных преимуществ в плане производительности к использованию OpenSL ES, кроме этого. В частности, использование OpenSL ES не приводит к более низкой задержке звука, более высокому приоритету планирования, и т.д., чем обычно предоставляет платформа. С другой стороны, поскольку платформа Android и конкретные реализации устройств продолжают эволюция, приложение OpenSL ES может рассчитывать на выгоду от любого будущего повышения производительности системы".

Итак, api для общения с драйверами, а затем hw - OpenSl (таким же образом Opengl делает с графикой). Более ранние версии Android имеют плохой дизайн в драйверах и/или hw. Эти проблемы были устранены и исправлены с версиями 4.1 и 4.2, поэтому, если hd имеет мощность, вы получаете низкую задержку с помощью OpenSL.

Опять же, из этой заметки на веб-сайте библиотеки pureata видно, что библиотека использует OpenSL для достижения низкой латентности:

Поддержка с низкой задержкой для совместимых устройств Последняя версия Pd для Android (по состоянию на 12/28/2012) поддерживает звук с низкой задержкой для совместимых Android-устройства. При обновлении копии убедитесь, что вы версия как pd-for-android, так и подмодуль libpd от GitHub.

Во время записи Galaxy Nexus, Nexus 4 и Nexus 10 обеспечивают низкозаходная дорожка для аудиовыхода. Чтобы попасть в латентность трек, приложение должно использовать OpenSL, и оно должно работать с правильным частоту выборки и размер буфера. Эти параметры зависят от устройства (Galaxy Nexus и Nexus 10 работают на частоте 44100 Гц, а Nexus 4 работает при 48000 Гц; размер буфера для каждого устройства различен).

Как это обычно делается, Pd для Android-документов по всем этим сложностям, как насколько это возможно, обеспечивая доступ к новым функциям с низкой задержкой когда они доступны, оставаясь обратно совместимыми с предыдущими версии Android. Под капотом звуковые компоненты Pd для Android будет использовать OpenSL на Android 2.3 и более поздних версиях, а назад на старый API AudioTrack/AudioRecord в Java на Android 2.2 и ранее.

Ответ 4

Те из вас больше интересуются андроидами 10 Миллисекундной проблемой, т.е. звуком с низкой задержкой на Android. Мы в Superpowered создали объяснение задержки аудиодорожки Android. См. Здесь:

http://superpowered.com/androidaudiopathlatency/#axzz3fDHsEe56