Параллельный захват

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

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

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

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

Требования CDD

Требования к поддержке одновременного захвата данных см. в документе CDD .

Захват ситуаций из аудио HAL

В сценарии одновременного захвата могут возникать различные ситуации с точки зрения количества активных входных потоков, выбора входного устройства или конфигурации предварительной обработки.

Параллельное выполнение может происходить между следующими процессами:

  • Несколько входных потоков от процессора приложений (AP)
  • Входные потоки и голосовой вызов
  • Входные потоки и аудиопроцессор, реализующий маломощное распознавание ключевых слов.

Одновременная активность входных потоков AP

Файл конфигурации аудиополитики audio_policy_configuration.xml используется аудиофреймворком для определения того, сколько входных потоков может быть открыто и активно одновременно.

Как минимум, аудио HAL должен поддерживать хотя бы один экземпляр каждого входного профиля ( mixPort роли sink ), указанного в открытом и активном файле конфигурации .

Выбор устройства

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

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

Если технология совместима, рекомендуется, чтобы аудио HAL и подсистема позволяли захватывать разные потоки с разных устройств, таких как Bluetooth-гарнитура и встроенный микрофон.

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

В этом случае:

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

Если в аудио HAL определен порядок приоритетов между активными сценариями использования, следуйте тому же порядку, что и в source_priority() в frameworks/av/services/audiopolicy/common/include/policy.h

Выбор предварительной обработки

Аудиофреймворк может запрашивать предварительную обработку входного потока с помощью методов HAL addEffect() или removeEffect() .

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

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

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

Если по техническим причинам это невозможно для данной аудиоподсистемы, аудио HAL должен применять правила приоритета, аналогичные тем, которые указаны в разделе «Выбор устройства» .

Одновременный голосовой вызов и захват сигнала с точки доступа.

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

Во время звонка требуется два разных типа захвата сигнала от точки доступа.

Захват приема и передачи вызовов.

Захват и передача вызовов инициируются использованием источника звука AudioSource.VOICE_UPLINK или AudioSource.VOICE_DOWNLINK и/или устройства AudioDevice.IN_TELEPHONY_RX .

Аудио HAL должны предоставлять доступ к входному профилю ( mixPort роли sink ) с помощью маршрута от устройства AudioDevice.IN_TELEPHONY_RX .

Когда установлен вызов (аудиорежим — AudioMode.IN_CALL ), должна быть возможность одновременного наличия как минимум одного активного потока захвата с устройства AudioDevice.IN_TELEPHONY_RX .

Захват данных с устройств ввода во время активного вызова.

Когда вызов активен (аудиорежим — AudioMode.IN_CALL ), должна быть возможность открывать и активировать входные потоки с точки доступа, как указано в разделе « Одновременная активность входных потоков точки доступа» .

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

Одновременный захват данных с DSP и AP.

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

Это должно отражаться в флаге одновременного захвата, сообщаемом HAL звукового триггера через дескриптор реализации: ISoundTriggerHw.Properties.concurrentCapture = true .

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

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

Последствия для внедрения системы Assistant.

Требования к использованию данных и уведомлению пользователей.

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

  • Собранные с помощью микрофона данные не должны покидать устройство, если пользователь не взаимодействует с Ассистентом. Например, после активации ключевого слова.
  • Приложения, одновременно принимающие запрос, должны предоставлять пользователю визуальные подсказки после обнаружения ключевого слова. Это помогает пользователям понять, что дальнейшие разговоры будут вестись через другое приложение, например, через Ассистента.
  • Пользователи должны иметь возможность отключать микрофон или триггеры голосового помощника.
  • При хранении аудиозаписей пользователи должны иметь возможность в любое время получать к ним доступ, просматривать и удалять их.

Функциональные улучшения для Android 10

Ассистенты не мешают друг другу

В Android 9 и более ранних версиях, когда на устройстве постоянно работают два ассистента, только один из них может одновременно считывать ключевое слово. Следовательно, возникала необходимость переключаться между двумя ассистентами. В Android 10 ассистент по умолчанию может одновременно считывать ключевое слово и другой ассистент. Это обеспечивает гораздо более плавную работу для пользователей, использующих оба ассистента.

Приложения, удерживающие микрофон открытым.

Когда такие приложения, как Shazam или Waze, держат микрофон включенным, голосовой помощник по умолчанию может продолжать прослушивать ключевое слово.

В Android 10 для приложений, отличных от стандартных приложений Google Assistant, изменений в поведении не наблюдается.

Пример реализации аудио HAL

Пример реализации аудио HAL, соответствующей рекомендациям данного документа, можно найти в AOSP .