PulseAudio est un serveur de son multiplate-forme en réseau, publié sous licence LGPL 2.1. Son développement a été commencé par Lennart Poettering, ce développeur est aujourd'hui reconnu pour ses nombreuses contributions à l'écosystème Linux, même si celles-ci ne font pas toujours l'unanimité. Le rôle principal d'un serveur PulseAudio au sein d'un système d'exploitation est d'effectuer le mixage des différents canaux audio en provenance des diverses applications et sources d'entrée, puis leur lecture sur des périphériques audio tels que des cartes sons locales ou distantes.
Merci à solstice, patrick_g, liberforce, Nils Ratusznik, PierreLM, moi1392, tankey, Bruno, Xavier Claude, Strash, Benoît et Enjolras pour avoir participé à la rédaction de cet article.
Sommaire
État des lieux
Principales caractéristiques
- Mixage des différents flux audio, avec contrôle du volume par application
- Routage des flux audio, avec par exemple la lecture d'un micro d'une carte son sur la sortie d'une autre carte son
- Transparence réseau, permettant à une application de lire un flux audio sur une machine distante
- Abstraction logicielle, de par la possibilité de jouer des flux en provenance de multiples API audio au travers d'adaptateurs ALSA, OSS, aRTS, Jack…
- Abstraction matérielle grâce à l'utilisation des pilotes audio ALSA
Rappel des fonctionnalités
- Contrôle du volume sonore par application
- Combinaison de multiples cartes son en une seule
- Auto-détection des périphériques (exemple : carte son USB, oreillette bluetooth)
- Mode « pass through » pour les sorties sur HDMI ou S/PDIF
- Diffusion de flux audio en A2DP, DLNA, RTP
- Réception de flux à partir de serveurs PulseAudio, AirTunes ou de flux RTP
- Synchronisation de multiples flux de lecture, notamment au travers d'un réseau
- Gestion précise de la latence pour la lecture ou l'enregistrement
- Conversion d'échantillon intégrée, possibilités de ré-échantillonnage
- Architecture de greffons extensible avec gestion de modules pouvant être chargés dynamiquement
- Architecture mémoire « zero-copy » pour la gestion des ressources lorsqu'aucun ré-échantillonnage n'est nécessaire
PulseAudio ou pas ?
PulseAudio a été conçu dans l'optique d'une utilisation sur un ordinateur de bureau. Les problématiques spécifiques à cet usage sont un environnement matériel changeant (ajout / suppression de périphérique audio « à chaud »), un contrôle par application du volume et de la sortie audio, une utilisation CPU et mémoire réduite tout en gardant une latence adaptée à la situation, et une gestion de l'énergie efficace.
Ce n'est pas un remplaçant d'ALSA, dont il utilise la pile de pilotes pour accéder au matériel audio, ainsi qu'une partie de ses bibliothèques pour communiquer avec certaines applications. ALSA dispose bien d'un mixeur nommé Dmix, mais ses fonctionnalités sont terriblement limitées. Pas de gestion dynamique des périphériques audio, de transparence réseau…
Ce n'est pas non plus un concurrent de JACK, car ces deux projets évoluent dans des environnements aux contraintes diamétralement opposées. PulseAudio s'occupant des problématiques complexes rencontrées sur un ordinateur personnel dit « de bureau » (politique de routage, mise à disposition aisée des ressources matérielles et réseau…) tandis que Jack s'occupe uniquement de routage et propose cela en très faible latence si nécessaire, avec contrôle complet mais manuel. Jack et PulseAudio ne sont donc pas concurrents, mais complémentaires en termes de réponse aux besoins. En outre, depuis peu, PA et JACK peuvent travailler de concert sur un même système pour répondre à certaines problématiques. JACK prend le pas dans la gestion audio, et lance PA en tant qu'un de ses clients. Ceci permet, par exemple, de gérer des applications incompatibles avec JACK en redirigeant le trafic vers PA. Pour plus de détails sur la relation entre les deux projets Lennart a écrit un article sur le sujet.
Architecture
On peut voir sur ce schéma que PulseAudio fait la liaison entre les applications et les pilotes audio ALSA. Il fonctionne en espace utilisateur et un processus est lancé par utilisateur.
PulseAudio v2.0
Principales nouveautés
Abandon du support de ESD (Enlightened Sound Daemon) au profit d'une approche plus native.
PulseAudio pouvait jusqu’à présent être utilisé comme remplaçant « clé en main » d'ESD, et bénéficier instantanément de la compatibilité avec les applications GNOME et Enlightenment. Avec la disparition de ce module, les applications devront utiliser exclusivement les connecteurs natifs tels que la libpulse ou libpulse alsa.
Travail sur ORC
The Oil Runtime Compiler est une bibliothèque qui fournit un compilateur à la volée ainsi qu'un langage permettant d'écrire d'une manière générique du code optimisé pour SIMD. ORC est utilisé dans diverses parties de PulseAudio pour améliorer les performances CPU lors des opérations les plus coûteuses, telles le ré-échantillonnage ou le mixage.
Amélioration de la qualité de la lecture sur des périphériques A2DP
Les appareils bluetooth comme les téléphones ou ordinateurs portables peuvent diffuser un flux audio au travers du protocole A2DP. Une amélioration de la qualité de diffusion est à noter grâce au travail effectué.
Amélioration de la qualité du module de suppression d'écho
Cette fonctionnalité est notamment utilisée lors de la lecture sur un périphérique d'entrée tel qu'un micro lors d'une conversation vocale. PulseAudio a amélioré la suppression d’écho grâce à une fonctionnalité de la bibliothèque WebRTC AudioProcessing, qui est une nouvelle dépendance de la version 2.0.
Détection des prises jack utilisées
PulseAudio avec un noyau linux récent peut maintenant détecter les matériels (micros, écouteurs enceintes…) connectés sur les prises jack d'un périphérique. Cela permet une meilleure sélection automatique des canaux des cartes sons à utiliser par défaut, ou encore par exemple le changement de canal si une nouvelle paire d'écouteurs est branchée. En outre, les niveaux peuvent désormais être réglés séparément pour chacune des sorties jack. À l'avenir, il est prévu de permettre de configurer simplement des sorties multi-canaux.
Meilleure sélection du taux d’échantillonnage
Jusqu’à présent PulseAudio initialisait chaque périphérique audio en utilisant un taux d’échantillonnage fixe (en général 44100 Hz ou 48000 Hz) puis ré-échantillonnait tous les flux qui ne correspondaient pas à ce taux. Dorénavant, PulseAudio pourra changer dynamiquement le taux d’échantillonnage d'un périphérique si celui-ci le gère, pour mieux correspondre aux taux des différents fluxs joués, évitant ou réduisant ainsi les opérations de ré-échantillonnage auparavant nécessaires. Cette fonction devrait apporter des économies d'énergie et de cycles CPU.
- La prise en charge du noyau HURD fonctionne à nouveau
- Gestion des sorties audio Surround virtuelles
- Gestion des sorties audio Xen para-virtualisées
Changement dans le cycle des sorties
Après plusieurs années de versions 0.9.xx au rythme de parution très irrégulier, la version 1.0 de PulseAudio a été publiée en septembre 2011, suivie un mois plus tard par la version 1.1. À cette occasion le format de numérotation des versions a évolué. Elles sont désormais numérotées X.Y, où X est incrémenté pour une version apportant des changements significatifs, et Y pour des correctifs. En outre, il a été décidé de produire des versions majeures à un rythme plus régulier, avec un objectif de 4 mois (le cycle de la 2.0 a duré 6 mois), pour satisfaire les distributions qui utilisent maintenant massivement PulseAudio.
Changements à venir
- Ré-échantillonnage avec SSE3
- Plus de fonctionnalités basées sur la détection des prises Jack
Aller plus loin
- À propos de PulseAudio (181 clics)
- PulseAudio sur Wikipédia (319 clics)
- "When PulseAudio and when not" une reflexion sur PA vs Jack par Lennart Poettering (141 clics)
- "Conception of PulseAudio" Un fils de discussion sur la vision du projet par le public (114 clics)
- L'annonce de la version 2.0 (105 clics)
# Sommaire
Posté par le_poney (Mastodon) . Évalué à 2.
Merci, pour ces petites infos sur PulseAudio.
Sinon il me semble que le Sommaire est en double…
[^] # Re: Sommaire
Posté par claudex . Évalué à 4.
Corrigé, merci.
« 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
# A2DP
Posté par JoeltheLion (site web personnel) . Évalué à 8.
Merci pour cette news très instructive!
Concernant A2DP, je ne sais pas exactement ce qui a changé, mais j'avais dès problèmes pour connecter mon portable à ma chaîne hifi (son faux après un moment, son haché par moment), et ce n'est plus le cas! \o/ !
[^] # Re: A2DP
Posté par FluffyHamster . Évalué à 5.
Oui il y a eu du travail de fait sur le système de timing pour la lecture par bluetooth, et il devrait encore y en avoir dans les prochaines versions.
# typo
Posté par Xavier Verne (site web personnel) . Évalué à 5.
Typo. si celui si -> si celui-ci
Belle news, j'aime bien quand il y a un schéma d'architecture. On comprend tellement mieux.
Existe-t-il un schéma pour l'ensemble de la pile linux Audio ?
[^] # Re: typo
Posté par BAud (site web personnel) . Évalué à 4.
Corrigé, merci.
Pour des schémas, tu as des articles (même si un peu anciens) :
# Le gnou n'est pas mort
Posté par jbbourgoin (site web personnel) . Évalué à 10.
Merci pour cet article très instructif, pour l'excellent schéme, et surtout pour ceci :
Au passage, je tiens juste à dire qu'au jour d'aujourd'hui pulseaudio fonctionne merveilleusement bien sur mes machines, y compris sur celle destinée à la composition musicale et faisant tourner jack.
Je ne pourrais plus m'en passer (ou difficilement)
[^] # Re: Le gnou n'est pas mort
Posté par psychoslave__ (site web personnel) . Évalué à 4.
Aurais-tu des liens vers des documents pour mettre en place une configuration jack/pulseaudio ?
[^] # Jack / pulseaudio
Posté par jihele . Évalué à 2.
http://linuxmao.org/tikiwiki/tiki-index.php?page=PulseAudio#PulseAudio_et_Jack
http://fuzzle.org/~petern/index.html
Je n'ai pas essayé. Un jour j'ai désinstallé PA, et depuis, tant que je n'en ai pas besoin, je laisse comme ça.
[^] # Re: Jack / pulseaudio
Posté par psychoslave__ (site web personnel) . Évalué à 2. Dernière modification le 14 mai 2012 à 10:12.
Bon, je lirais ça cette semaine. Il faut que je me fasse un documentation de fond sur le sujet pour utiliser jack(2?) avec pulseaudio sous archlinux. Hier j’ai découvert patchage. :)
Bref, il faut que je cale un peu tout ce que fait chaque composant, et après je pourrait écrire un peu de doc sur le sujet.
[^] # Re: Le gnou n'est pas mort
Posté par kursus_hc . Évalué à 10.
Au passage je tiens à signaler que cette expression est une abomination.
Pour info "hui" signifie "ce jour", ce qui rend donc déjà le mot "aujourd'hui" légèrement pléonastique (au jour de ce jour).
Mais si l'on rajoute "au jour", comme une partie toujours plus large de la population semble vouloir s'obstiner à faire, on obtient un sacré combo que Jean-Claude Van Damme ne renierait pas : au jour du jour de ce jour.
Voilà, j'espère ne plus jamais revoir ça ici.
[^] # Re: Le gnou n'est pas mort
Posté par djano . Évalué à 4.
On m'a expliqué que cela peut être compris comme "à la lumière d'aujourd'hui".
Mais je suis d'accord, je trouve l'expression sacrément moche. Je préfère largement l'expression ci-dessus.
# Pourquoi PA sux
Posté par fcartegnie . Évalué à -5.
Et quand on aura 16 cores, lennart demandera à virer l'accélération gpu ?
Sux by design:
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html
[^] # Re: Pourquoi PA sux
Posté par Zenitram (site web personnel) . Évalué à 8.
C'est sûr, gagner 0.1% de perfs en plus, ça va déchirer.
Question : qui a encore des cartes-son avec accélération "audio"?
Et ce n'est pas "sux par design", il dit juste qu'il en a rien à foutre. Tu craches sur un truc juste pour dire de cracher, car il n'y a aucun "sux".
Résumons : aux prix de développement que tu n'auras sans doute pas envie de sponsoriser toi-même, il faudrait faire gagner 0.1% de CPU aux rares qui ont encore du fric à dépenser dans un DSP audio alors que les CPU modernes savent très bien faire ça (ils ont leur propre "DSP" : MMX etc). Super… Ah oui, et parce que lui ne compte pas le faire, ça pue par design (sic).
[^] # Re: Pourquoi PA sux
Posté par FluffyHamster . Évalué à 6.
Effectivement, si intérêt il y a eu un jour de faire le mixage audio en hardware, il à complètement disparu aujourd'hui. Faire ça sur le CPU ne coûte rien (mais alors rien du tout) et c'est infiniment plus flexible (et ça ne t'oblige pas à re-coder l'accélération pour chaque carte audio)…
Non, car pour égaler une carte graphique d'aujourd'hui il ne faut pas 16 coeurs mais plutôt 4096. La question ne se pose donc pas. Néanmoins tu évoque le sujet, poursuivons avec le cas du décodage vidéo en hardware.
Avec un i7 2600K, décoder du 1080p à gros bitrate prend moins de 10% d'un seul coeur. Partant de la, mais pourquoi se faire chier à faire fonctionner toute une carte graphique (+250W dans mon cas) à coté du CPU (déjà 100W) pour faire son petit décodage vidéo en hardware ? C'est le même type de problématique que le mixage audio hardware. "Hier" c'étais quasiment obligatoire, "demain" se sera complètement inutile. Ce n'est pas une question de "design" (bien au contraire, déléguer des tâches à du hardware spécifique relève plus du gros hack qu'autre chose), c'est une question de moyens qui évoluent, et de besoins qui restent les mêmes.
[^] # Re: Pourquoi PA sux
Posté par barmic . Évalué à 5.
Tu parle tout de même d'un monstre de puissance. Très loin d'être représentatif et à mon avis le seul cas où tu peux commencer à te poser ce genre de question. Si on prend là où linux est très présent et a besoin de puissance graphique android, l'utilisation d'un circuit dédié au graphique est important, il apporte un gain en puissance brute, en espace mémoire et moins de latence entre les deux.
Donc oui peut être que dans 5 ans les pc de bureaux pourront se poser la question s'ils n'utilisent pas l'accélération 3D, mais pour le reste ça restera nécessaire pour longtemps.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi PA sux
Posté par FluffyHamster . Évalué à 3.
Effectivement, je parle bien d'un CPU haut de gamme.
Et attention je parle de décodage vidéo et pas d'accélération 3D. Tant qu'on fera de la 3D par rasterisation non on ne se passera pas de carte graphique, même dans 5 ans.
[^] # Re: Pourquoi PA sux
Posté par djano . Évalué à 2.
Mais ou est ce que j'ai lu récemment qu'il pouvait être plus intéressant de faire les calculs par le CPU plutôt que par le circuit graphique pour la consommation électrique? Ça intéresse Android, non? La raison étant que le CPU reste allumé quand il attend la carte graphique:
Ah j'ai trouvé sur linuxfr.org: http://linuxfr.org/nodes/90478/comments/1346219
[^] # Re: Pourquoi PA sux
Posté par barmic . Évalué à 8.
Le commentaire que tu met en lien n'est pas si clair que ça je trouve :
Il parle d'un axe de recherche et pas de faits et surtout il parle d'utiliser conjointement CPU et GPU pour diminuer les latences du au bus entre les deux et pour utiliser au mieux le CPU (mais sans abandonner le GPU).
Je pensais que tu allais parler de ça : https://linuxfr.org/users/steckdenis/journaux/en-finir-avec-la-lourdeur-de-kde mais il y a une phrase importante dedans :
Et ça c'est bien sur les CPUs Intel et AMD (peut être aussi sur le Cell), mais sur les ARM ce n'est pas le cas. Au grand désarrois d'Intel android est surtout utilisé sur ARM plutôt que sur x86.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi PA sux
Posté par FluffyHamster . Évalué à 5.
Par instructions multimédia il sous entend MMX / SSEx sur x86, Altivec sur PPC, Neon sur ARM. Toute les familles de CPU ou presque ont leurs jeux d'instructions vectorielles "simd", pas de soucis.
Après les backends de rendus sont souvent plus efficaces sur CPU avec simd pour la plupart des opérations (ex: rendu des polices, génération de petits bouts d'interface, etc). La ou c'est plus rentable sur GPU c'est pour la composition de larges pans d'images, ou pour des choses genre génération de gradients…
J'ai plus les liens mais les gars de chez Qt avaient fait pas mal d'articles très instructifs sur leurs différents backend de rendu et les optimisations qu'ils avaient faits dessus.
[^] # Re: Pourquoi PA sux
Posté par gpe . Évalué à 10.
C'est un peu réducteur, le faire faire par du matériel spécifique peut aussi être important pour l'efficacité énergétique.
Ta carte graphique ne consomme pas 250W quand elle fait du décodage HD. Un décodage fait par du matériel dédié consomme moins que de le faire par un CPU généraliste.
Dire que déléguer des tâches à du matériel spécifique est un gros hack et que c'est mieux de le faire par le CPU c'est quand même osé car les CPU n'ont récupéré ses tâches qu'à partir du moment où ils ont intégré le matériel nécessaire. Le hack est donc toujours présent il a juste changé de place …
Et ça continue dans ce sens avec de plus en plus l'intégration dans les CPU de processeurs graphique et de tout ce qui va bien pour décoder la HD.
[^] # Re: Pourquoi PA sux
Posté par cedric . Évalué à 4.
Ce n'est pas si simple. Lorsque tu communiques avec un processeur externe, tu dois mettre en place un echange de donnee entre les deux processeurs (DMA si memoire separe, remapping memoire sinon). Ca implique dans le cas minimum un flush du cache de ton CPU et une latence importante. L'impact est donc loin d'etre negligeable, c'est la raison de la mort de la majorite des processeurs externes. Si on peut le faire sur le CPU, c'est plus souple et plus efficace.
Pour la video, c'est quelque chose qui se trouve encore a la frontiere et qui merite une analyse au cas par cas. Par contre, pour le mixage audio, c'est juste tellement plus simple, puissant et efficace a faire sur le CPU. A contrario, si tu n'as pas besoin de faire de mixage (exemple seule une application mp3 fonctionne), tu peux deleguer la decompression a un processeur externe, comme une oreillette bluetooth. En tout cas, c'est la theorie, dans la pratique tu as envie de pouvoir reactiver le mixer n'importe quand et ca rend les choses tout de suite plus complique. La vrai vie, c'est jamais simple !
[^] # Re: Pourquoi PA sux
Posté par gpe . Évalué à 1.
Et ? En fait je vois pas lien avec ce que tu dis et ce que je disais …
[^] # Re: Pourquoi PA sux
Posté par Kaane . Évalué à 10.
Effectivement, si intérêt il y a eu un jour de faire le mixage audio en hardware, il à complètement disparu aujourd'hui.
Dans le cadre du PC de madame Michu qui ne fait pas de création musicale même en niveau amateur avancé éventuellement, dans tout ce qui concerne les métiers de l'audio (de l'amateur éclairé au gros studio d'enregistrement), si.
Faire ça sur le CPU ne coûte rien (mais alors rien du tout)
Ca dépend, si tu utilises la méthode R.A.C.H.E en userland avec un coefficiant de latence qui peut varier et une distortion qui peut monter à plus de 0.1% ca coute pas grand chose en effet. On met de gros buffers et roule. Par contre déjà sur un système comme Pulse Audio qui veut jouer avec les redirections et pas avoir de trop gros buffers pour éviter les latences, ca commence à couter cher en termes d'interrupts.
Si tu veux du vrai temps réel multipistes multisources et que tu sors le noyau temps réel avec controle des flux et compensation de drift, la ca commence à piquer niveau ressources.
et c'est infiniment plus flexible
En quoi ? Dans tous les cas tu diriges des flux décodés vers des entrées. J'ai du mal à voir ce que l'accélération hardware empêche de faire.
[^] # Re: Pourquoi PA sux
Posté par FluffyHamster . Évalué à 2.
Car avec un traitement software on passe partout, alors qu'avec un traitement hardware on est limité par l'implémentation du constructeur. Et de ses drivers proprio dans le cas du décodage vidéo.
[^] # Re: Pourquoi PA sux
Posté par Kaane . Évalué à 6.
Car avec un traitement software on passe partout, alors qu'avec un traitement hardware on est limité par l'implémentation du constructeur.
L'acceleration hardware se fait au dernier niveau, à savoir au moment du rendu. Tous les traitements softwares "interressants" sont fait antérieurement. Bien sur il existe la possibilité de rajouter des effets type "echo, distorsion, changement de pitch" en hardware sur certaines cartes sons mais c'est le plus souvent annecdotique (même sur les ensembles très haut de gamme les ingés sons préfère régler le truc à la main plutôt que de le passer par les filtres hardware).
Dans le cas ou tu as les pilotes complets (proprios ou non) tu peux éventuellement te passer d'une étape de décodage du flux (genre une carte son qui prend du MP3 ou du OGG nativement en entrée - L'équivalent d'une carte vidéo qui prend un flux MPEG-2 en entrée directe).
Mais de toutes les façon le mixeur hard (c'est à dire au moment ou on arrive au rendu final sur la machine cible) est forcément un avantage. Il ne coute rien et n'empêche rien.
[^] # Re: Pourquoi PA sux
Posté par Jehan (site web personnel, Mastodon) . Évalué à 1.
Salut,
quand vous parlez de mixage/accélération hardware, est-il question de ces grosses cartes externes que je voyais chez des ingénieurs du son, avec pleins de boutons, switchs et leviers? Le genre de trucs qu'ils vont en général utiliser avec Protools. Je me souviens en particulier de cartes M-audio.
Si on parle bien de cela, considère-t-on leur obsolescence essentiellement dans le monde Linux, ou Windows/OSX également? En d'autres termes, le monde professionnel du son lui-même est-il en train de migrer vers du mixage tout software?
Pourtant en tant que néophyte, je vois bien l'intérêt de travailler avec de vrais leviers pour mixer diverses entrées (l'avantage habituel du physique sur l'immatériel), bien que je conçois bien également la flexibilité du software.
Et si ce changement est vraiment généralisé (et non Linux centré seulement), alors ce sera tout de même marrant d'aller dans des studios d'enregistrement qui auront remplacé les énormes consoles de mixage de 3m de long par un petit boîtier d'où partirait tous les câbles et branché à un ordinateur. En même temps cela ferait un sacré gain de place et faciliterait l'accession au métier aux moins fortunés. De ce point de vue, c'est plutôt bon. Mais je me demande à quel point c'est vrai.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pourquoi PA sux
Posté par Zenitram (site web personnel) . Évalué à 1.
Tu peux avoir les deux : les boutons hardware, et le calcul en software. Comme pour beaucoup de matériel (WiFi, imprimantes…) aujourd'hui, ce qui a un énorme avantage : le coût. Et ce sans te séparer de l'avantage des boutons physiques. "léger" problème par contre pour les libristes : le soft n'est souvent pas compatible Linux (comme pour les imprimantes).
[^] # Re: Pourquoi PA sux
Posté par Kaane . Évalué à 10.
quand vous parlez de mixage/accélération hardware, est-il question de ces grosses cartes externes que je voyais chez des ingénieurs du son, avec pleins de boutons, switchs et leviers? Le genre de trucs qu'ils vont en général utiliser avec Protools. Je me souviens en particulier de cartes M-audio.
L'acceleration hardware du mixage est un comportement que l'on trouve sur certaines cartes moyen et haut de gamme pour particuliers.
Grosso modo sur une carte son sans mix hardware l'interface d'écriture est mono source. En d'autres termes si tu fais cat /home/toto/fichier.wav > /dev/audio ca joue ton fichier. Si en même temps tu fais un cat /home/toto/fichier2.wav > /dev/audio ca va te répondre "device busy".
Par contre si ta carte supporte le mixage hard alors tu pourras envoyer autant de fichiers que tu veux dedans (dans la lmitie du raisonable) et les fichiers seront joués en même temps.
Sauf que si tu utilises Pulse Audio il va forcer un lock exclusif de /dev/audio, obligeant tout le monde à passer par lui. Donc non seulement il ne prend pas en charge le mixing hard, mais en plus il le saborde pour les autres applications qui ne veulent pas/ne peuvent pas utiliser PA.
Les cartes M-Audio (ou autres consoles pro) sont chères non pas à cause du mix hard (qui n'est finalement pas très couteux à implémenter) mais surtout parce qu'elles ont un coefficiant de distorsion très faible et des horloges extrèmement précises. C'est ce qui permet de bosser pendant des heures sur un fichier son sans se demander à la fin de la prod si le début de la bande son a pas drifté d'une demi seconde.
En d'autres termes, le monde professionnel du son lui-même est-il en train de migrer vers du mixage tout software?
Même pas en rêve. Le mixage soft à la Pulse Audio pose de vrais problèmes de calage. Pour chaque source jouée on va avoir un triple context switch (utilisateur -> daemon PA -> Alsa), en mixage hardware si on se démerde bien , on a un seul context switch par utilisateur sur la console. A défaut on peut facilement limiter le nombre de context switch. Tu imagines bien que quand tu fais un assemblages de plus de 50 sources (Musique + 3 sources voix + 2 sources bruitages + effets sur certaines sources +….) et que tu veux une précision au centième de seconde (l'oreille humaine est d'une précision monstrueuse, elle réagit a des éccarts de l'ordre du cinquantième de seconde) sur deux heures de bande son redirigée vers des sorties 7.1 voire 9.1 aujourd'hui - l'idée de te frapper 3 context switch par source ne te fait pas rire du tout.
Donc les pro utilisent des mixer hardware avec des horloges ultra-précises et des composants a très faible distorsion.
[^] # Re: Pourquoi PA sux
Posté par Zarmakuizz (site web personnel) . Évalué à 1.
/dev/audio ça existe encore ?
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Pourquoi PA sux
Posté par Kaane . Évalué à 5.
/dev/audio ça existe encore ?
C'était principalement pour que tout le monde comprenne de quoi on parle. Maintenant avec udev tu lui donne le nom que tu veux, en sachant que le choix majoritaire (/dev/dsp) ne veut pas dire grand chose. A la limite /dev/pcmin ou /dev/sndin ca pourrait se comprendre, même /dev/dac dans une certaine mesure, mais /dev/dsp ca a autant de sens que /dev/dma ou /dev/interface…
[^] # Re: Pourquoi PA sux
Posté par jihele . Évalué à 4.
Ces grosses cartes doivent être des cartes son (ou interfaces audionumériques). Elles servent à connecter des instruments à l'ordi. Pour enregistrer le moindre truc, il est vite nécessaire de passer sur un carte dite pro ou semi-pro, sans quoi le son est franchement à chier. Il suffit d'essayer de brancher une guitare sur une carte son de base pour le constater.
Parmi les fonctionnalités de ces cartes (elles n'ont pas forcément tout ça) :
Attention aux problèmes de pilotes !
Ces interfaces existent en PCI, USB et FireWire.
http://linuxmao.org/tikiwiki/tiki-index.php?page=Cartes+son
http://linuxmao.org/tikiwiki/tiki-index.php?page=Cartes+son+des+membres
En USB, il me semble qu'on est un peu limité parce qu'alsa ne gère que l'USB1. J'ai lu sur un forum que c'est parce qu'USB2 est mal spécifié et chaque constructeur fait à sa sauce, mais je n'ai pas de source.
En FireWire, il le pilote libre ffado, c'est un projet bénévole. Beaucoup de cartes ne fonctionnent pas ou pas complètement, ça dépend en partie des cartes à disposition des développeurs, des efforts fournis par les fabricants (specs, don de matos, peut-être) :
http://ffado.org/?q=devicesupport/list
ffado ne fonctionne qu'avec jack, donc si on utilise cette carte en carte son principale, il faut tout router vers jack.
[^] # Re: Pourquoi PA sux
Posté par deasy . Évalué à 7.
Ton exemple de comparaison cpu et gpu pour le décodage h264/vc1 est mauvais.
Prends un wattmètre tu verra que ta carte vidéo fait que ton pc consomme moins dans sa globalité en décodage hardware qu'en software sur cpu.
Les circuits spécialisés sur la carte vidéo consomment moins qu'un coeur à ?%
Tu parles de 10% d'un coeur ou de 10% du cpu complet? car 10% d'un quad ça fait presque la moitié d'un core.
Dans tout les cas, ta machine consomme moins en décodage hardware qu'en soft, wattmètre à l'appui.
[^] # Re: Pourquoi PA sux
Posté par xcomcmdr . Évalué à 3.
Exactement !
Décodage par la CG nVidia chez moi de 1080p qui tâche : utilisation CPU à moins de 10%, ça chauffe peu (et c'est infiniment mieux pour la batterie du portable), c'est fluide, stable..
Décodage par le CPU : Ça ne tourne pas ou mal (Core 2 Duo T5800) parfois, dans tous les cas ça prend 100% ou presque des deux cores, ça chauffe grave, et la batterie est morte en 10 minutes, il y a des bugs graphiques, revenir en arrière est lent, …
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi PA sux
Posté par deasy . Évalué à 2. Dernière modification le 13 mai 2012 à 12:11.
Je pense que ça doit passer en soft aussi sur ton cpu avec un bon lecteur(mplayer par exemple).
Un core 2 à 2Ghz c'est pas si vieux quand même.
La principale diffèrence entre soft et hard c'est que tu as moins de fonctions de filtre en hardware.
ps: errata j'oubliais que sur Linux un core c'est 100% donc 10% sur un quad c'est 10% d'un core et 400% c'est 4 cores à 100%
[^] # Re: Pourquoi PA sux
Posté par FluffyHamster . Évalué à 2.
Les résultats sont cohérents, j'ai un laptop avec un core i5 2x2.2Ghz, je peut effectivement le monter à 100% d'un coeur sur du "gros" 1080p. Et la au revoir la fluidité de la vidéo.
L'astuce pour moi dans ce cas est d'utiliser une version de mplayer et de ffmpeg bien à jour et d'activer le décodage sur plusieurs coeurs.
[^] # Re: Pourquoi PA sux
Posté par FluffyHamster . Évalué à 4.
Détrompe toi, les décodeurs vidéo matérielles des cartes graphiques sont conçus pour être plus performants que les CPU, les économies d'énergies sont un objectif secondaire. Alors j'ai mon wattmètre mais pas mon gros PC pour vérifier ça malheureusement. Je pense que suivant les combos CPU/GPU les résultats vont être variables.
Le seul bench que j'ai pu retrouver donne ça sur un portable :
http://www.phoronix.com/scan.php?page=article&item=nvidia_vdpau_mobile&num=2
Et encore c'est sur un cas particulier : le CPU et le GPU consomment globalement la même chose en charge (un intel atom et un nvidia ion), et voila pourquoi il est plus efficace de faire tourner 50% du GPU que 100% du CPU dans ce cas.
Avec mon PC j'ai bien 10% d'utilisation sur un seul coeur. Et faire 10% sur un coeur (i7 2600K, TDP max de 95W, et qui diminue très bien sa conso quand il n'est pas en charge, les derniers CPU Intel sont véritablement bon à ce niveau la) je maintiens que c'est plus efficace que de mettre la moitié de sa carte graphique en route (gtx 570, TDP max 225W), qui elle n'est vraiment pas aussi efficace niveau énergie…
[^] # Re: Pourquoi PA sux
Posté par deasy . Évalué à 1.
Ta carte vidéo ne consommera pratiquement rien en plus au contraire du réveil du cpu qui lui est couteux en consommation.
Parce que c'est un circuit dédié à ça.
En tout cas c'est ce que je constate avec un wattmètre et un logiciel qui m'indique l'utilisation de mon gpu.
[^] # Re: Pourquoi PA sux
Posté par Zenitram (site web personnel) . Évalué à 5.
Le problème est sans doute dû à ta carte graphique qui balance 50% d’énergie pour tout démarrer alors qu'on lui demande que de décoder une vidéo. Ce n'est pas adapté.
Si ta carte graphique était adaptée, ça serait comme sur les mobiles / tablettes, décoder une vidéo 1080p ne prend que quelques Watts, bien moins que ton CPU.
Bref : avec ton matos, oui ça vaut peut-être mieux de décoder par CPU, mais c'est la faute de la non optimisation de ta carte graphique, pas du principe.
Pour revenir à l'idée initiale de virer le GPU un jour quand le CPU sera puissant, ben oui : rien ne sert d'avoir un GPU qui fasse du décodage HDTV si ton CPU fait la même chose à 1% de taux CPU. Le jour où on en sera à 1% de CPU pour décoder, le prix d'une puce additionnelle pour ça sera inutile (comme le son les super-cartes son à 200€ qui étaient utiles à une époque mais plus maintenant, car même sur la puce a baissé, ça reste une dépense inutile vu que le CPU ne voit même pas la charge en plus).
Et dans 10 ans, décoder de la vidéo sera peut-être aussi facile que faire du muxing son (inférieur à 1% de CPU qui glandera). Peut-être, car pour le moment on monte en gamme de qualité en vidéo, l'idée étant de monter à 7680x4320 3D, à 48 fps, sans chroma subsampling, à 12 bits par pixel au lieu de 8 actuels, avec un codec AVC + extensions ou JPEG-2000 qui bouffent, et sur ça, ton CPU souffre un max, j'ai des vidéos en stock où ton i7 2600K morfle à fond.
Alors que pour le son, même en 96 KHz 24-bit 7.1 (et pour la maison, il n'est pas prévu d'aller au delà même pour le haut de gamme, le 22.2, c'est que pour le ciné, t'imagine mettre 24 enceintes chez toi? ;-) ), ton CPU glande aujourd'hui, les exemples de besoin de puce pour l'audio ne sont pas un besoin généralisable à plus de 0.1% de la population d'utilisateurs (eux ont besoin de matos, je ne remet pas ça en cause. Mais la, pas de PA, c'est de l'OS dédié et tout le bordel).
[^] # Re: Pourquoi PA sux
Posté par FluffyHamster . Évalué à 5.
Oui on est bien d'accords.
Et c'est pour ca que j'ai écrit avec un ton volontairement polémique ""Hier" c'étais quasiment obligatoire, "demain" se sera complètement inutile."
Quand on en viendra à ce niveau de qualité, le problème qui se posera je pense sera plus "bordel j'ai 10 go de vidéo compressée pour 10 minutes de film" que "ha oui sa occupe bien mon CPU".
Et d'ailleurs si on monte à se niveau de qualité, il sera temps d’arrêter (enfin de diminuer, car sinon nos disques durs vont prendre cher) avec les algos de compressions de fou qui détruisent la qualité qu'on essai de gagner ^
Je suis toujours intéressé par des samples comme ça. Par contre, c'est précisément dans se genre de cas ou on tombe de toute manière sur les limites des décodeurs hardwares, qui sont prévus pour fonctionner uniquement sur les profils les plus courants. J'ai un sample mpeg2 à 70mbps avec un mode d'entrelacement pas commode, 400mo pour moins d'une minute, et bien il ne passe que en lecture software de toute manière !
Et c'est également pour ça que je dis que les décodeurs softwares sont plus flexibles.
Effectivement, les seuls personnes qui ont déjà vu leur CPU passer plus de 10% du temps sur du traitement sonore (hors décompressions qui ne sont de toute manière pas gérées en hardware) sont soit devant un bug, sois devant un cas d'utilisation très particulier.
[^] # Re: Pourquoi PA sux
Posté par Zenitram (site web personnel) . Évalué à 4.
A ce moment-la, les disques durs auront aussi fait un x100 sur la taille, un disque de 200 TB sera la norme, ton fichier sera petit en comparaison.
10 Go pour 10 minutes? J'en ai déjà :), ça devient la norme chez les broadcasters.
Tu vois des gros pixels baveux sur les Blu-ray? A part les codeurs du dimanche, les algo sont très très bons avec le bitrate adéquat. AVC est très bon. HEVC qui arrive encore plus (mais tu vas payer cher en CPU). Ca va de ce côté la.
Petit cadeau : Sintel_1mn_4K_24_fps_5.1_channels_DCP_SMPTE (500 GB)
Par contre, bon courage pour trouver un lecteur libre qui le lise bien.
Désolé, j'ai aussi des AVC-Intra 100 (1080p, mais en 4:2:2 10 bits) ou du 7680x4320 mais NDA dessus :( (et pour le reste, j'ai dit que c'était la cible, pas que j'en avais :) )
(et 100 Mbps, c'est pour les petits joueurs, je viens de voir une spec SMPTE qui norme une version à 200 Mbps! Ouch… Mais bon, ça ne fait que 200 GB par film;-) )
MPEG-2, trop facile pour ton CPU! :)
Et oui, les decodeurs hardware sont fait pour les profiles de base de MPEG-2, au bitrate plus bas, donc ne lisent pas ça. Comme les décodeurs hardware bloque si tu fait plus que la norme Blu-ray (High@L5.0, faut pas aller plus loin)
Oui, mais il faut reconnaître que pour le moment, il y a a pas grand chose en grand public qui ne passe pas sur les decodeurs avec le "standard de facto" AVC High@L5.0. C'est le prix à payer pour la diffusion (prix de la puce). Ca viendra, ça viendra, avec le temps.
Bref, aujourd'hui on en encore de la marge pour le décodage vidéo, mais nos enfants rigoleront quand on leur dira qu'on faisait du decoding hardware de video comme on rigole quand on parle de puce dédiée audio aujourd'hui alors que nos parents claquaient du fric dans une puce dédiée.
Désolé pour la digression.
[^] # Re: Pourquoi PA sux
Posté par FluffyHamster . Évalué à 3.
Oui mais non, les Blu-ray sont encodés avec des ratios de compressions qui ne sont pas du tout impressionnants (normal quand ils ont 50go de dispo pour la cible) avec des facteurs de quantifications bien trop élevés pour ce que c'est. Ils feraient mieux de passer au 12bpc sans subsampling par exemple, mais après la limitation viendrait plus des dalles lcd je suppose.
Effectivement à la lecture du draft ça va tabasser sévère. Mais reste que pour plus de compression on grignote toujours plus sur la qualité.
Merci pour le sample ! Ça fait cher la minute quand même ^
[^] # Re: Pourquoi PA sux
Posté par Zenitram (site web personnel) . Évalué à 4.
Oui mais non : les Blu-ray sont encodés avec des ratios de compression qui sont exactement ce qui est prévu par ceux qui font les specs. Après tu a les gamin qui essayent de faire rentrer la chose dans 10x moins de place tout en restant en 1080p, c'est (pas trop) moche mais on passe alors à un niveau de qualité qui n'est compatible avec ce que veulent les diffuseurs. Justement donc : les Blu-ray sont exactement le niveau "pas baveux" prévu lorsque les mecs ils créent AVC! HEVC est prévu aussi pour améliorer la qualité à débit identique, ou… Plus haut. C'est exactement le but d'AVC : que tu ne le vois pas!
80 Mbps, "classique" ;-). C'est du JPEG-2000, que des images indépendantes, alors forcément ça monte en débit :). C'est la norme Cinema 4K, ce que tu pourrais voir sur un écran de ciné "correct" (qui est passé au 4K plutôt que cette horreur de 2K qui a plus sa place sur un projo de maison).
[^] # Re: Pourquoi PA sux
Posté par deasy . Évalué à 2.
Euh…grignoter sur la qualité?
h264 > mpeg2/mpeg4 asp(xvid/divx) et largement!
On grignote pas!
[^] # Re: Pourquoi PA sux
Posté par FluffyHamster . Évalué à 3.
Je pensais plus de h264 à h265. Les gains en qualité deviennent moins évidents qu'entre les précédentes générations de codecs, pour toujours plus de complexité ajoutée dans les encodeurs et décodeurs. Pour continuer à gagner en qualité on utilise encore plus de modes d'intra-prédictions, plus d'usage de compensation de mouvement et avec des interpolations de meilleure qualité, et on fait jouer des optimisations psycho-visuelles comme le sous-échantillonnage des couleurs (qui reste la base, utilisé depuis plus de 60 ans) qui permet de stocker 4x moins d'informations de couleurs pour une qualité ressentie "identique" pour un oeil humain.
La différence de qualité "ressenti" est donc bien meilleure avec les codecs plus récents, mais la perte d'informations par rapport à la source est toujours la.
[^] # Re: Pourquoi PA sux
Posté par Zenitram (site web personnel) . Évalué à 1.
Et tu veux faire comment? Stocker les images sans pertes? Alors la c'est une taille gigantesque, pour un intérêt des plus discutables… Tu n'as toujours pas dit que c'était une perte gênante quand tu regardes un Blu-ray (ou quand tu vas au ciné, c'est du JPEG-2000 avec des pertes aussi).
Je ne vois pas où tu veux en venir avec cette remarque : quel est le problème?
[^] # Re: Pourquoi PA sux
Posté par FluffyHamster . Évalué à 1.
Moi non plus enfaîte… Ça fait déjà un moment qu'on dérive :-) C'étais pour faire avancez le schimlibi, le shimiliibilik !
[^] # Re: Pourquoi PA sux
Posté par M . Évalué à 4.
Tout dépend comment tu fais ton mixage. Si les sources que tu mixes sont pas tout a fait synchrone et ben il va falloir faire de la conpensation de glissement. Idem si les sources ne sont pas au même échantillonnage/format (8bits, 16bits, flotant)
Si tu es dans le cas d'une appli téléphonique tu vas vouloir aussi faire de l'anulation d'echo.
Et tout ça, ça bouffe énormément de cpu, d'autant plus que certains algo (anulation de bruit) on besoin d'un aspect temps réel.
Enfin les cartes "bas de gamme" ont aussi un dac/adc d'assez mauvaise qualité.
Donc oui sur le pc de madame michu ça n'a peu d’intérêt (tout comme d'avoir une carte graphique de la mort), mais dans d'autre cas c'est indispensable.
[^] # Re: Pourquoi PA sux
Posté par reno . Évalué à 3.
Moi: SoundBlaster Live, je suis quasiment sûr qu'elle fait du mixing HW.
Mais après sous Linux, l'utilisation de l'accélération matérielle pour le son ou pour la vidéo, je sais qu'il ne faut pas trop compter dessus..
[^] # Re: Pourquoi PA sux
Posté par fcartegnie . Évalué à 3.
Voilà pourquoi il faut pas laisser un sujet dériver sans surveillance…
L'intérêt n'est pas d'une "accélaration", mais de la prise en charge par le matériel.
J'ai pris l'exemple de la carte graphique, car tout le monde peut comprendre que le bénéfice ne se fait par qu'au niveau utilisation cpu, comme lui le mentionne pour les dsp audio.
Comme mentionné par quelqu'un au dessus, le dsp permet de se décharger de choses (mix, conversion 7.1, encodage, effets, codecs, …) qui doivent être faites en espace utilisateur, qu'elles soient simple ou lourdes. Et le code le supportant est déjà dans le driver linux.
D'ailleurs, ce qui ont un mix hardware n'ont jamais eu de conflit audio sous linux, tandis que les autres ont du jouer avec le dmix d'alsa, soit ce que propose PA.
Il mentionne un atout pour l'embedded (or là le cpu est justement important…), mais lui propose d'avoir un daemon audio, avec un thread, des buffers supplémentaires par source,
alors que le support hw ne nécessite qu'une écriture ( et fournit le support des écritures //) dans /dev/dsp…
[^] # Re: Pourquoi PA sux
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Personne. On préfère faire du passthru vers l'ampli qui lui fait du décodage hard.
[^] # Re: Pourquoi PA sux
Posté par moi1392 . Évalué à 2.
je suis 100% d'accord, c'était juste pour faire remarquer que moi, j'ai "encore" une carte son qui fait le mixage en matériel. Une sb live 5.1 achetée en 2001 !
Et ce, sans avoir de fric à dépenser dans un DSP audio, bien au contraire ;)
Autrefois, la matériel était plus robuste !
[^] # Re: Pourquoi PA sux
Posté par ben51 . Évalué à 1.
Vous entendais quoi par accélération par carte son ?
Décodage hard, en gros tout ce qui concerne la lecture d'un fichier audio (comme pour le décodage d'une vidéo par un gpu).
Ou génération de scène audio, calcule de rendu (par exemple avec openal).
# Enfin pour les portables ?
Posté par Arthur Accroc . Évalué à 6.
C’est-à-dire pas sur un portable sur batterie.
C’est bien ce que je soupçonnais à l’avoir vu bouffer 10 % de temps CPU sur mon portable pour jouer un pauvre MP3 tout seul, avec les conséquences évidentes sur l’autonomie (… jusqu’à ce que je le vire, donc pas longtemps dans les faits).
Ce point clarifié, on peut donc conclure que PulseAudio était inadapté à une utilisation sur portable et que les distributions grand public qui l’imposaient jusque là y compris dans le cas d’une installation sur portable faisaient n’importe quoi. Et qu’on ne vienne pas me dire que les portables, c’est une niche.
Bonne nouvelle pour les utilisateurs de portables, surtout pour ceux qui n’ont pas le niveau technique pour éviter les distributions grand public ni contourner leurs conneries (c’est triste que ce soit nécessaire). Il leur restera l’environnement graphique et le lecteur vidéo Flash pour leur consommer inutilement des ressources…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Enfin pour les portables ?
Posté par deasy . Évalué à 7.
Pour avoir parlé avec certains prochent du projet, la consommation du cpu dont tu parles est anormale selon eux.
===> rapport de bogue.
D'ailleurs cela a déjà été dit, Pulse audio a permis de chasser des bogues dans certains pilotes.
[^] # Re: Enfin pour les portables ?
Posté par Zenitram (site web personnel) . Évalué à 0.
N'importe quoi.
Pour expliciter un peu : un utilisateur de PC de bureau n'est pas forcément un amateur de facture EDF pour le plaisir, certes à moindre degré mais bref : consommer n'est pas le but.
Ne fait pas d'un bug chez toi une généralité. Ré-échantillonner ne consomme pas grand chose même sur PC portable.
Non. On gagne sur un truc, ben oui. Mais ça marchait bien avant aussi. La prochaine fois que le noyau gagnera un peu de temps CPU car il faisait un truc inutile pas vu avant, tu va dire que le noyau n'était pas adapté pour les portables?
[^] # Re: Enfin pour les portables ?
Posté par 태 (site web personnel) . Évalué à 7.
Ré-échantilloner ne coûte pas grand chose sur mon PC portable, par contre sur mon fixe (atom), j'avais le CPU à 100% et pas de son relativement souvent avant de modifier l'option "resample-method".
Le cas n'est pas isolé vu que toutes les distribs ont un bug ou un forum qui en parle, par exemple https://bbs.archlinux.org/viewtopic.php?pid=905450#p905450 ou https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/207135 ou http://forums.debian.net/viewtopic.php?f=16&t=12497&sid=e4c21db528c1bbc1465645531fdef55d#p115509
[^] # Re: Enfin pour les portables ?
Posté par Troy McClure (site web personnel) . Évalué à 8.
reechantillonner, meme sur un atom tout moisi, ça ne devrait pas couter plus de, soyons large:
44100 samples/sec * 64 cycles/sample * 2 channel / 1.6GHz = 0.35% de cpu , et ce avec un algo qualité extreme pas rapide (64 cycles/sample ça permet de faire plein de choses)
[^] # Re: Enfin pour les portables ?
Posté par Batchyx . Évalué à 4.
Sur les rapports de bugs que tu cite, il y a surtout des cas ou pulseaudio prend plus de 10% de CPU lorsque aucun son n'est joué. Ça m'est déjà arrivé aussi, mais j'ai pas réfléchi plus loin que de jarter pulseaudio, c'est pas comme s'il allais servir à quelque chose sur un PC de boulot sans haut-parleurs.
[^] # Re: Enfin pour les portables ?
Posté par Albert_ . Évalué à 3.
Amusant, auncun bug report pour RH/Fedora…
C'est ca qui me gene beaucoup avec PA. C'est tellement chiant a compiler/configurer que seul une distribution arrive a le faire correctement et curieusement c'est celle de l'auteur…
[^] # Re: Enfin pour les portables ?
Posté par claudex . Évalué à 2.
Personnellement, ça me rassure, ça veut au moins dire que l'auteur passe du temps (ou a réussi à former des gens pour passer du temps) pour l'intégration du bouzin. Que ça ne marche pas pour Fedora m’inquiéterait plus.
« 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: Enfin pour les portables ?
Posté par zebra3 . Évalué à 1.
C'est surtout la preuve que c'est possible, et que certaines distributions font mal leur boulot. Mais ça vient de Pottering donc c'est la faute de PA.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Enfin pour les portables ?
Posté par Albert_ . Évalué à 2.
s/certaines distribution/toutes les autres distributions/
Cela aide peut etre tres legerement que ce soit Pottering lui meme qui s'occupe de ca sur Fedora non?
Enfin bon moi je veux bien que les devs de Ubuntu soit des glandus mais que ceux de debian et d'archlinux le soit aussi cela me semble un peu curieux.
[^] # Re: Enfin pour les portables ?
Posté par claudex . Évalué à 3.
Il faut voir si c'est parce qu'ils sont des glandus ou parce qu'ils ne sont pas intéressés de corriger les problèmes.
« 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: Enfin pour les portables ?
Posté par Albert_ . Évalué à 2.
Il faut voir si c'est parce qu'ils sont des glandus ou parce qu'ils ne sont pas intéressés de corriger les problèmes.
Vu comment les packageurs debianistes sont perfectionnistes j'ai comme un doute et un logiciel qui est tellement difficile a installer/configurer me pose probleme. Ca me rappelle beaucoup trop les tactiques de certaines boites…
[^] # Re: Enfin pour les portables ?
Posté par kursus_hc . Évalué à 3.
Je ne vois pas en quoi PA est difficile à installer/configurer sous debian. Tu as réessayé depuis 3 ans ? Tu installes, tu redémarres, et ça marche. Quel est ton problème au juste ?
[^] # Re: Enfin pour les portables ?
Posté par brendel . Évalué à 0.
Ben déjà il y a un problème si il faut redémarrer la machine pour lancer pulseaudio…
[^] # Re: Enfin pour les portables ?
Posté par zebra3 . Évalué à 4.
Pas besoin de redémarrer, c'est plus pour simplifier qu'autre chose.
Tu installes, tu fermes puis ouvre ta session, et ça marche. PA est appelé à l'ouverture par le démon GNOME. Ou alors tu l'appelles manuellement par la commande « pulseaudio -d ».
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Enfin pour les portables ?
Posté par zebra3 . Évalué à 1.
Pour Arch, je ne sais pas, mais j'utilise PA sur Debian depuis un bon moment (quelques années) et je n'ai pas le moindre souci.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Enfin pour les portables ?
Posté par Albert_ . Évalué à 2.
Regarde au dessus, c'est pas moi qui le dit mais il semblerai que cela ne soit pas exempte de bug.
[^] # Re: Enfin pour les portables ?
Posté par zebra3 . Évalué à 1.
Ben oui, tous les logiciels ont des bugs.
Tout ce que je vois, c'est que ça marche sur de nombreuses machines (au moins mes portables, les PC de mes parents, celui du boulot, etc). En fait, j'ai jamais vu un PC où PA ne fonctionne pas ou fait tourner le CPU à fond.
Donc oui, il y a des bugs, sûrement, mais de là à généraliser à tout le monde et dire que c'est inutilisable, c'est excessif.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Enfin pour les portables ?
Posté par Albert_ . Évalué à 2.
Heureusement que c'est utilisable mais la plupart des nouvelles fonctionnalites fonctionne comme il faut sous Fedora/RH et il faut 1 an aux autres distribs, avec un peu de chance, pour arriver a les mettre comme il faut. Ca te gene pas tant mieux. Moi ca me gene. Et c'est curieux comme ce genre de truc arrive souvent avec les logiciels RH et systematiquement avec les logiciels Pottering…
[^] # Re: Enfin pour les portables ?
Posté par 태 (site web personnel) . Évalué à 3. Dernière modification le 14 mai 2012 à 15:55.
C'est juste que je n'en ai pas cité :
https://bugzilla.redhat.com/show_bug.cgi?id=474487
Réponse de Lennart Poettering :
Donc le resampling ça consomme effectivement du CPU.
[^] # Re: Enfin pour les portables ?
Posté par Troy McClure (site web personnel) . Évalué à 2.
Cf mon calcul au-dessus, si ça bouffe plus de quelques pourcent de cpu alors quelque chose est vraiment très mal fait. Mais bon pour en savoir plus sur quelle zone du code consomme autant de cpu il suffirait d'une bete stacktrace..
[^] # Re: Enfin pour les portables ?
Posté par Kaane . Évalué à 2.
Cf mon calcul au-dessus, si ça bouffe plus de quelques pourcent de cpu alors quelque chose est vraiment très mal fait.
C'est l'idée même d'un mixer centralisé en userland avec un compte de daemon à part du compte utilisateur actif qui est absurde. Il s'agit d'un bricolage (il y a des gens qui bricolent bien) qui cherche à compenser l'incapacité chronique d'Alsa à fournir une API cohérente et uen doc fiable.
Mais bon pour en savoir plus sur quelle zone du code consomme autant de cpu il suffirait d'une bete stacktrace..
stacktrace ne verrait pas grand chose, en soit Pulse Audio est bien codé, mais il déclenche des context-switch par paquets. Faire un resample propre en se calant sur l'horloge système tout en lisant les infos venant d'un flux utilisateur, le tout avec des buffers pas trop délirants pour que le son continue pas pendant 2 secondes quand l'utilisateur appuie sur stop ca nécessite des vas et viens constant userland/userland et userland/kernelspace.
Et là, ça pique.
[^] # Re: Enfin pour les portables ?
Posté par FluffyHamster . Évalué à 2.
PulseAudio lance un processus par utilisateur, le mode daemon est déprécié depuis longtemps. Donc c'est bon pour toi ?
Alors peut être, mais moi tout se que je vois c'est qu'il demande moins de réveil processeur que Alsa pour la même chose = plus efficace que ce que l'on avait avant.
[^] # Re: Enfin pour les portables ?
Posté par Kaane . Évalué à 3.
PulseAudio lance un processus par utilisateur, le mode daemon est déprécié depuis longtemps. Donc c'est bon pour toi ?
PulseAudio peut encore se lancer en mode multi-utilisateur, ce qui permet par exemple de lancer de la musique sur le réseau tou en laissant un autre utilisateur profiter du son de la machine locale. Ce mode qui est le plus complet et le plus flexible reste très problématique. Je n'ai pas vu qu'il était deprecated.(option --system)
Ensuite il y a le mode mono-utilisateur, avec lock exclusif de la carte son, qui semble prendre l'ascendant. Bien sur si vous avez plusieurs utilisateurs au sein de votre session c'est dommage, il n'y en a qu'un seul qui aura le son. Mais de toute les façons dans la plupart des distribs PulseAudio est set-uid root, ce qui implique des context switch même en mode mono utilisateur. (N.B si vous enlevez le setuid root, le son devient dégueulasse sur un paquet de machines ou en cas de forte charge)
Dans tous les cas Pulse Audio se lance en mode daemon (i.e détaché de la console d'origine)
Alors peut être, mais moi tout se que je vois c'est qu'il demande moins de réveil processeur que Alsa pour la même chose = plus efficace que ce que l'on avait avant.
Euh… Personellement sur ma carte sans mixer hard, en utilisation standard (3 source simultanées couramment) ma config dmix bouffe que dalle en CPU sur un pentium E5300 (moins de 1%), la même en pulse-audio me coutait près de 12% de CPU… (Donc au revoir pulseaudio, c'est normal).
Sur ma config avec mixer hardware, le out Alsa est 0.
Comme au final Pulse-Audio finit toujours par renvoyer les infos à Alsa (éventuellement à un Alsa distant) il ne peut que couter plus cher qu'une config Alsa pure.
[^] # Mea culpa
Posté par Arthur Accroc . Évalué à 3.
J’admets, s’agissant d’un truc dont je n’avais pas l’utilité, j’ai trouvé plus simple de le jeter que de remplir des rapports de bugs.
Dans la réalité, sur mon fixe du boulot sur lequel j’utilise Fedora depuis assez longtemps, PulseAudio partait de temps en temps en sucette avec 100 % de temps CPU et pas un son qui sortait.
Au changement de version, je lui ai quelquefois laissé le bénéfice du doute trop peu de temps pour voir s’il le faisait toujours, parce que déjà, le son était complètement haché en cas de forte charge (alors qu’avec Alsa tout seul, nickel), le clou étant quand il compressait le son semble-t-il pour rattraper le retard : abominable !
Par rapport à ça, du son généralement correct avec 10 % de temps CPU sur mon portable, ça me semblait le fonctionnement normal (cela dit, comme ça me semblait gênant en consommation, je ne l’ai pas laissé assez longtemps pour assurer qu’il fonctionnait parfaitement)…
Sur la Fedora 15 que j’ai remise en dernier sur mon fixe du boulot, je n’ai pas encore rencontré de problème avec PulseAudio (écouter du son n’est pas mon activité principale non plus), peut-être fonctionne-t-il enfin correctement, plusieurs versions de Fedora après son introduction ; mais il est possible aussi que ce soit simplement parce que j’ai changé la vieille machine par une qui l’éclate complètement question puissance : je n’ai encore jamais atteint une forte charge avec.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Enfin pour les portables ?
Posté par FluffyHamster . Évalué à 6.
J'entendais par la "utilisation bureautique", sur PC fixe ou portable, opposé à une utilisation professionnelle et les besoins spécifiques qui vont avec.
PA est très efficace niveau gestion énergétique, notamment grâce à cela :
http://0pointer.de/blog/projects/pulse-glitch-free.html
De plus, il à été porté sur Android et mis en compétition avec son système AudioFlinger, et les résultats préliminaires sont très encourageant (meilleur perf, latence et économie d'énergie), montrant encore une fois si c'étais nécessaire que oui, PA fonctionne en embarqué (il équipe également les N900).
http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/
[^] # Re: Enfin pour les portables ?
Posté par zebra3 . Évalué à 4.
Merci de la précision, j'éviterai par la suite d'utiliser mes portables sur un bureau. Je les mettrai directement sur mes genoux.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Bravo et merci
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Je ne l’ai pas encore lu en entier, mais cette dépêche me fait bien plaisir. Merci beaucoup !
PS : pass through -> transversal, je dirais, non ?
https://fr.wiktionary.org/wiki/pass_through
https://fr.wiktionary.org/wiki/transversal
[^] # Re: Bravo et merci
Posté par FluffyHamster . Évalué à 1.
Oui "transversal" pourrait convenir, mais c'est le genre de terme qui est écrit partout en anglais, donc commencer à utiliser une traduction içi amènerai plus de confusion qu'autre chose.
[^] # Re: Bravo et merci
Posté par psychoslave__ (site web personnel) . Évalué à 5.
Pour ce genre de cas je recommande de préciser le terme anglais entre parenthèses : transversal (pass through).
[^] # Re: Bravo et merci
Posté par gpe . Évalué à 6. Dernière modification le 14 mai 2012 à 00:04.
Moi je dirais plutôt traversant.
Après comme partout tout est écrit en anglais pourquoi continuer à parler français …
Quand il y a un terme technique vraiment ultra spécifique je ne dis pas mais là pass through c'est du langage commun il n'y a donc aucune raison de ne pas le traduire.
# et sans interface graphique ?
Posté par Yao Kuramoto . Évalué à 2.
question bête :
pourquoi il faut dbus et xorg pour que pulseaudio fonctionne (je ne les vois pas sur le chéma pourtant) ?
car j'ai pas réussi à le faire tourner en console uniquement. du coup mon serveur de son à un xorg qui tourne pour … pulseaudio.
alors j'ai certainement mal cherché, ok, mais j'affirme que ce n'est pas trivial.
[^] # Re: et sans interface graphique ?
Posté par FluffyHamster . Évalué à 4.
Hum je ne sais pas quelle distribution tu utilise, mais je n'ai pas ces dépendances. Peut être que ton paquet inclus également les outils graphiques tels que le gestionnaire de préférences ou de volumes (en screenshot dans la dépêche). Ou qu'il est mal packagé :-0
D-bus par contre au moins est utilisé pour communiquer avec Jack lors ce que les deux logiciels sont utilisés conjointement.
http://www.archlinux.org/packages/extra/i686/pulseaudio/
http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules#JACK_Connectivity
[^] # Re: et sans interface graphique ?
Posté par Yao Kuramoto . Évalué à 3.
je ne sais pas… j'utilise Archlinux.
Bon j'ai retenté et j'ai pas réussi ou bien à moitié, à savoir, que maintenant, à la place d'avoir une session xorg sur la carte graphique, je l'ai en freenx.
et je peux sortir le son du téléphone via bluetooth sur pulseaudio \o/
Ce qui n'a rien à voir avec ce que je cherche à faire mais c'est ça qui est marrant. on se sais jamais ou la session de bidouille nous mène !
# Pourquoi je n'aime pas PA
Posté par mathieu mathieu (site web personnel) . Évalué à 4.
Les dépendances sont trop fortes dans le packaging de ma distrib (debian). Si je veux gnome3, ca tire la dépendance PA et plus de mixeur Alsa fourni.
Je n'ai pas trouvé de config qui fonctionne avec PA avec un périph usb externe (DAC ampli casque) + filtre LADSPA + daemon mpd.
Obligé d'etre en alsa et de bidouiller avec dmix.
# Tant que j'y pense…
Posté par chimrod (site web personnel) . Évalué à 4.
Puisque les enceintes intégrées sur portable sont souvent moisies, je fais sortir le son par pulseaudio vers un autre PC dédié à la musique (MPD et tout le tralala).
Mais par définition, un portable est fait pour bouger, et il lui arrive de ne pas être chez moi.
Partons du principe que :
J'aimerai bien une configuration de PA en fonction du réseau : si l'on est identifié sur le réseau A, faire sortir le son sur la machine A.1
sinon, faire sortir le son en local.
Est-ce que je suis le seul à avoir des idées comme ça ?
[^] # Re: Tant que j'y pense…
Posté par Alexandre . Évalué à 2.
Sauf qu'il ne me semble pas que le créateur de PulseAudio ait un quelconque lien avec Network Manager …
[^] # Re: Tant que j'y pense…
Posté par chimrod (site web personnel) . Évalué à 2.
Ah ? Aurais-je associé deux applications controversées à la même personne ? Merci de la précision…
Il n'empêche que j'aimerais beaucoup que PA puisse s'adapter au réseau pour faire sa configuration…
[^] # Re: Tant que j'y pense…
Posté par Albert_ . Évalué à 2.
En theorie tu dois pouvoir utiliser son autre bebe, avahi.
Mais bon good luck pour configurer cela.
[^] # Re: Tant que j'y pense…
Posté par Albert_ . Évalué à 4. Dernière modification le 14 mai 2012 à 11:05.
Lennart Poettering est aussi le créateur de network manager non.
Pas du tout efface, c'est l'auteur du truc a moiti fini qu'est avahi mais absolument pas de network-manager.
On peut pas le rendre responsable de tout les bloatware de linux non plus.
[^] # Re: Tant que j'y pense…
Posté par zebra3 . Évalué à 8. Dernière modification le 14 mai 2012 à 11:49.
C'est tellement à moitié fini que les auteurs de la spécification qu'il implémente ont reconnu qu'il était meilleur que leur propre implémentation.
En effet, on le rend déjà responsable de problèmes faux, n'abusons pas.
J'ai l'impression que certains ont un algorithme qui les font cracher sur le logiciel dès qu'ils lisent le nom "Lennart Poettering".
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Tant que j'y pense…
Posté par Albert_ . Évalué à 3.
Je dis bien a moiti fini car c'est a peu pres impossible pour madame michu de s'en servir mais je sais que tu vas me demontrer le contraire.
Il n'empeche que je vois des gens normaux qui se servent de cette techno sous Mac et que je vois des gens qui savent se servir de linux avoir toute les peines du monde pour se servir de ce truc. Alors peut etre que les bases sont bonnes mais si le cote user est oublie cela ne sert a rien et c'est a moiti fini.
[^] # Re: Tant que j'y pense…
Posté par Buf (Mastodon) . Évalué à 2.
La différence entre Mac et Linux pour Avahi/Bonjour, c'est surtout une question d'intégration.
Sur Mac, c'est mis en avant par Apple et ça existe depuis longtemps, du coup les applications vont faire tout le boulot pour enregistrer les services qu'elles proposent. Du point de l'utilisateur, ça va marcher tout seul dans la plupart des cas.
Sous Linux, il y aura très souvent une bonne dose de travail à faire manuellement.
[^] # Re: Tant que j'y pense…
Posté par Albert_ . Évalué à -1.
C'est bien ce que je dit c'est a moitie fini. Si ce n'est pas utilisable c'est pas fini point barre.
[^] # Re: Tant que j'y pense…
Posté par zebra3 . Évalué à 5.
Quel travail ? Je m'en sers tous les jours et n'ai jamais rien eu à configurer.
Ah si, j'ai coché « Partage de musique » dans Rhythmbox, vachement compliqué…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Tant que j'y pense…
Posté par zebra3 . Évalué à 4.
Sauf que Mme Michu ne va certainement pas s'en servir, vu que c'est un framework. Ce sont les logiciels au dessus qui s'en servent.
Et désolé de te décevoir, mais Avahi fonctionne. Tu l'installes sur plusieurs machines, tu fais ping machin.local et ça répond (sans DNS).
Je lance Rhythmbox, j'active le partage DAAP et je le vois sur toutes mes machines.
Je lance Empathy qui me propose de créer un compte réseau local, et tous les Empathy discutent entre eux.
Et ça ne date pas de trois mois, hein, ça fait des années que je m'en sers. Sans rien configurer côté Avahi, bien entendu.
C'est un framework, que veux-tu que l'utilisateur fasse avec ? C'est comme si tu me disais que Mono est pourri parce que l'utilisateur final ne sait pas s'en servir, c'est débile.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Tant que j'y pense…
Posté par Albert_ . Évalué à -3.
Vu que pas mal de distributions n'installent pas les services par defaut (question de securite) et qu'il n'y a rien pour le faire autrement que ouvrir un terminal et copier les bons fichiers la ou il faut. Ce n'est pas Madame michu qui aura un truc fonctionnel.
[^] # Re: Tant que j'y pense…
Posté par zebra3 . Évalué à 3.
Quelles fameuses distributions ?
Non parce qu'au moins Ubuntu, celle que Mme Michu a le plus de chances de se voir installer, a un service Avahi installé par défaut et fonctionnel.
Quels fichiers ? Il n'y a rien à configurer sur Avahi. Un apt-get install et le service est actif…
Mauvaise distribution, changer distribution.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Tant que j'y pense…
Posté par Batchyx . Évalué à 3.
Ce n'est vraiment pas une bonne raison. Faire un standard qui tiens la route et coder proprement sont deux choses différentes, et on trouve beaucoup plus de personnes qui savent faire l'un et pas l'autre que de gens qui savent faire les deux.
Que Avahi soit mieux conçu que l'implem de l'auteur original qui à du tester plusieurs modifications/améliorations de son protocole avec son implémentation, je trouve ça presque normal. C'est toujours plus facile d'arriver après la bataille.
Mais pour avoir regardé le code source d'Avahi (déjà, généralement, quand il y a besoin de descendre jusqu'au code source, c'est qu'il y a un problème), c'est quand même un gros sac de spaghettis et de code moche avec un peu trop de copier/coller.
[^] # Re: Tant que j'y pense…
Posté par zebra3 . Évalué à 1.
Que le code soit moche ne fait pas de lui un logiciel à moitié fini.
Critiquer son code et lui reprocher de ne pas fonctionner ne sont pas la même chose.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.