Esta página foi traduzida pela API Cloud Translation.

AÁudio e MMAP

AAudio é uma API de áudio introduzida na versão Android 8.0. A versão Android 8.1 tem aprimoramentos para reduzir a latência quando usada em conjunto com um HAL e um driver compatível com MMAP. Este documento descreve a camada de abstração de hardware (HAL) e as alterações de driver necessárias para oferecer suporte ao recurso MMAP do AAudio no Android.

O suporte para AAudio MMAP requer:

relatando os recursos MMAP do HAL
implementando novas funções no HAL
implementando opcionalmente um ioctl() personalizado para o buffer do modo EXCLUSIVE
fornecendo um caminho de dados de hardware adicional
definindo propriedades do sistema que habilitam o recurso MMAP

AArquitetura de áudio

AAudio é uma nova API C nativa que fornece uma alternativa ao Open SL ES. Ele usa um padrão de design Builder para criar fluxos de áudio.

AAudio fornece um caminho de dados de baixa latência. No modo EXCLUSIVE, o recurso permite que o código do aplicativo cliente grave diretamente em um buffer mapeado de memória que é compartilhado com o driver ALSA. No modo SHARED, o buffer MMAP é usado por um mixer rodando no AudioServer. No modo EXCLUSIVE, a latência é significativamente menor porque os dados ignoram o mixer.

No modo EXCLUSIVE, o serviço solicita o buffer MMAP do HAL e gerencia os recursos. O buffer MMAP está sendo executado no modo NOIRQ, portanto, não há contadores de leitura/gravação compartilhados para gerenciar o acesso ao buffer. Em vez disso, o cliente mantém um modelo de temporização do hardware e prevê quando o buffer será lido.

No diagrama abaixo, podemos ver os dados da modulação por código de pulso (PCM) fluindo através do MMAP FIFO para o driver ALSA. Os carimbos de data/hora são solicitados periodicamente pelo serviço AAudio e, em seguida, transmitidos ao modelo de temporização do cliente por meio de uma fila de mensagens atômicas.

Diagrama de fluxo de dados PCM. — **Figura 1.** Fluxo de dados PCM através de FIFO para ALSA

No modo SHARED, um modelo de temporização também é usado, mas ele reside no AAudioService.

Para captura de áudio, um modelo semelhante é usado, mas os dados do PCM fluem na direção oposta.

Alterações HAL

Para tinyALSA veja:

external/tinyalsa/include/tinyalsa/asoundlib.h
external/tinyalsa/include/tinyalsa/pcm.c

int pcm_start(struct pcm *pcm);
int pcm_stop(struct pcm *pcm);
int pcm_mmap_begin(struct pcm *pcm, void **areas,
           unsigned int *offset,
           unsigned int *frames);
int pcm_get_poll_fd(struct pcm *pcm);
int pcm_mmap_commit(struct pcm *pcm, unsigned int offset,
           unsigned int frames);
int pcm_mmap_get_hw_ptr(struct pcm* pcm, unsigned int *hw_ptr,
           struct timespec *tstamp);

Para o HAL legado, consulte:

hardware/libhardware/include/hardware/audio.h
hardware/qcom/audio/hal/audio_hw.c

int start(const struct audio_stream_out* stream);
int stop(const struct audio_stream_out* stream);
int create_mmap_buffer(const struct audio_stream_out *stream,
                        int32_t min_size_frames,
                        struct audio_mmap_buffer_info *info);
int get_mmap_position(const struct audio_stream_out *stream,
                        struct audio_mmap_position *position);

Para HAL de áudio HIDL:

hardware/interfaces/audio/2.0/IStream.hal
hardware/interfaces/audio/2.0/types.hal
hardware/interfaces/audio/2.0/default/Stream.h

start() generates (Result retval);
stop() generates (Result retval) ;
createMmapBuffer(int32_t minSizeFrames)
       generates (Result retval, MmapBufferInfo info);
getMmapPosition()
       generates (Result retval, MmapPosition position);

Relatórios de suporte a MMAP

A propriedade do sistema "aaudio.mmap_policy" deve ser definida como 2 (AAUDIO_POLICY_AUTO) para que a estrutura de áudio saiba que o modo MMAP é suportado pelo HAL de áudio. (consulte "Ativando o caminho de dados AAudio MMAP" abaixo.)

O arquivo audio_policy_configuration.xml também deve conter um perfil de saída e entrada específico para o modo MMAP/NO IRQ para que o Audio Policy Manager saiba qual fluxo abrir quando os clientes MMAP forem criados:

<mixPort name="mmap_no_irq_out" role="source"
            flags="AUDIO_OUTPUT_FLAG_DIRECT|AUDIO_OUTPUT_FLAG_MMAP_NOIRQ">
            <profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
                                samplingRates="48000"
                                channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
</mixPort>

<mixPort name="mmap_no_irq_in" role="sink" flags="AUDIO_INPUT_FLAG_MMAP_NOIRQ">
            <profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
                                samplingRates="48000"
                                channelMasks="AUDIO_CHANNEL_IN_STEREO"/>
</mixPort>

Abrindo e fechando um fluxo MMAP

createMmapBuffer(int32_t minSizeFrames)
            generates (Result retval, MmapBufferInfo info);

O fluxo MMAP pode ser aberto e fechado chamando as funções do Tinyalsa.

Consultando a posição do MMAP

O timestamp passado para o Timing Model contém uma posição do quadro e um tempo MONOTONIC em nanossegundos:

getMmapPosition()
        generates (Result retval, MmapPosition position);

O HAL pode obter essas informações do driver ALSA chamando uma nova função Tinyalsa:

int pcm_mmap_get_hw_ptr(struct pcm* pcm,
                        unsigned int *hw_ptr,
                        struct timespec *tstamp);

Descritores de arquivo para memória compartilhada

O caminho de dados AAudio MMAP usa uma região de memória compartilhada entre o hardware e o serviço de áudio. A memória compartilhada é referenciada usando um descritor de arquivo gerado pelo driver ALSA.

Alterações do kernel

Se o descritor de arquivo estiver diretamente associado a um arquivo de driver /dev/snd/ , ele poderá ser usado pelo serviço AAudio no modo COMPARTILHADO. Mas o descritor não pode ser passado para o código do cliente para o modo EXCLUSIVO. O descritor de arquivo /dev/snd/ forneceria acesso muito amplo ao cliente, portanto, ele é bloqueado pelo SELinux.

Para suportar o modo EXCLUSIVE, é necessário converter o descritor /dev/snd/ para um descritor de arquivo anon_inode:dmabuf . O SELinux permite que esse descritor de arquivo seja passado para o cliente. Também pode ser usado pelo AAudioService.

Um descritor de arquivo anon_inode:dmabuf pode ser gerado usando a biblioteca de memória do Android Ion.

Para obter informações adicionais, consulte estes recursos externos:

"O alocador de memória Android ION" https://lwn.net/Articles/480055/
"Visão geral do Android ION" https://wiki.linaro.org/BenjaminGaignard/ion
"Integrando o alocador de memória ION" https://lwn.net/Articles/565469/

Alterações HAL

O serviço AAudio precisa saber se este anon_inode:dmabuf é suportado. Antes do Android 10.0, a única maneira de fazer isso era passar o tamanho do buffer MMAP como um número negativo, por exemplo. -2048 em vez de 2048, se suportado. No Android 10.0 e posterior, você pode definir o sinalizador AUDIO_MMAP_APPLICATION_SHAREABLE .

mmapBufferInfo |= AUDIO_MMAP_APPLICATION_SHAREABLE;

Alterações no subsistema de áudio

AAudio requer um caminho de dados adicional no front-end de áudio do subsistema de áudio para que possa operar em paralelo com o caminho original do AudioFlinger. Esse caminho legado é usado para todos os outros sons do sistema e sons do aplicativo. Essa funcionalidade pode ser fornecida por um mixer de software em um DSP ou um mixer de hardware no SOC.

Ativando o caminho de dados AAudio MMAP

AAudio usará o caminho de dados AudioFlinger legado se o MMAP não for compatível ou não abrir um fluxo. Portanto, o AAudio funcionará com um dispositivo de áudio que não suporta o caminho MMAP/NOIRQ.

Ao testar o suporte MMAP para AAudio, é importante saber se você está realmente testando o caminho de dados MMAP ou apenas testando o caminho de dados herdado. A seguir, descreve como habilitar ou forçar caminhos de dados específicos e como consultar o caminho usado por um fluxo.

Propriedades do sistema

Você pode definir a política MMAP por meio das propriedades do sistema:

1 = AAUDIO_POLICY_NEVER - Use apenas o caminho legado. Nem tente usar MMAP.
2 = AAUDIO_POLICY_AUTO - Tente usar MMAP. Se isso falhar ou não estiver disponível, use o caminho legado.
3 = AAUDIO_POLICY_ALWAYS - Use apenas o caminho MMAP. Não volte ao caminho legado.

Estes podem ser definidos no Makefile dos dispositivos, assim:

# Enable AAudio MMAP/NOIRQ data path.
# 2 is AAUDIO_POLICY_AUTO so it will try MMAP then fallback to Legacy path.
PRODUCT_PROPERTY_OVERRIDES += aaudio.mmap_policy=2
# Allow EXCLUSIVE then fall back to SHARED.
PRODUCT_PROPERTY_OVERRIDES += aaudio.mmap_exclusive_policy=2

Você também pode substituir esses valores após a inicialização do dispositivo. Você precisará reiniciar o servidor de áudio para que a alteração tenha efeito. Por exemplo, para habilitar o modo AUTO para MMAP:

adb root

adb shell setprop aaudio.mmap_policy 2

adb shell killall audioserver

Existem funções fornecidas em ndk/sysroot/usr/include/aaudio/AAudioTesting.h que permitem substituir a política para usar o caminho MMAP:

aaudio_result_t AAudio_setMMapPolicy(aaudio_policy_t policy);

Para descobrir se um stream está usando o caminho MMAP, chame:

bool AAudioStream_isMMapUsed(AAudioStream* stream);