Comparaison intéressante entre pulseaudio et l'api audio native de Android, qui s'appelle AudioFlinger:
http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/
La comparaison est faite sur un Galaxy Nexus sous Android 4.0, sur lequel AudioFlinger s'appuie sur ALSA (comme pulseaudio).
En résumé:
- pulseaudio consomme legerement moins de cpu
- pulseaudio consomme moins d'energie
- pulseaudio permet une latence beaucoup plus faible: 20ms contre 176ms
# résumé complémentaire
Posté par bubar🦥 (Mastodon) . Évalué à 7. Dernière modification le 17 janvier 2012 à 22:45.
En complément pour le résumé :
Ce n'est pas le pulseaudio standard, il s'agit d'un portage.
Ce portage ne fonctionne pas sur Alsa mais sur salsa
Détail : la latence mesurée l'est pour un seul flux tel que décrit dans l'article.
Passionnant. Mais à relativiser, donc. (autre détail : la conclusion parle de SHM en:Shared memory dont il est difficile de voir la pertinence sur android, de part les limitations matérielles inhérentes à la plateforme, en terme de ram par exemple. Cela semble prématuré dès lors de parler de shm (pa pouvant le remplir vers ~40mo pour un simple desktop)
Hop. Article passionnant. (et assez savoueux de lire ces arguments pour PA aujourd'hui :)) Mais de là à dire que "PA explose AF", disons plutôt "ce portage de PA explose AF"
[^] # Re: résumé complémentaire
Posté par Tobu . Évalué à 2.
Effectivement, il y a une différence sur le composant userland d'ALSA. tinyalsa est hyper-minimale et écrite à neuf, salsa est une extraction d'un sous-ensemble de la bibliothèque ALSA standard. Je ne pense pas que l'avantage vienne de là; en fait on pourrait penser que salsa est plus lourde et désavantage Pulse. L'analyse d'Arun explique les différences de manière plausible et mesurable. Il constate moins de réveils avec PulseAudio, et fait le lien avec le scheduling sur des timers.
Sur l'IPC: ashmem et la SHM Posix servent à éviter les copies, ils devraient permettre un gain en mémoire non? L'ocupation exacte doit être tunable, on peut occuper moins de mémoire tant qu'on est prêt à ce que l'application se réveille plus souvent pour remplir les tampons.
[^] # Re: résumé complémentaire
Posté par monde_de_merde . É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.
[^] # Re: résumé complémentaire
Posté par bubar🦥 (Mastodon) . Évalué à 2. Dernière modification le 18 janvier 2012 à 13:34.
Simple : remettre en perspective le propos du journal. Apporter des compléments que l'article originel donne. (en m'abstenant de tout jugement personnel). C'est tout.
à propos de salsa je trouve que ça devrait être une piste à creuser de manière plus général, dans la mesure où depuis PA il y a des éléments de Alsa qui ne sont plus indispensables (dmix, typiquement) mais ça ne doit pas encore être possible pour des conditions de rétro-compatibilité. D'une autre côté pa est vraiment icontournable aujourd'hui ("intégration" de jack, amélioration générale, présence dans les distros, etc..) il serait donc logique qu'il "avance" (si possible) dans l'autre sens, en poussant dmix et qq lourdeurs de alsa dehors) Contrairement à ce que dit Tobu au dessus ("on pourrait penser que salsa est plus lourde pour PA") je m'étais dit que ça allégeait un peu la pile audio, et ça c'est bien
Clair. +1
Pour la blague si le R.H ou service achat qui découvre Collabora et n'est pas capable en deux minutes de se dire qu'il a affaire à des cadors, celui là devrait changer de métier :)
Là je suis plus dubitatif... L'argument "c'est présent dans les distros donc c'est meilleur" ne me semble pas être ni un argument vrai, ni valide, ni définitif. Par exemple pour avoir une vision complète pour ce cas il faudrait voir comme AF et PA se comportent en fortes charges, PA ayant toujours du mal avec ça, il serait intéressant comme AF se comporte.
Bref, bis : l'article est passionnant.
[^] # Re: résumé complémentaire
Posté par monde_de_merde . Évalué à 3.
Je ne dis pas que parce que c'est présent dans les distros, c'est meilleurs, ce que je dit c'est si c'est présent dans les distros et dans Android ce sera mieux.
Pour nous évidement parce Google a une force de développement et de test qui n'a (presque) pas d'égale dans l'industrie de l'Open Source, mais je pense aussi un peu pour Google parce que développer une API au dessus d'un composant qu'ils ne sont pas les seul à utiliser, ça doit quand même couter beaucoup moins cher que de repartir de zéro.
Bon après ce n'est que mon avis de semi-bisounours qui vaut ce qu'il vaut, mais Android est quand même un tout petit peu alourdi par le syndrome dNIH.
# Pas Glop
Posté par Gwen Gaumend . Évalué à -1.
Ah, content de l'apprendre.
C'est possible de l'installer ?
Parce que, sur mon HTC Dream avec Gingerbread 2.3.4, impossible d'écouter mes fichiers
audio AAC : ils sautent tous. Je ne comprends pas.
Pourtant, les vidéos passent bien, en h264 pour l'image et AAC pour l'audio !
J'attends VLC sur Android, pour voir si cela me résoud mes problèmes de son, mais
je n'y crois pas trop, j'ai essayé d'autres lecteurs audio.
Je suis donc prêt à installer pulseaudio sur mon HHTC Android.
S'il y a un fichier .apk à télécharger, je suis preneur pour un test.
# pulseaudio consomme moins et offre 0 latence
Posté par B16F4RV4RD1N . Évalué à 8.
Effectivement, sur plusieurs ordinateurs où j'ai installé Linux, PulseAudio offrait tellement moins de latence que le son était déjà terminé avant d'avoir commencé. Les utilisateurs étaient quand même ennuyé de ne pas pouvoir entendre le son. Une fois ce truc dégagé, le son fonctionnait correctement.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par coïn . Évalué à 8.
il y a combien de temps ?
Parce que les bugs de pulseaudio, c'est comme les BSOD de Windows, ca commence à dater.
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par B16F4RV4RD1N . Évalué à 3.
la première fois, c'était il y a 2-3 ans. La dernière fois, il y a 15 jours, sur la dernière Linux Mint : certaines applications offraient du son, d'autres pas. Une fois pulseaudieux déinstallé, tout fonctionnait sans problème, preuve que cette surcouche n'est au mieux pas nécessaire, et au pire néfaste.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par gnumdk (site web personnel) . Évalué à 6.
Idem sous Arch, avec pulseaudio, j'ai du son et puis d'un coup, pouf plus rien... Ca arrive rarement mais suffisamment pour le supprimer...
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par brendel . Évalué à 6.
Moi j'avais des BSOD régulièrement sur Windows 7, pendant plusieurs semaines. J'ai pourtant cherché d’où ça venait, notamment sur la doc officielle, mis tout les drivers à jour,ect. parce que j'avais vraiment pas envie de tout réinstaller. Mais finalement c’est ce que j'ai fait. On dirait que la bonne vieille habitude de la ré-installation régulière est encore d'actualité. Maintenant, je n'ai plus de BSOD du tout (ce qui enlève l’hypothèse d'un problème matériel, ce que je pensais au début).
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par Olivier Serve (site web personnel) . Évalué à 1.
Il y a encore des problèmes, par exemple avec certains programmes sous wine (Skyrim p.e.).
Sans PA, ça marche.
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par zebra3 . Évalué à 4.
PulseAudio est maintenant largement stabilisé, mais son paramétrage par défaut n'est pas franchement terrible ; c'est peut-être de ce côté qu'il faut regarder.
La première chose que je change à l'installation est le paramètre resample-method que je fixe à trivial dans /etc/pulse/daemon.conf, ça permet déjà de moins consommer de CPU.
Après, il y a plein d'autres entrées, à voir dans man pulse-daemon.conf
C'est vraiment dommage que le défaut ne soit pas optimal, ça résoudrait la plupart des problèmes que les gens rencontrent encore (même si ça fait longtemps que je n'en ai pas croisé).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par Troy McClure (site web personnel) . Évalué à 5.
et la qualité sonore ne se degrade pas quand il y a du reechantillonage ? parce que "trivial" ça sonne comme "interpolation lineaire" voire pire (j'imagine qu'il faut se taper les sources pour savoir ce que c'est exactement) , le genre de truc idéal pour avoir un son de casserole. Le fait qu'ils aient choisi par defaut un resampling de qualité correcte ne me semble pas etre une erreur de configuration.
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par zebra3 . Évalué à 3.
Non, j'ai pas senti de dégradation, au contraire : le son ne sautait plus.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par Grunt . Évalué à 5.
Ah, donc ce truc a été mis en place pour que le bureau Linux soit plus sympa envers les utilisateurs qui viennent de Windows/Mac OS et autres cliquodrômes, et il nécessite de modifier des fichiers textes en tant que root avec des paramètres cryptiques pour bien fonctionner ?
On n'arrête pas le progrès :)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par zebra3 . Évalué à 6.
Ben s'il arrivait avec des paramètres par défaut corrects, il n'y aurait plus rien à faire, ça ne serait pas drôle.
Un bureau libre, ça se mérite.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par claudex . Évalué à 3.
J'avais eu des problèmes avec PulseAudio, du coup j'avais chercher une documentation. En a-tu trouvé pour savoir dans quel fichier modifier les paramètres ou tu as essayé au hasard ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par zebra3 . Évalué à 2.
Je ne sais plus où j'ai lu ça, mais je sais que je n'avais pas cherché. J'avais dû voir passer ça sur la debian-user-french et ça avait bien amélioré les choses (faut dire c'était déjà largement utilisable, c'était juste parfois gênant).
Comme quoi ça sert les listes, même si on n'a rien à y écrire :)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par monde_de_merde . Évalué à 3.
Soit j'ai un ange gardien dont les skills en administration de système et programmation sont colossaux, soit il y a beaucoup de gens de mauvaise foi un peu partout.
Parce que la dernière fois que j'ai eu un problème avec PA, c'était il y a fort longtemps, au moins 2 ans.
Peut être que je devrait parler de ma petit situation personnelle (en la présentant comme une généralité évidement) pour faire chier ceux chez qui ça en marche pas à chaque fois qu'on parle de PA en disant que chez moi ça marche.
Et je pourrais même leur réclamer des rapports de bug en disant : "bug report or it didn't happen".
Ce serait hyper constructif.
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par BFG . Évalué à 4.
C'est un très bon moyen pour se glorifier et prétendre que notre logiciel n'a aucun problème, parce que beaucoup de situations à problèmes sont difficiles à reproduire (surtout quand le problème implique de nombreux logiciels agissant en même temps, ainsi que de très nombreux autres paramètres), ou qu'il y a une part de subjectif ("le son est souvent de mauvaise qualité"), ou que l'on peut rejeter les rapports de bugs facilement ("pas assez d'informations, affaire classée").
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par bubar🦥 (Mastodon) . Évalué à 4. Dernière modification le 18 janvier 2012 à 13:42.
Pareil :
J'utilise PA quotidiennement depuis presque un an, et même constat : absolument aucun problème. ça fonctionne parfaitement. En plus, point de détail, j'aime bien le design d'un léger son lorsqu'il libère la carte son, ça fait très sain (même si ce n'est que du design)
Le défaut reste sa charge cpu pour une utilisation "audio" du bureau gnu/linux. PA et Jack suffisent dans la plupart des cas. Mais pour certains cas il faut encore virer totalement PA. Pas question d'espérer avoir une latence de 20ms sur 32 pistes si PA tourne : un intel i7 n'y survirait pas 2 heures ... (sans parler de recherche de perfs pour obtenir la limite de son matériel afin de connaître "l'étalon", simplement un usage pas commun mais réel : 20ms de latence sur 32 pistes, PA ne peut pas encore assurer cela)
Ceci dit, PA au quotidien, pour moi aussi c'est devenu un vrai petit régal (bon, faut dire qu'utilisant Gnome, ça aide beaucoup).
[^] # Re: pulseaudio consomme moins et offre 0 latence
Posté par claudex . Évalué à 4.
Je peux me tromper, mais je pense que beaucoup de bugs de Pulseaudio sont liés à la configuration matériel. Ce qui fait que certains n'ont plus eu de bugs depuis 2 ans et d'autres en ont toujours.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# La réaction de Lennart
Posté par letsyl . Évalué à 9.
C'est ici : http://0pointer.de/blog/projects/aruns-numbers.html
Avec notamment : "Apparently, AudioFlinger is a great choice if you want to shorten your battery life.".
La grande classe :)
# Et si on compare avec OSS?
Posté par Maclag . Évalué à 5.
Histoire d'avoir un Troll plus trollesque, quoi!
# Tu oublie un "petit" détail
Posté par reno . Évalué à 6.
PulseAudio est LGPL que Google évite dans Android donc porter l'API native d'Android au dessus de PA comme évoquer dans l'article me parait une perte de temps..
Je serai Google je payerai les dev de PA pour qu'ils acceptent de mettre leur code en licence BSD, ça coûterait probablement moins cher que d’améliorer AudioFlinger.
[^] # Re: Tu oublie un "petit" détail
Posté par JoeltheLion (site web personnel) . Évalué à 4.
Ca ferait tellement mal pour Google de mettre quelque part les sources de Pulse Audio en téléchargement?
LGPL, c'est pas la fin du monde, quand même. (à moins que ça ne soit la LGPL v3 et que ce soit une histoire de brevets?)
# Y a un truc qui cloche
Posté par Batchyx . Évalué à 7.
C'est bien sa comparaison, mais la seule chose qu'il à tésté, c'est la lecture d'un fichier audio, sans savoir quel chip son il utilisait.
Sur les SoC prévus pour téléphones portables que j'ai vu, y a des chips sons qui sont un poil plus compliqué que "une entrée et une sortie". C'est plutôt du genre usine à gaz qui en fait le maximum en hard en supportant genre des entrées/sorties directement relié au modem avec l'encodage avec le codec qui va bien, de l'encodage/décodage A2DP pour le bluetooth, de l'annulation d'écho et de bruit (avec un deuxième micro), ainsi que plein de mixage pour par exemple diriger directement le flux A2DP vers le GSM sans passer par le processeur. Et j'imagine qu'il y a encore bien d'autres fonctionnalités (décodage MP3?).
Est ce que ça supporte tout ça, pulseaudio ?
Après, le fait que ça soit fait sur un truc dédié va peut-être consommer plus, mais va peut-être libérer de la puissance pour le processeur pour qu'il puisse faire quelque-chose d'intéressant, ou tout simplement glander en veille.
[^] # Re: Y a un truc qui cloche
Posté par bubar🦥 (Mastodon) . Évalué à 3. Dernière modification le 19 janvier 2012 à 14:34.
Et il oublie aussi de préciser que la limite de latence sur laquelle son test se base pour faire du bruit n'est pas une limite atteinte par AF comme l'article le laisse sous-entendre, mais une limite d'architecture (Difficile de comparer ce qui tourne au dessus de Dalvik avec une solution tournant en dessous, c'est comparable en terme de fonctionnalité (bémol AF propose en plus une spécificité) c'est tout)
Le jour où Google ressentira le besoin d'avoir une solution pour l'audio-rt, nul doute qu'il le feront en dessous de AF, avec une lib spécifique, afin de contenter ce type de logiciels qui commencent à arriver... Mais pas en remplaçant l'élément AF par une couche au dessus autre, en plus en nécessitant une couche de compat avec af pour garantir l'historique. Ou, rêvons un peu, qu'ils attendent Asio (ou Jack) for Android, ou mieux encore : qu'ils améliorent Alsa directement... ce qui bénéficierait à tous
Bref, c'est un troll Java vs C, mais pas plus.
[^] # Re: Y a un truc qui cloche
Posté par Troy McClure (site web personnel) . Évalué à 2.
A priori audioflinger c'est un demon écrit en c++: http://gitorious.org/android-eeepc/base/blobs/90329a69f8e26626c3dc51c50a287e47931afe18/libs/audioflinger/AudioFlinger.cpp
Sinon j'aime bien le bug report sur les pb de latence d'android qui montre bien que google n'en a strictement rien à foutre: http://code.google.com/p/android/issues/detail?id=3434
[^] # Re: Y a un truc qui cloche
Posté par reno . Évalué à 2.
Merci pour le lien, ça me rappelle les bugs report sur Java qui duraient des années avec plusieurs centaines de commentaires.
Mais bon là c'était moins drôle car j'avais besoin des corrections, en spectateur non intéressé c'est plus amusant.
[^] # Re: Y a un truc qui cloche
Posté par bubar🦥 (Mastodon) . Évalué à 4. Dernière modification le 19 janvier 2012 à 16:32.
Moi aussi. Ce lien était dans le post du blog, également. A lire aussi : ça fil dans lequel Glenn Kasten intervient (là) pour mettre des points sur les i.
Et c'est clairement dit par plusieurs personnes : au dessus de 10ms, pas question de parler low_latency.
Oui mais il est exposée comme ça. Ce qui rend intéressant cette phase dans son blog : "make the comparison fair plays it via the AudioTrack interface" Gros Gros SIC. En gros, PA est meilleur que AF en passant par ça. Bon heu... Retour à la case "lorsque Android aura besoin d'une solution audioRT, il le feront en deça de 10ms... et pas en remplacement l'existant, encore moins en remplaçant l'existant par un truc à peine mieux sur lequel il faudrait ajouter effects ainsi qu'une grosse couche de compat avec l'ancien existant.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.