Audio Server и буферизация¶
Используйте эту страницу после выбора аудиоинтерфейса и сценария работы изделия, описанных в обзоре аудио. Здесь рассматриваются границы ответственности во время работы между кодом приложения, сеансами Audio Server, буферами DMA и аппаратным аудиотрактом.
Область действия сведений о SDK: приведённые ниже сведения об API задокументированы для SF32LB52x в текущей версии SiFli SDK. Для целевого семейства и версии SDK сверьтесь с audio_server.h, реализацией и конфигурацией. Рекомендации по размеру буферов, планированию и работе с кэшем являются инженерными практиками; Audio Server не гарантирует одинаковое поведение и правила владения буферами на всех платформах.
Распределение ответственности¶
Отделяйте политику приложения от механизмов передачи аудиопотока. Приложение определяет, когда начинать и останавливать воспроизведение или запись и как менять состояние; Audio Server координирует сеанс; DMA передаёт блоки отсчётов; драйвер отвечает за конфигурацию оборудования. Во время активного потока не позволяйте интерфейсу пользователя, callback-функциям Bluetooth или чтению файловой системы напрямую управлять регистрами кодека.
| Граница | Ответственный компонент | Вопрос для проверки |
|---|---|---|
| Исходные данные | Приложение, декодер или задача работы с хранилищем | Успевает ли компонент пополнять очередь воспроизведения до её опустошения? |
| Кэш записи Audio Server, если настроен | Audio Server; размер задаётся конфигурацией приложения | Допустимо ли значение write_cache_size для этого SDK и обрабатывает ли приложение все результаты audio_write()? |
| Буфер активной передачи | DMA/аудиодрайвер | Остаётся ли буфер неизменным и когерентным относительно кэша в течение всей передачи? |
| Буфер после завершения передачи | Приложение или задача обработки | Успевают ли подготовить данные воспроизведения или обработать записанные данные до повторного использования области DMA? |
| Состояние сеанса | Audio Server и политика приложения | Предотвращают ли повторные запросы запуска, остановки, обработки ошибки и завершения двойное закрытие или освобождение ресурсов? |
Выберите стратегию буферизации¶
Если драйвер поддерживает двойную буферизацию, с неё удобно начать: DMA передаёт одну область, пока ПО в другой готовит данные воспроизведения или обрабатывает записанные данные. Различайте очередь PCM приложения и DMA-буфер драйвера. Запись в Audio Server сама по себе не означает передачу DMA без копирования.
Увеличивайте ёмкость очереди только тогда, когда этого требуют задержки накопителя, время декодирования, джиттер транспорта Bluetooth или разброс времени выполнения задач. Ёмкость занимает память; время ожидания определяется объёмом аудиоданных, фактически помещённых в очередь. Само выделение дополнительных буферов не обязательно увеличивает задержку. Используйте расчёты по аудиокадрам из обзора аудио, учитывая число каналов и количество байтов, занимаемых каждым отсчётом.
Измеряйте длительность блока, максимальное время подготовки или обработки и допустимую сквозную задержку. Определяйте каждый срок по уведомлениям целевого драйвера о необходимости пополнить буфер и завершении передачи, а также по порядку повторного использования буферов. Если драйвер поддерживает обратные вызовы для половины передачи и её завершения, планируйте обработку с учётом этих переходов; не считайте окончание текущей передачи единственным сроком. Данные воспроизведения должны быть готовы до того, как понадобятся DMA; записанные данные нужно обработать или скопировать до их перезаписи DMA. Оставляйте запас на планирование задач и выясняйте причины даже редкого опустошения буфера воспроизведения (underrun) и переполнения буфера записи (overrun).
Для памяти, которую приложение или драйвер напрямую передаёт DMA, соблюдайте правила работы с кэшем и владения буферами целевой платформы: до того как DMA начнёт читать данные воспроизведения, сбросьте в память изменённые строки кэша, содержащие эти данные; подготовьте приёмные буферы согласно требованиям; и при необходимости инвалидируйте кэш записанных данных до чтения CPU. Эти требования зависят от SoC, области памяти и API драйвера. Не выполняйте ручное обслуживание кэша буферов, принадлежащих Audio Server или драйверу, если этого не требует API. Не изменяйте, не освобождайте и не используйте повторно область, которой владеет DMA.
В документации Audio Server для SF32LB52x указано, что обратные вызовы выполняются в потоке Audio Server, а callback audio_open() не должен вызывать audio_close(), поскольку это может привести к взаимной блокировке. Ограничивайте длительность обратных вызовов, а блокирующие операции с накопителем или обработку поручайте рабочему потоку. В обработчик захвата передаются указатель и длина одного аудиокадра; в указанной документации не определено, как долго этот указатель остаётся действительным после завершения обработчика. Копируйте данные до возврата из обработчика, если целевой SDK явно не гарантирует более длительный срок действия.
В той же документации SF32LB52x описаны следующие результаты audio_write():
| Возвращаемое значение | Документированное значение |
|---|---|
> 0 |
Значение равно data_len; данные приняты в кэш записи. |
0 |
Кэш записи заполнен. Запрос размером больше настроенной ёмкости также отклоняется с результатом 0. |
-1 |
Клиент находится на паузе или приостановлен (suspended); переданные аудиоданные отбрасываются. |
-2 |
Недопустимый параметр. |
В этом API размер write_cache_size ограничен значением 0x7FFF байт; для схемы записи ping-pong документация рекомендует ёмкость не менее удвоенного объёма данных одного вызова audio_write(). Это программный кэш записи Audio Server, а не гарантия физической организации DMA-буферов драйвера. Прежде чем применять эти ограничения, проверьте SDK целевой платформы. Приоритеты клиентов, микширование и доступные аудиотракты также зависят от конфигурации; открытие сеанса не гарантирует, что Audio Server предоставляет доступ ко всем аудиоинтерфейсам чипа.
Проверка под нагрузкой изделия¶
Проверяйте сеанс при типичной совместной нагрузке устройства: обновлении дисплея, уведомлениях или аудио Bluetooth, чтении и записи накопителя, журналировании и переходах в энергосберегающие режимы. Регистрируйте опустошение буфера воспроизведения и переполнение буфера записи, заполнение очереди, задержку от обратного вызова до запуска рабочего потока, аудиосбои, переподключения и переходы сна/пробуждения. Проверяйте прерывание по приоритету, приостановку и возобновление, ошибки запуска и повторные запросы остановки. Убедитесь, что предусмотренное восстановление работает, а потери данных не остаются незамеченными.
При завершении убедитесь, что драйвер остановил передачи и ожидающие обратные вызовы больше не могут обращаться к освобождённым буферам. Проверьте снятие запросов управления питанием аудиотракта и отключение внешних компонентов в соответствии с аппаратной последовательностью. Для проверки энергопотребления системы см. обзор энергосбережения, для совместной работы с радиотрактом — обзор Bluetooth.
Последнее обновление: