Ce n'est effectivement pas le pulseaudio standard comme tu dis, c'est un portage, mais je ne vois pas en quoi exactement cela rend ses conclusion moins valides. Évidement qu'il ne va pas utiliser un PA compiler pour le noyau de Debian puisqu'il s'agit d'Android là. Et par ailleurs il insiste sur le fait que le portage en question a essentiellement consister en une transformation du build system pour l'adapter à Android. Et je ne vois toujours pas où tu veux en venir.
On en saura plus sur les modifications apportées à PA pour le faire tourner sur Android mais l'objectif de cette article n'est pas tant de montrer que PA >>AF mais surtout que Collabora possède un excellent savoir faire en terme de portage, y compris quand on prend une brique un peu compliquée comme PA et qu'on la met sur Android, le résultat de la comparaison de PA et AF est un effet collatéral.
En ce qui concerne salsa/alsa, il n'est pas hyper clair la dessus mais il me semble que pour ses tests il utilise Alsa (car salsa n'a pas de support pour UCM) :
For our purposes, though, just using alsa-lib is good enough.
Ce n'est pas tant à relativiser que ça, et oui je suis d'accord avec l'auteur du journal PA explose AF, mais pas uniquement pour des raisons de performance et de latence. Alsa, Salsa, PA et compagnie sont des morceaux presque standard dans une distribution Linux, les intégrer au socle d'Android est clairement un avantage par rapport à l'utilisation d'une brique custom. En particulier si cela peu conduire à réduire le delta entre un système Linux habituel et Android, si cela peut amener Google à s'investir dans Alsa et PA et surtout si cela montre au firme qui exploite l'OpenSource qu'une solution maison n'a pas toujours l'avantage face à une solution générale.
Les plus gros avantages d'AF sur PA ce sont les API, en particulier l'API "effects", comme mentionné dans l'article de LWN. Mais bon une couche de compatibilité ne devrait pas réduire de beaucoup les avantages de PA.
[^] # Re: résumé complémentaire
Posté par monde_de_merde . En réponse au journal Pulseaudio sur Android. Évalué à 6.
Ce n'est effectivement pas le pulseaudio standard comme tu dis, c'est un portage, mais je ne vois pas en quoi exactement cela rend ses conclusion moins valides. Évidement qu'il ne va pas utiliser un PA compiler pour le noyau de Debian puisqu'il s'agit d'Android là. Et par ailleurs il insiste sur le fait que le portage en question a essentiellement consister en une transformation du build system pour l'adapter à Android. Et je ne vois toujours pas où tu veux en venir.
On en saura plus sur les modifications apportées à PA pour le faire tourner sur Android mais l'objectif de cette article n'est pas tant de montrer que PA >>AF mais surtout que Collabora possède un excellent savoir faire en terme de portage, y compris quand on prend une brique un peu compliquée comme PA et qu'on la met sur Android, le résultat de la comparaison de PA et AF est un effet collatéral.
En ce qui concerne salsa/alsa, il n'est pas hyper clair la dessus mais il me semble que pour ses tests il utilise Alsa (car salsa n'a pas de support pour UCM) :
Ce n'est pas tant à relativiser que ça, et oui je suis d'accord avec l'auteur du journal PA explose AF, mais pas uniquement pour des raisons de performance et de latence. Alsa, Salsa, PA et compagnie sont des morceaux presque standard dans une distribution Linux, les intégrer au socle d'Android est clairement un avantage par rapport à l'utilisation d'une brique custom. En particulier si cela peu conduire à réduire le delta entre un système Linux habituel et Android, si cela peut amener Google à s'investir dans Alsa et PA et surtout si cela montre au firme qui exploite l'OpenSource qu'une solution maison n'a pas toujours l'avantage face à une solution générale.
Les plus gros avantages d'AF sur PA ce sont les API, en particulier l'API "effects", comme mentionné dans l'article de LWN. Mais bon une couche de compatibilité ne devrait pas réduire de beaucoup les avantages de PA.