J'essaie actuellement de minimiser la latence audio pour une application simple :
J'ai une vidéo sur un PC, et je transmets l'audio de la vidéo par RTP à un client mobile. Avec un algorithme de mise en mémoire tampon très similaire, je peux obtenir une latence de 90 ms sur iOS, mais une latence terrible de ± 180 ms sur Android.
Je suppose que la différence vient du fait que bien connu latence questions sur Android.
Cependant, après avoir lu un peu, Je suis tombé sur cet article qui stipule que :
-
L'audio à faible latence est disponible depuis Android 4.1/4.2 sur certains appareils.
-
L'audio à faible latence peut être obtenu en utilisant libpd, qui est la bibliothèque Pure Data pour Android .
J'ai deux questions, directement liées à ces deux déclarations :
-
Où puis-je trouver plus d'informations sur le nouveau système audio à faible latence de Jellybean ? C'est tout ce que j'ai pu trouver, mais il manque cruellement d'informations spécifiques. . Les changements doivent-ils être transparents pour moi, ou dois-je implémenter une nouvelle classe/des appels à l'API pour que je remarque des changements dans mon application ? J'utilise l'API AudioTrack et je ne suis même pas sûr qu'elle puisse bénéficier de cette amélioration ou que je doive me tourner vers un autre mécanisme de lecture audio.
-
Devrais-je envisager d'utiliser libpd ? Il me semble que c'est la seule chance que j'ai d'obtenir des latences plus faibles, mais puisque j'ai toujours considéré PD comme un utilitaire de synthèse audio, est-il vraiment adapté à un projet qui ne fait que saisir des images d'un flux réseau et les lire ? Je ne fais pas vraiment de synthèse. Est-ce que je suis la mauvaise piste ?
En outre, avant que quelqu'un ne mentionne OpenSL ES, Cet article indique clairement qu'il ne faut pas s'attendre à une amélioration de la latence en l'utilisant. :
"Comme OpenSL ES est une API C native, les threads d'applications non-Dalvik qui appellent OpenSL ES n'ont pas de surcharge liée à Dalvik, comme le garbage par exemple. appellent OpenSL ES n'ont pas de surcharge liée à Dalvik comme les pauses de la les pauses de collecte de déchets. Cependant, il n'y a pas d'avantage de performance supplémentaire à l'utilisation d'OpenSL ES que cela. En particulier, l'utilisation d'OpenSL ES ne se traduit pas par une latence audio plus faible, une priorité d'ordonnancement plus élevée, etc. que ce que la plate-forme fournit généralement."
13 votes
Je suis membre de l'équipe Android et je travaille en étroite collaboration avec les auteurs de l'article que vous citez. Le passage que vous citez n'est plus strictement vrai. Lorsque l'article a été écrit, les plus petits tampons disponibles pour OpenSL étaient encore assez grands. Maintenant que la taille des tampons a été réduite dans Jellybean, la latence a chuté à un point tel que "les frais généraux liés à Dalvik tels que les pauses de collecte des déchets" sont une considération très importante. La seule façon de profiter de manière fiable des tampons plus petits de Jellybean est d'utiliser OpenSL.