Les fournisseurs peuvent implémenter deux fonctionnalités clés pour réduire la latence audio :
- Mixeur FAST dans AudioFlinger : introduit dans Android 4.1, cette fonctionnalité est compatible avec les applications utilisant Java AudioTrack et AAudio. Le FAST Mixer implique des modifications minimes de l'API client publique ou de l'API HAL.
- AAudio MMAP : introduite dans Android 8.1, cette fonctionnalité permet aux applications natives d'obtenir une latence encore plus faible grâce à AAudio. Pour en savoir plus, consultez AAudio et MMAP.
Cette page décrit la conception initiale de la latence audio, qui a continué d'évoluer au fil du temps. Il est essentiel que les OEM d'appareils et les fournisseurs de SoC comprennent bien cette conception pour garantir une implémentation correcte sur leurs appareils et chipsets spécifiques. Cette page n'est pas destinée aux développeurs d'applications.
Création de pistes
Le client peut éventuellement définir le bit AUDIO_OUTPUT_FLAG_FAST
dans le paramètre audio_output_flags_t
du constructeur AudioTrack C++ ou AudioTrack::set()
. Actuellement, seuls les clients suivants le font :
- Audio natif Android basé sur OpenSL ES ou AAudio
android.media.SoundPool
android.media.ToneGenerator
L'implémentation C++ AudioTrack examine la requête AUDIO_OUTPUT_FLAG_FAST
et peut éventuellement la refuser au niveau du client. S'il décide de transmettre la requête, il le fait en utilisant le bit TRACK_FAST
du paramètre track_flags_t
de la méthode de fabrique IAudioTrack
IAudioFlinger::createTrack()
.
Le serveur audio AudioFlinger examine la requête TRACK_FAST
et peut éventuellement la refuser au niveau du serveur. Il indique au client si la requête a été acceptée ou non, via le bit CBLK_FAST
du bloc de contrôle de la mémoire partagée.
Voici les facteurs qui ont une incidence sur la décision :
- Présence d'un thread de mixeur rapide pour cette sortie (voir ci-dessous)
- Taux d'échantillonnage des titres
- Présence d'un thread client pour exécuter les gestionnaires de rappel pour cette piste
- Taille de la mémoire tampon de suivi
- Emplacements disponibles pour la procédure accélérée (voir ci-dessous)
Si la demande du client a été acceptée, on parle de procédure accélérée. Sinon, on parle de piste normale.
Fils de discussion Mixer
Au moment où AudioFlinger crée un thread de mixeur normal, il décide s'il faut également créer un thread de mixeur rapide. Le mixeur normal et le mixeur rapide ne sont pas associés à une piste spécifique, mais plutôt à un ensemble de pistes. Il existe toujours un thread de mixeur normal. Le thread du mixeur rapide, s'il existe, est subordonné au thread du mixeur normal et agit sous son contrôle.
Mixeur rapide
Fonctionnalités
Le thread du mélangeur rapide fournit les fonctionnalités suivantes :
- Mixage du sous-mix du mixeur normal et de sept pistes rapides client maximum
- Atténuation par piste
Fonctionnalités omises :
- Conversion du taux d'échantillonnage par piste
- Effets par piste
- Effets par mix
Point
Le mixeur rapide s'exécute périodiquement, avec une période recommandée de deux à trois millisecondes, ou une période légèrement plus élevée de 5 ms si nécessaire pour la stabilité de la planification. Ce nombre a été choisi de sorte que, en tenant compte de l'ensemble du pipeline de mémoire tampon, la latence totale soit de l'ordre de 10 ms. Des valeurs plus petites sont possibles, mais peuvent entraîner une augmentation de la consommation d'énergie et des risques de problèmes en fonction de la prévisibilité de la planification du processeur. Des valeurs plus élevées sont possibles (jusqu'à 20 ms), mais elles entraînent une dégradation de la latence totale et doivent donc être évitées.
Planification
Le mixeur rapide s'exécute avec une priorité SCHED_FIFO
élevée. Il a besoin de très peu de temps processeur, mais doit s'exécuter souvent et avec une faible gigue de planification.
Le jitter exprime la variation du temps de cycle. Il s'agit de la différence entre le temps de cycle réel et le temps de cycle attendu.
Si vous êtes trop en retard, des problèmes de synchronisation se produiront en raison d'un manque de données. Si vous exécutez le processus trop tôt, des problèmes se produiront, car vous extrairez des données d'un canal rapide avant que celui-ci n'ait fourni des données.
Vidéo bloquée
Idéalement, le thread du mixeur rapide ne se bloque jamais, sauf au niveau de HAL write()
. Les autres occurrences de blocage dans le mixeur rapide sont considérées comme des bugs. En particulier, les mutex sont évités.
À la place, des algorithmes non bloquants (également appelés algorithmes sans verrouillage) sont utilisés.
Pour en savoir plus, consultez Éviter l'inversion de priorité.
Relation avec d'autres composants
Le mixeur rapide interagit peu directement avec les clients. En particulier, il ne voit pas les opérations au niveau du binder, mais il accède au bloc de contrôle de la mémoire partagée du client.
Le mixeur rapide reçoit les commandes du mixeur normal via une file d'état.
En dehors de l'extraction des données de piste, l'interaction avec les clients se fait via la table de mixage normale.
Le récepteur principal du mixeur rapide est le HAL audio.
Mixeur normal
Fonctionnalités
Toutes les fonctionnalités sont activées :
- Jusqu'à 32 pistes
- Atténuation par piste
- Conversion du taux d'échantillonnage par piste
- Traitement des effets
Point
La période est calculée comme étant le premier multiple entier de la période du mixeur rapide qui est supérieur ou égal à 20 ms.
Planification
Le mixeur normal s'exécute avec une priorité SCHED_OTHER
élevée.
Vidéo bloquée
Le mixeur normal est autorisé à bloquer, et le fait souvent au niveau de différents mutex ainsi qu'au niveau d'un canal de blocage pour écrire son sous-mix.
Relation avec d'autres composants
Le mixeur normal interagit de manière intensive avec le monde extérieur, y compris les threads du binder, le gestionnaire de règles audio, le thread du mixeur rapide et les pistes client.
Le récepteur du mixeur normal est un canal bloquant pour la piste 0 du mixeur rapide.
Drapeaux
AUDIO_OUTPUT_FLAG_FAST
bits est un indice. Il n'est pas garanti que la demande sera traitée.
AUDIO_OUTPUT_FLAG_FAST
est un concept au niveau du client. Il n'apparaît pas sur le serveur.
TRACK_FAST
est un concept client-serveur.