PulseAudio est un serveur de son multi‐plate‐forme développé en C et publié sous licence LGPL 2.1. Son rôle au sein d’un système d’exploitation est d’effectuer le mixage des canaux audio en provenance des diverses applications et entrées sonores externes, puis leur lecture sur des périphériques audio tels que des cartes sons locales ou distantes (voir les schémas ici et là).
La version 4.0 est sortie le 3 juin 2013 (et est déjà disponible dans Debian Sid, par exemple).
Rappelons que PulseAudio, devenu le serveur de son de référence pour les systèmes GNU/Linux, a été créé par le très talentueux Lennart Poettering :
De nos jours les vendeurs de matériel comprennent que quand PulseAudio ne marche pas correctement avec leurs produits c’est sans doute de leur faute, pas celle de PulseAudio. D’une certaine façon, PulseAudio est devenu un test standardisé que les vendeurs de matériel utilisent pour évaluer leurs pilotes. (source)
Les principales nouveautés
- Meilleure gestion des demandes pour les flux nécessitant une faible latence ;
- Optimisations du mixage des flux audio (générique, ARM NEON) ;
- Le rééchantillonnage utilise maintenant par défaut une qualité de 1/10 plutôt que 3/10, et permet ainsi d’alléger la charge processeur sans perte de qualité notable ;
- Factorisation du code pour le Bluetooth permettant une meilleure fiabilité et une maintenance plus simple ;
- Complétion Bash et zsh pour les outils en ligne de commande ;
- Correction de bogues pour Solaris et Mac OS X ;
- Ajout du MPEG-2 AAC pour le matériel le prenant en charge ;
- Beaucoup d’autres améliorations, corrections de bogues, documentation et mises à jour d’internationalisation.
Les nouveaux modules
module-role-ducking
Ce module permet d’adapter les niveaux sonores des différents flux en fonction de leur importance (ducking). Par exemple, par défaut, les flux audio et vidéo sont relégués au second plan lorsque un flux téléphone est présent. Ce comportement utilise les propriétés media.role des flux. Ce module n’est pas activé par défaut.
module-remap-source
module-remap-source permet d’encapsuler une source pour réassigner ses ports. Par exemple, il est possible de permuter les canaux droit et gauche.
Aller plus loin
- Site officiel (294 clics)
- Sortie de Pulseaudio 2.0 (128 clics)
- Pulseaudio vs Jack (280 clics)
- Entretien avec Lennart Poettering (98 clics)
- Notes de version (42 clics)
- PulseAudio vs. AudioFlinger: Fight! (janvier 2012) (125 clics)
# Pulse audio siffle dans mes oreilles...
Posté par kadalka . Évalué à -10.
Le fameux pulseaudio de Lennart, l'homme qui suscite tant de controverse…
En plus je l'utilise je crois bien dans mon ordinateur…
A moins, que, non finalement il n'est pas présent, pourtant j'ai du son quand même…
Je me pose quand même une question philosophique:
Et, XMMS il est définitivement mort ?
Je m'en servais beaucoup avec Mandrake 8. Ah nostalgie quand tu nous tiens.
Si ça c'est une bonne chose je veux bien qu'on me pende…
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par xcomcmdr . Évalué à 5.
Si tu cherches un remplaçant à XMMS, je ne peux que te conseiller Audacious.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par kadalka . Évalué à -10.
Je parlais du serveur de son. Je connais audacious, il est présent dans cet ordinateur.
XMMS 2 est un serveur de son du genre VLC (je crois) :
selon wikipedia : " un lecteur basé sur un modèle client serveur, et une gestion des bibliothèques multimédia " (…)
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par Didrik Pining . Évalué à 3.
XMMS 2 c'est comme MPD, en plus… xmms ?
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par barret benoit . Évalué à 10. Dernière modification le 18 juin 2013 à 13:07.
Sous mandrake 8 via le dépôt urpmi ? pas les premières release alors.
Parce que xmms2 d’après mes souvenirs était plutôt disponible sur la 9.0 voire .1
xmms2 est autant un serveur de son que vlc, totem, xine, bmpx, audacious, mplayer, rhythmbox, …
C'est autant un serveur de son que (choix multiples)
- Firefox un serveur Web
- les shells scripts permettent de faire du langage objet
- GNU/Hurd est une grappe de calculs (pas les rénaux)
Ce serait peut-être plus judicieux de sortir de wikipedia pour persister dans la non connaissance/maitrise/savoir-faire sur ce sujet… et plutôt d'aller voir du cote d'ubuntustudio par exemple qui te permettrait de mieux comprendre/maitriser ces concepts sur le son.
Tu pourrais ainsi parler de jack D (pas daniels), oss (pas 117), alsa (pas pour la cuisine), mpd (rien a voir avec le mariage pour tous), et éventuellement ICECAST qui t’intéresserait !?
Si je me suis emporte pour rien ou fourvoyé : mes excuses.
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par kadalka . Évalué à -10. Dernière modification le 18 juin 2013 à 13:24.
J'utilisais Mandrake 8 avec XMMS 1. Dans le texte c'est écrit XMMS [sans chiffre]
Je cherche l'équivalent de la XMMS2 dès fois qu'il y en aurait …
Je ne savais pas qu'audacious (ou totem) était un serveur de son.
Le serveur de son qui m'intéresse c'est celui qui pourrait faire transiter par le réseau le son.
VLC peut fonctionner en streaming via http par exemple.
Merci pour la vanne; elle n'est pas drôle.
En théorie, on peut transformer en serveur de son XMMS2, non seulement c'est écrit mais en faisant un
xmms2 --helpon a les commandes qui conviennent." Network transparency means you can run and control XMMS2 remotely " (…)
source XMMS2 official home page
Pas intéressé.
Je crois que ce sont les enfants qui se fâchent pour des prunes… T'es pas fâché au moins ?
PS: Wikipedia est une bonne source d'information à qui sait s'en servir…
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par ariasuni . Évalué à 2.
PulseAudio sait faire (c'est un des buts de sa conception d'ailleurs). Dans la dépêche on parle de Bluetooth d'ailleurs…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par Frank-N-Furter . Évalué à 10.
Quand on dit que Pulse Audio est un serveur de son, ce qu'on entend c'est qu'il va présenter (servir) les flux audio qui lui son soumis par les applications (lecteur vidéo, audio, jeu, etc) a la carte son pour qu'elle fasse vibrer les membranes de tes enceintes/écouteurs et produise ainsi du son.
Quand on dit que XMMS2 est serveur c'est parce que la partie qui joue la musique peut tourner en arrière plan, sans interface graphique et être contrôlée soit en ligne de commande, soit par un client sur une autre machine Network transparency means you can run and control XMMS2 remotely, mais ça ne concerne pas le transit du son, qui lui va passer par pulse audio.
Et puisque tu mentionnes Wikipedia: http://commons.wikimedia.org/wiki/File:Pulseaudio-diagram-fr.svg
Depending on the time of day, the French go either way.
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par kadalka . Évalué à -10.
Pour moi un serveur de son (donner du son musical, etc.) c'est le logiciel qui lui lit les fichiers son (ogg) qu'on lui soumet, il les dispatche (http, alsa, oss, etc.), ou il attend (genre daemon qui attend ).
ALSA, OSS, PulseAudio sont pour moi des serveurs audio: il autorise ou pas l'usage de la carte son locale.
Maintenant si ce n'est pas ça, expliquez moi alors.
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par Larry Cow . Évalué à 3.
C'est ce que le monsieur vient de faire. Ce que tout le monde (sauf toi) nomme "Serveur de son" (ou "Sound server", "sound daemon", etc.), c'est un logiciel comme PA, ESD, ArTS (pas certain de la casse…), etc. Un logiciel qui permet (entre autres) la transparence réseau pour la diffusion du son.
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par kadalka . Évalué à -10.
Ah ? Donc pour vous XMMS2 est un serveur de son ?
Parce que XMMS2 attend (daemon), dispatche (http, alsa, PA), lit les fichiers audio (ogg, mp3)…
Pulse lui il attend qu'on lui livre ce que XMMS veut bien lui passer…
Pulse EST le deamon entre la carte audio physique et le /dev/dsp par exemple
(Pulse est un serveur audio mais pas un serveur de son.)
Selon votre exemple, Pulse s'occupe du réseau aussi ?
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par Frank-N-Furter . Évalué à 10.
Tu as regardé le diagrame que j’ai mis en lien?
Depending on the time of day, the French go either way.
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par Larry Cow . Évalué à 10.
Arrête d'essayer d'analyser l'étymologie du truc. Ce que tout le monde appelle un "serveur de son", c'est une abstraction de ton matériel audio qui te fournit la transparence réseau (et plus si affinités/pulseaudio). Basta.
Range Shoutcast, XMMS2 et MPD dans la catégorie des "serveurs de flux audio" si ça te fait plaisir, mais il ne suffit pas de "déclarer" une définition pour que tout le monde la suive. Et ça te simplifiera grandement la vie de suivre les définitions existantes des mots plutôt que d'expliquer à tout le monde qu'il se plante et que la tienne est meilleure.
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par Misc (site web personnel) . Évalué à 3.
Il peut s'occuper du réseau :
http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network/
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par ariasuni . Évalué à 3.
VLC n'est pas un serveur de son, ne l'a jamais été et n'a jamais eu vocation à l'être.
Donc c'est un lecteur.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 6.
Le C de VLC veut dire client…
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par kadalka . Évalué à -10.
On peut utiliser VLC pour le streaming: la vidéo et le son passent par le LAN…
Sinon continuer la lecture ici pour xmms2
C'est aussi un serveur. Voir le lien ci-dessus.
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par osmedts . Évalué à 9.
Un serveur de streaming n'est pas ce que tout le monde ici sauf toi appelle un serveur de son.
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par ariasuni . Évalué à 4.
Mais pas un serveur de son… Le serveur de son c'est celui qui communique le son des applications à une couche plus basse, le noyau généralement.
Un client de musique peut avoir une architecture de type client/serveur, c'est à dire que tout le boulot est fait par le serveur et c'est un ou plusieurs clients éventuellement connectés qui font l'affichage et le contrôle.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par gnumdk (site web personnel) . Évalué à 10.
XMMS2 sous Mandrake 8.0, arrête la drogue, vite!
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par Mme Michu-cide . Évalué à 0.
@kadalka : Tu m'as trop fait penser à ce gars en la ramenant de la sorte:
https://www.youtube.com/watch?feature=player_embedded&v=SggWtYEirKE
:)
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par omer666 . Évalué à 10.
Sais-tu pourquoi il suscite des "controverses" ? Lesquelles ? Chez qui y a-t-il controverse ? La première fois que j'ai été confronté à PulseAudio, c'était sur une Ubuntu 8.04, et la version utilisée était encore bien loin d'être finalisée, du moins pas encore assez pour une distribution grand public. C'est le choix de la distribution qui est à remettre en cause ici. Quand j'ai essayé de le désinstaller, apt m'a gentiment notifié que c'était une dépendance et qu'il allait virer tout le desktop Ubuntu avec, alors du coup j'ai bricolé des après-midis durant pour obtenir quelque chose d'utilisable. Très user-friendly, n'est-ce pas ? Mais est-ce là la faute de Poettering ?
Il faut bien que le développement suive son cours, et pour ce faire, que les versions pré-1.0 sortent et soient testées par les utilisateurs. Si les distributions décident de s'en servir, et de contraindre l'utilisateur dans ce choix (voir le wiki Ubuntu, sous "PulseAudio Removal", "This is generally a bad idea, for reasons outlined in this Article"), c'est leur entière responsabilité. D'ailleurs Poettering s'est prononcé contre la façon dont PulseAudio avait été adopté par Ubuntu 8.04 : "To my surprise when Ubuntu adopted PulseAudio they moved into one of their 'LTS' releases rightaway"
Quand je suis passé à Fedora, j'avais encore des problèmes avec PulseAudio, installé par défaut. Cependant, d'une part le public visé par la distribution n'est pas le même, d'autre part quand j'ai voulu le désinstaller, Yum a désinstallé PulseAudio tout seul comme un grand et le problème était réglé. Depuis quand la désinstallation d'une composante logicielle est-elle "déconseillée" ?
J'ai fui pendant des années PulseAudio pour des problèmes techniques, mais est-ce une raison pour en rajouter encore une couche au sujet de Lennart Poettering, qui fait son travail, et qui le fait bien, il me semble. En effet, la version 1.0 de PulseAudio était stable sur tous mes systèmes, ce qui est, je pense, le but d'une version 1.0, et systemd qui en prend pour son grade depuis un bon moment, se révèle être très efficace sur mon système, de sorte que j'ai bien l'impression que tout ce battage tient plus du troll frénétique que des problèmes techniques.
Ah et en plus de revoir ta définition d'un serveur son, intéresse-toi un peu à celle de la philosophie qui aurait besoin d'un peu plus d'attention.
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par Marotte ⛧ . Évalué à 3.
Je pense que c'est le fait que systemd éloigne Linux de la grande famille des UNIX, en particulier des BSD. Lennart dit qu'il a rien contre un port de systemd sur BSD mais il me semble que techniquement ça obligerait à modifier en profondeur le noyau des OS BSD, ce qui paraît à la fois coûteux et potentiellement dangereux, donc non souhaitable.
Après, est-ce que c'est mal de se reposer sur des spécificités du noyau Linux bien que ça nuise à la portabilité du bousin ? Ça je suis bien incapable de le dire.
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par claudex . Évalué à 7.
Le gros problème du portage vers BSD, ce sont les cgroups. Alors, soit les BSD ont un équivalent et systemd se porte assez bien, soit tu retire les cgroups de systemd et tu perds une grosse partie de sont intérêt (et donc, peut-être que ça ne vaut pas la peine de le porter).
« 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: Pulse audio siffle dans mes oreilles...
Posté par GnunuX (site web personnel) . Évalué à 4.
De toute façon systemd est sous LGPL, quelque soit les choix technologiques systemd ne sera pas installé par défaut sur les systèmes BSD.
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par ariasuni . Évalué à 10.
Mais ça on s’en fout un peu non?
En fait c’est plutôt le contraire que j’avais compris, que c’était possible de faire tourner systemd sans certaines fonctionnalités sous BSD mais personne n’a envie de faire ce travail…
Non, Linux a des fonctionnalités en plus de BSD mais faut pas s’en servir c’est mâââl.
Pour conclure: on va pas râler parce qu’on a un logiciel performant, souple et puissant qui exploite un maximum de fonctionnalités de Linux quand même? on est pas une population de vieux con à ce point, si?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par Marotte ⛧ . Évalué à 3.
Si, comme dit Xavier Claude, sans les cgroups systemd perd une grande partie de son intérêt, pourquoi dépenser de l'énergie dans un portage sous BSD ?
Non pas du tout. Je n'utilise pas car je suis sous Debian et je préfère garder l'init par défaut mais j'imagine que si j'utilisais une distribution avec systemd par défaut je l'utiliserais. Ça ne me ferait pas changer de distribution ou bien me lancer dans du bricolage pour virer systemd et utiliser l'init « traditionnelle ». Enfin j'imagine.
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par ariasuni . Évalué à 4.
Faut arrêter, c’est quand même pas le seul avantage de systemd d’utiliser les cgroups… Bon si les performances ça intéresse personne il y a aussi les unités systemd qui sont faciles à écrire, un même code pour toutes les distributions (l’ayant adopté s’entend), des services qui se lancent à la demande, une administration simplifiées parce que systemctl saytropratik™, etc.
J’ai déjà bricolé l’init pour avoir systemd quand c’était pas encore celui par défaut et je n’ai pas eu de problèmes (en suivant les instructions du wiki ça passe tout seul). D’ailleurs systemd pourrait passer à systemd, mais Debian/kFreeBSD pose un problème…
Pour en revenir au sujet: si c’est pas ton système d’initialisation, de quoi peux-tu te plaindre? :p
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par robin . Évalué à 3. Dernière modification le 20 juin 2013 à 00:45.
C’est pas un compilateur, il n’a pas besoin de se compiler lui-même pour prouver sa maturité ( ¬‿¬). D’ailleurs j’ai du mal à saisir ta phrase, j’aurai pu penser que tu parlais des BSD*, mais la mention de Debian juste après contredis cette hypothèse.
Et pour rester sur les anecdotes, je viens de m’apercevoir que tu as posté le 20 juin, hors le 20 c’est encore demain pour moi ! Décalage horaire toussa-toussa.
bépo powered
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par ariasuni . Évalué à 2.
Oui je voulais parler de Debian… (qui n’est pas passé à systemd!)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par claudex . Évalué à 5.
Autant écrire un traducteur unité systemd → script init, c'est plus simple et ça a le même avantage. Ça couvre beaucoup de cas, et pour les autres, on écrit le script init à la main.
Là, on parle d'adapter le code pour les BSD, ce ne sera justement plus le même code.
Il faudrait voir ce qui reste de systemctl une fois qu'on n'a plus les cgroups.
Pas besoin de systemd pour ça.
« 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: Pulse audio siffle dans mes oreilles...
Posté par xcomcmdr . Évalué à 2.
Et on se foire dans le script, et on revient à une unité systemd bien plus simple et sécurisée.
Been there, done that !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par ariasuni . Évalué à 3.
Ça m’étonnerait que ça soit possible, puisque les sripts et le système d’init ont toujours été très différents donc à moins qu’ils passent tous à OpenRC ou à un système d’init à la BSD…
J’espère quand même qui s’ils adaptent systemd ça changera pas les 3/4 du code parce que sinon ça sert à rien effectivement. OpenSSH sous GNU/Linux c’est pas la version «officielle», c’est un portage et pourtant c’est quand même relativement proche de l’upstream non?
Bah systemctl enable/disable/start/stop/restart/reload/status/list-units/etc ça va quand même pas disparaitre si? Bon c’est sûr ça demandera du travail de changer toutes les parties qui dépendent des fonctionnalités de Linux, mais je pense que c’est possible (en virant les parties de code qui dépendent de Linux et en remplaçant quand c’est nécessaire par la version kifonktione™ sous BSD).
C’est plus facile avec systemd quand même… (ex:
systemctl enable cups.socket)Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par claudex . Évalué à 3.
Tu veux dire que les BSD devraient passer à un système d'init à la BSD ?
Il y a déjà un service start/stop/reload/status, autant l'étendre que de tirer systemd si c'est juste pour avoir ça en plus.
Et quand il n'y a pas d'équivalent comme les cgroups ? (parce que ça joue quand même dans tout systemd, y compris dans systemctl status ou systemctl restart.
Ce n'est pas vraiment plus compliqué autrement.
« 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: Pulse audio siffle dans mes oreilles...
Posté par ariasuni . Évalué à 3.
Je pensais aux distros GNU/Linux qui ne sont pas passées à systemd (oui j'ai bugué).
Mais je crois que tous les BSD n'ont pas le même système d'init. À vérifier.
On fait comme avant avec les scripts shell, en mode bourrin? Après je sais pas jusqu'où va l'utilisation des cgroups…
Enfin bref, même si c'est pas systemd, les BSD gagneraient à avoir un système d'initialisation bien foutu, parce que même si les scripts shell ça marche, niveau maintenance c'est un cauchemar.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pulse audio siffle dans mes oreilles...
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 20 juin 2013 à 09:59.
Pendant que les uns se battent pour rester dans un vieux monde qui n'existe plus, d'autres avancent pour proposer des outils utiles dans le monde d'aujourd'hui (bien différent d'hier, en public visé et machines disponibles), et si ça nécessite de casser, on casse.
C'est quoi le problème? Faut rester avec des contraintes datant du moyen-age juste pour le principe?
systemd a l'air de répondre à pas mal de besoins…
faut un autre argument que celui-ci pour ne pas bouger.
# PulseAudio, un test standardisé ?
Posté par gouttegd . Évalué à 10.
Je ne sais pas dans quel monde vit Lennart Poettering, mais moi j’ai plutôt l’impression que les vendeurs de matériel s’en contrefichent royalement que PulseAudio ne fonctionne pas bien avec leurs produits (ou que leurs produits ne fonctionnent pas bien avec PulseAudio).
Sérieusement, on a des exemples documentés de vendeurs de matériel audio prenant la peine de tester la compatibilité de leur matériel avec GNU/Linux ? Moi je ne connais que des initiatives émanant de la communauté, mais rien qui témoigne d’une implication directe des constructeurs…
[^] # Re: PulseAudio, un test standardisé ?
Posté par kadalka . Évalué à -5.
C'est une question que j'ai fini par me poser au final…
Avec le marché restreint de linux, je doute qu'ils vont mettre des billes dedans, mais bon si intel va vers le kernel, peut-être qu'un constructeur daigne bien donner sa chance à l'audio de linux ?
[^] # Re: PulseAudio, un test standardisé ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 0.
Majoritaire sur les ordiphones il me semble… Alors s'ils s'en moquent, ils sont bons pour mourir sans être regrettés.
[^] # Re: PulseAudio, un test standardisé ?
Posté par claudex . Évalué à 10.
Android n'utilise pas Pulseaudio, WebOS n'existe plus, SailfishOS n'existe pas encore, et pour FirefoxOS je ne sais pas s'il utilise Pulseaudio.
« 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, un test standardisé ?
Posté par kadalka . Évalué à -9.
Mais ubuntu, il utilise PulseAudio quand même non ?
La version publique je veux bien, mais selon Wikipedia Sailfish OS est déjà fait.
--- " The most significant products created by Jolla " (…)
source Jolla
[^] # Re: PulseAudio, un test standardisé ?
Posté par mpurple . Évalué à -3.
Il ne faut pas toujours croire ce qu'il se dit sur internet, encore moins que Wikipedia.
Sailfish ne devrait pas sortir en Europe avant la fin de l'année.
PulseAudio n'est surement pas un test standardisé mais on le trouve très souvent dans l'embarqué, même dans Android…
[^] # Re: PulseAudio, un test standardisé ?
Posté par antistress (site web personnel) . Évalué à 5.
Tu peux sourcer STP ? Ça m’intéresse
[^] # Re: PulseAudio, un test standardisé ?
Posté par riri le breton (site web personnel) . Évalué à 3.
source "on le trouve très souvent dans l'embarqué, même dans Android…"
---->[]
[^] # Re: PulseAudio, un test standardisé ?
Posté par kadalka . Évalué à -7.
Wikipedia est une référence à qui sait s'en servir. C'est grâce à elle que j'ai des infos pertinentes comme ceci :
SailFish SDK c'est déjà là : Get the toolkit
[^] # Re: PulseAudio, un test standardisé ?
Posté par Larry Cow . Évalué à 3.
Je pinaille, mais le SDK dédié à un OS, c'est assez différent de l'OS lui-même. Après, peut-être qu'ils fournissent un simulateur muni d'une image bootable, on ne sait jamais.
[^] # Re: PulseAudio, un test standardisé ?
Posté par CrEv (site web personnel) . Évalué à 3.
Tiens, en voilà une référence wikipedia : http://brols.mardyck.org/post/5657
[^] # Re: PulseAudio, un test standardisé ?
Posté par peikk0 . Évalué à 9.
Par contre Maemo 5 utilisait PulseAudio, et ça fonctionnait tellement bien que le son sacadait avec 2 applications audio en même temps, et qu'il était impossible de lire du Flac vu que PA utilisait trop de CPU pour en laisser au codec…
[^] # Re: PulseAudio, un test standardisé ?
Posté par claudex . Évalué à 10.
C'est marrant parce que quelqu'un s'était amusé à mettre Pulseaudio sur Android (à la place d'AudioFlinger) et les performances étaient meilleures.
« 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, un test standardisé ?
Posté par Batchyx . Évalué à 7.
En même temps, Android n'est pas un modèle de légèreté non plus …
[^] # Re: PulseAudio, un test standardisé ?
Posté par fravashyo . Évalué à 4.
et puis les téléphones android sont maintenant des dual ou quadcore, plus puissants que mon PC de bureau.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: PulseAudio, un test standardisé ?
Posté par Misc (site web personnel) . Évalué à 3.
Pour référence :
http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/
mais c'était y a 1 an et demi.
[^] # Re: PulseAudio, un test standardisé ?
Posté par antistress (site web personnel) . Évalué à 6.
Bonne question, apparemment ça serait AudioFlinger ?
https://bugzilla.mozilla.org/show_bug.cgi?id=808907
[^] # Re: PulseAudio, un test standardisé ?
Posté par padenot . Évalué à 10.
Oui, pour l'instant c'est AudioFlinger dans FirefoxOS (et Firefox pour Android, du coup), à travers soit OpenSL, soit un vile
dlopend'une bibliothèque pas super publique (libmedia.so, sur Android 2.2 uniquement). Ça fonctionne, mais on en est pas très content. On pense peut-être utiliser Pulseaudio dans le future. On peut troller autant qu'on veut, mais Pulseaudio est très balaise pour gérer et mixer plein de sources avec des priorité/frequence d'échantillonnage/format différent, et est meilleur que AudioFlinger quand il s'agit de minimiser les interruptions CPU et d'avoir une basse latence 1.[^] # Re: PulseAudio, un test standardisé ?
Posté par antistress (site web personnel) . Évalué à 4.
Merci pour cette précision
[^] # Re: PulseAudio, un test standardisé ?
Posté par kadalka . Évalué à -9.
Tiens ce que vous dites là, qui est pertinent de mon point de vue personnel, me rappelle la phrase de misc:
Qt/Gtk n'est pas adapté à l'ordiphone selon un dev qu'il connaît…
Je n'en suis pas convaincu mais bon, je prends bonne note de ce qu'à dit misc.
Du coup, j'ai envie de me poser la question: et pulseaudio, il est adapté pour les ordiphones ?
Parce que sur ce marché, il vaut mieux être à la hauteur côté son… et c'est un euphémisme.
[^] # Re: PulseAudio, un test standardisé ?
Posté par bayo . Évalué à 3.
En tout cas, ils semble que les dev font en sorte que PulseAudio soit adapté aux téléphones.
C'est pourquoi il y a cette URL dans la dépêche. Mais c'est un peu vieux.
[^] # Re: PulseAudio, un test standardisé ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4.
Je n'ai pas suivi dans les détails le dev de QtMoko pour le GTA04, mais cet OS avait des problèmes de mise en veille de la carte son (si j'avais bien compris) avec ALSA et est donc passé à pulseaudio pour ce matériel afin d'avoir une veille du téléphone correcte (ensuite ils ont tenté de l'utiliser également pour les OpenMoko, mais ces périphériques n'étaient pas assez puissant et le gain n'était pas suffisamment intéressant).
Donc oui ça s'utilise sur des ordiphones et ça marche (en tout cas pour les appels/alarmes/videos youtube/…).
[^] # Re: PulseAudio, un test standardisé ?
Posté par Misc (site web personnel) . Évalué à 8.
Si tu me permets ( c'est une formule de politesse, en fait, je vais prendre la permission avec ou sans ton consentement ), je vais me citer moi même pour qu'on puisse bien voir comment tu pars de ce qu'on dit vers ce que tu dis :
Sur https://linuxfr.org/nodes/98638/comments/1461011 j'ai dit :
"En fait, non, j'ai encore parlé à midi avec un développeur que je connais ( qui au passage bosse chez RH, mais qui parle en son nom, je précise même si c'est l'évidence vu que tu as du mal à faire la séparation ), et lui pense que GTK et Qt, c'est mort, et qu'il faut partir sur des technologies comme Cordova/phonegap. Car dans tout les cas, si tu vises du multiplateforme, ça inclue les téléphones et c'est le moyen le plus simple. Perso, je continue de penser que les widgets natifs permettent des choses que les UI en html5 ne font pas, et que la fragmentation webkit/blink/firefox/ie/etc est aussi chiante ( ça et les versions ). Et que c'est bien plus lourd qu'une appli local."
De la, tu traduit en "Qt/Gtk n'est pas adapté aux smartphones", ce qui est un raccourci totalement foireux. J'ai bien préciser que pour lui, c'était Qt/Gtk qui sont largué pour faire du multiplateforme ( ie, dans la discussion, c'était du windows/linux/osx au début, puis vers les tablettes, et donc android/ios ). Il a pas dit que c'est inadapté dans tout les cas, ni inadapté sur les portables. Par exemple, pour cibler la plateforme Ubuntu Phone, qui n'a pas pour vocation d'être en multiplateforme, ça semble être plus que correct.
Donc voila, forcément, si tu piges pas plus ce que les gens te disent en dehors de Linuxfr que sur Linuxfr, faut pas étonner que les gens soient pas d'accord avec toi et le fasse comprendre.
[^] # Re: PulseAudio, un test standardisé ?
Posté par groumly . Évalué à 4.
D'un autre cote, vu l'etat pitoyable des API sons sous autre chose qu'iOS, on est en droit de se dire que tant que le chipset fait a peu pres pouic pouic a +/- 50ms, le constructeur/vendor est content (le vendeur, lui, s'en fout comme de sa premiere chemise, il travaille pour att, et c'est a peine s'il sait ce qu'est android)..
Vous vous etes jamais demande pourquoi le marche des appli de creation musicales fleurit sous iOS alors que c'est le grand vide sous android?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: PulseAudio, un test standardisé ?
Posté par ariasuni . Évalué à 1.
Keuwa?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: PulseAudio, un test standardisé ?
Posté par groumly . Évalué à 2.
Vendor est tres mal traduit dans la citation par vendeur, alors qu'il veut dire fournisseur/prestataire.
Le vendeur en francais, c'est le gars avec un cravate chez darty.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: PulseAudio, un test standardisé ?
Posté par hugoL . Évalué à 8.
Dans la version original, il dit:
Ce que je traduirais par
Ce que ce comprends comme une tentative de prophétie auto-realisatrice (ratée) plutôt qu'un constat.
# Ducking
Posté par Artefact2 (site web personnel) . Évalué à 10.
Ce module a l'air intéressant sur papier, mais en réalité il ne sert à rien (et bonne chance pour configurer les applications qui n'envoient pas leur rôle correctement à Pulseaudio…): j'ai essayé de l'utiliser avec Teamspeak et Mumble, et j'ai rencontré le même problème: les autres applications ont leur volume réduit même lorsque personne ne parle.
Si vous voulez vraiment essayer le « ducking », la vraie façon de faire est d'utiliser jack, avec un side-chain compressor (par exemple le module LADSPA SC3). Avec un peu de bidouillage, on y arrive, on peut même garder Pulseaudio (qui enverra le son vers jack au lieu d'ALSA/OSS) pour pouvoir garder le contrôle du volume par application. Voici un exemple de ma config, attention c'est pas joli! http://i.imgur.com/KeOgnkm.jpg
[^] # Re: Ducking
Posté par insert_coincoin . Évalué à 2.
M'enfin bon, s'il faut se transformer en sonorisateur pour pouvoir avoir un ducking décent de certains flux par d'autres…
Hypothèse à la con : le mauvais comportement du ducking que tu remarques est peut-être dû au fait que les basses fréquences ne sont pas filtrées dans la sidechain : du coup, le moindre coup sur la table ou sur l'ordi lui-même déclenche le ducking ?
[^] # Re: Ducking
Posté par Artefact2 (site web personnel) . Évalué à 7. Dernière modification le 18 juin 2013 à 13:15.
Aucun rapport, si tu jettes un coup d'œil à la source, tu verras que le module n'analyse pas le flux censé être "prioritaire" par rapport aux autres, et baisse bêtement le volume des autres flux dès qu'un flux prioritaire est crée (même si c'est pour du silence). Le comportement attendu est de baisser le volume par rapport au volume du flux prioritaire (bref, un vrai side-chain compressor).
Et même si jack est plutôt orienté vers un usage professionnel, je ne vois pas pourquoi s'en priver pour avoir quelque chose de correct :) Il suffit de lire les manuels et d'appliquer du bon sens…
[^] # Re: Ducking
Posté par bayo . Évalué à 2.
En passant, ils indiquaient dans les notes de version qu'ils avaient corrigé un bug dans PulseAudio lorsque on veut lancer JACK sur la carte déjà utilisée par PA via ALSA.
J'ai pas testé mais, en croisant les doigts, il sera plus simple de lancer JACK, et PA devrait lui laisser sa place comme un grand et se placer comme client de JACK.
[^] # Re: Ducking
Posté par barmic . Évalué à 4.
Parce que la pile audio de linux est déjà suffisamment imbitable comme ça ?
Que la première version d'une fonctionnalité pas activé par défaut soit un peu pourri ne me surprend pas tellement ça s'améliorera dans l'avenir :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Liens matériel-ALSA-PulseAudio
Posté par rogo . Évalué à 7.
Je croyais naïvement que PulseAudio n'était qu'une couche au-dessus d'Alsa (parfois OSS). Avec cette idée, la citation de 2011 sur les vendeurs de matériel me semblait maladroite, puisqu'elle oublie les problèmes de pilotes ALSA. J'ai souvent eu des bugs lors de l'hibernation, avec divers PC, surtout lorsque l'audio était actif (lecteur en pause, etc). En général, il faut alors recharger les pilotes avec
sudo alsa force-reload.Dans les nouveautés, j'ai vu le décodage AAC matériel. Si je comprends bien, PulseAudio dialogue donc généralement avec l'API ALSA, mais il peut de temps en temps la court-circuiter pour s'adresser directement au matériel. Je me plante peut-être, mais ça ne me semble pas très robuste : on peut avoir 3 applications qui accèdent simultanément à la même carte son par 3 voies distinctes. L'une par ALSA+matériel, l'autre par PulseAudio+matériel, la dernière par PulseAudio+ALSA+matériel. Il me semble miraculeux que ce scénario fonctionne !
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par tchaik . Évalué à 8.
PulseAudio utilise bien ALSA/OSS/… comme interface avec le matériel. Mais, pour ALSA par exemple, il remonte certaines "méta-données" depuis le matériel pour déterminer la corrélation entre le niveau réel (en dB) de la sortie analogique et le paramètre de volume logiciel. Sauf que pour certains matériels ces données sont complètement fausse; d'où la citation de Lennart à ce sujet.
Pour ce qui est de l'AAC, il s'agit de "passthrough" et pas de décodage : PulseAudio est capable de passer directement du son encodé aux sorties numériques d'une carte son (S/PDIF) ou d'un appareil Bluetooth. Il ne s'agit pas d'un accès direct à la mémoire tampon du matos.
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par bubar🦥 (Mastodon) . Évalué à 9. Dernière modification le 19 juin 2013 à 20:48.
Certains utilisateurs (plein de pincettes tu vois) on justement reprochés cela initialement à PulseAudio, en résumé :
« pourquoi refaire une mauvaise couche de trop ? »
Et j'ajouterai « pourquoi prendre un nouveau dev plutôt que d'améliorer l'existant ? »
Factuellement, ce qui était reproché initialement à PA c'était cela et rien d'autre : ne pas être capable de remplacer jack, et ne pas être capable de remplacer dmix. Bref, une couche de plus :-( Tout ça pour quels bénéfices initiaux ? Clairement : uniquement le blutooth et Adobe Flash. super :-/
Aujourd'hui les choses changent, visiblement. PA n'est toujours pas capable de réaliser tout ce que fait Jack, mais il s'en approche. PA ou Jack, "on" s'en fiche, c'est simplement dommage qu'une solution de grande qualité n'ai pas bénéficiée des mêmes efforts qu'une solution initialement de bien piètre qualité.
Quant aux autres devs de Mr Pottering, on ne peux que constater qu'il a complètement changé son fusil d'épaule, en cherchant justement à changer en profondeur certaines abbérations (de certains points de vue, quelque soit le jugement que l'on porte sur ces changements, il faut constater que nous ne sommes plus du tout sur un ajout mais sur de réels changements. Et en tant qu'admin comme en tant que user, systemD c'est juste génial). Ce qui a nourri d'autres types de trolls. Finalement Lennart s'en prends plein la tronche par certains pour des raisons très différentes.
Quant à PA, je continue de le virer illico, mais je ne désépère pas d'avoir une solution pouvant prendre en compte gloablement les différents besoins, et cerise sur le gateau, tirer tout le monde vers le haut (ne pas grêver les usages lourds pour les gadgets)
hop, moinssez moi.
un systemd user ravi. et bientôt un wayland user ravi ;)
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par fmaz fmaz . Évalué à 2.
Le but de jack et de PA sont très différents.
Pour jack, c'est temps réel et latence faible à tout prix même si ça bouffe 100% du processeur.
Pour PA, c'est plus orienté desktop avec dans l'idée quelque chose de pas trop mauvais le plus souvent mais sans aucune garantie de latence mais avec une charge machine plus faible.
C'est un peu la différence en linux et linuxRT.
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par briaeros007 . Évalué à 0.
charge machine faible ?
On a pas dut avoir le même PA (en tout cas au début de sa vie)
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par ariasuni . Évalué à 7.
Bah regarde ce que ça donne à l’heure actuelle, au lieu de parler au passé.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par Albert_ . Évalué à 1.
J'ai regarde et vu comment mon systeme est plus reactif depuis que j'ai vire ce truc, je dirai que PA est toujours un bouffeur de ressource.
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par ariasuni . Évalué à 3.
J'aurais bien aimé plus d'informations: config matérielle et logicielle, occupation processeur et mémoire prise par PulseAudio lorsqu'1/2/3/4 applications utilisent le son, effets sur les autres applications.
Si on a aucune information, on peut pas vraiment résoudre le problème/bug.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par Albert_ . Évalué à 1.
Je n'ai plus envie (c'est curieux apres des annees d'emmerde) de remettre PA. J'aiu deja rempli des tonnes de bug report sur le sujet et j'en ai marre. J'ai trouve une solution qui FONCTIONNE et en plus me sort une couche de logiciel et utilise donc forcement moins de ressource… Parceque au final je dois etre dur de la comprehension mais je vois pas comment rajouter une couche peut diminuer les ressources utilise vu que de tout de facon tu n'as pas le choix Alsa sera utilise!
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par ariasuni . Évalué à 2.
Ok très bien.
Si ça te convient, tu fais ce que tu veux!
On a jamais dit que PuseAudio serait plus léger que ALSA seul (et heureusement d'ailleurs).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par ariasuni . Évalué à 2.
Maintenant que j’y pense, c’est PulseAudio qui mixe donc ça veut dire qu’on ne passe pas par le mixer d’ALSA donc la différence est peut-être négligeable (sauf dans ton cas visiblement)… Faudrait voir à benchmarker tout ça.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par thamieu . Évalué à 7.
Bah il a le droit d'être sous Debian, aussi.
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par Troy McClure (site web personnel) . Évalué à 4.
Ben ouais mais regarde macos (ou ios). Une seule API, coreaudio, qui permet de tout faire, faible latence ou gros buffers, zéro prise de tête et tout le monde est content. Ca aurait surement été possible sous linux si poettering s'était interessé aux problématiques de temps réel pour l'audio dès le départ, et si les gens qui gravitent autour de jack avaient été un peu moins violents dans leurs réactions.
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par tchaik . Évalué à 10.
Hummm, ton avis est intéressant parce que plutôt subjectif pour quelqu'un qui n'utilise pas PulseAudio. Voici le mien :
Avant PA il y'avait clairement un manque côté pile audio sous linux. Dire que dmix (le mixage logiciel pour ALSA) était/est une solution n'est valable que pour le mec qui utilise encore un PC type bureau en ne branchant jamais rien dessus. Rappelons que ALSA ne gére QUE les cartes son internes et usb. Donc rien pour le firewire, le bluetooth ou le réseau. Ne parlons même pas de fonctionnalitées avancées (suppression de l'echo, ducking, …)
Jack a, lui, clairement une vocation professionnelle : réduire la latence au maximum pour permettre à des applications PRO de faire du monitoring/overdub/multi-pistes/synth… en temps réel. Est il le fait très bien.
PA s'est toujours voulu orienté "consumer audio" pas "pro audio". Il a donc des fonctions avancées (y'a un gouffre avec dmix) pour l'utilisateur classique qui branche son oreillette et utilise skype (arf… le pauvre).
Ce qu'on lui reproche c'est de ne pas être au niveau de CoreAudio (la pile audio OSX) qui, elle, arrive a concilier les deux. Mais là encore il y a des raisons. En faite une, principalement : ALSA n'est pas souple au niveau de sa gestion des tampons mémoires : explications [english]. CoreAudio sait le faire. Comment fait Jack ?? Il utilise un tampon de taille très petite, ce qui garanti une lantence très faible. Le problème c'est que seul les cartes avec une électronique pro et un processeur musclé arrivent a tenir la charge… (+ un kernel aux oignons + rtlimits + …)
"Ouai, enfin, mon PulseAudio bouffe 151% de mon CPU !". Là aussi il y'a une raison. Ce qui coûte cher en audio c'est les IRQs et le rééchantillonnage. Les IRQs c'est vu plus haut. Le rééchantillonnage : Jack ou dmix imposent le taux d'échantillonnage, et c'est a l'application de faire avec, la charge CPU va donc au client. PulseAudio essaye de trouver le bon compromis et rééchantillone lui même, c'est lui qui prend la charge. Ce qui ne veux pas dire que PA est exempt de bugs !
"Mais on peux très bien utiliser Jack sans RT ou faible latence". Certe. M'enfin niveau fonctionnalitées avancés on reppasera : un client veux jouer un son stéréo sur une carte 5.1 > il se connecte aux deux premier ports de la carte son > si c'est pas les deux L/R ben… il faut redistribuer à la main…
De par son architecture "lock-free" et "zero-copy" (en faite, comme celle de Jack) PulseAudio est à priori capable de faire du temps réel comme Jack. Mais l'orientation et clairement à la légèreté et la faible consomation d'énergie, les dévellopements ne vont pas dans ce sens.
On peux par contre regréter la mauvaise intégration avec Jack (PA deviens un simple client Jack quand celui ci se lance) : on notera un manque de volonté côté Jack qui ne veux pas entendre parlé de DBus (pour négocier la main sur ALSA, m'enfin ça va mieux depuis qu'il existe 36 version de Jack) et un retard côté PA dont le pilote Jack est plutôt (très) naze.
Notons quand même que seul Jack est capable de faire cracher les watts à une carte firewire (via libffado,). Mais (toutes ??) les cartes firewire sont des cartes pro…
Après si pour prouver ses dires il faut donner un exemple de quand ça marche pas, je vous laisse fouiner dans les buzilla respectifs de chaque projet à la recherche d'une pépité confirmant votre thèse. Je m'épargne cette peine.
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par ariasuni . Évalué à 2.
Et donc faut un remplaçant à ALSA pour avoir une meilleure pile audio? Parce que bon le seul espoir qu’on ai eu récemment c’est KLANG (et j’ai eu beaucoup d’espoir que ça règle tous les problèmes). Et vu l’état de la page d’accueil du projet (avant il avait beaucoup de textes et deux-trois liens) ainsi que le fait que l’auteur initial c’est fait sévèrement démonté par des professionnels de l’audio sous GNU/Linux…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par tchaik . Évalué à 3.
Remplacer je ne sais pas, mais plusieurs développeurs (Lennart Poettering/Pulseaudio & Paul Davis/Jack) s'accordent pour dire que ALSA devrait arrêter de maintenir sont API en espace utilisateur et revoir l'architecture de ses pilotes internes. Mais le travail est énorme pour une main d'oeuvre très faible.
Pour KLANG, l'objectif est similaire voir plus ambitieux mais la charge de travail est encore plus importante, il semble impossible que ca aboutisse un jour…
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par Albert_ . Évalué à 4.
rappelons que ALSA ne gére QUE les cartes son internes et usb. Donc rien pour le firewire, le bluetooth ou le réseau.
Euh j'ai vire PA et j'arrive a me connecter au systeme son par bluetooth. Est ce de la magie?
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par tchaik . Évalué à 3.
Oui, et le magicien s'appelle bluez-alsa probablement.
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par Albert_ . Évalué à 1. Dernière modification le 20 juin 2013 à 13:13.
Je savais mais c'etais juste pour pointer du doigt que c'etait faisable sans PA. Donc dire que ALSA ne gere pas le bluetooth c'est un peu normal c'est pas fait pour et c'est laisse au … programme qui gere le bluetooth, comme il se doit je rajouterait, et oh miracle ca fonctionne!
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par tchaik . Évalué à 5.
Exactement, ALSA n'est pas fait pour. ALSA c'est des pilotes noyaux pour les cartes PCI/ISA/… & USB + une librairie en espace utilisateur pour son interface client. Au début tout le monde avais UNE carte son INTERNE, alors les clients utilisaient directement l'API ALSA, c'était simple.
Le problème c'est que le matos a évolué et les pilotes ce sont retrouvés en dehors l'ALSA et là c'est devenu compliqué. Simuler une interface ALSA virtuel pour causé à un autre pilote qui peux lui même être en espace utilisateur (bluez-alsa) n'est pas, à mon sens, une bonne solution.
La solution (PA ou Jack) c'est d'avoir une vrais API audio qui ne soit pas dépendante du pilote/matos. Utiliser l'API ALSA pour jouer du son dans son client haut niveau c'est stupide, a moins qu'ALSA centralise tout les pilotes pour le matos audio.
ALSA n'est PAS une API audio haut niveau, même s'il est vrai que libasound a toujours eu un statut ambigu.
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par Albert_ . Évalué à 2.
c'est peut etre pas LA bonne solution mais ca fonctionne alors que la soit disant bonne solution ne fonctionne pas. J'ai un peu l'impression que c'est tres similaire au micro-kernel comme HURD c'est soit disant la bonne solution mais ca fonctionne pas alors que le monolithique Linux a "quelques" succes…
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par tchaik . Évalué à 9.
La comparaison ne me semble pas très adaptée mais en gros c'est un peu : "coder des plugins pour ALSA et assurer une rétro-compatibilité pour une API veille de + 15 ans" contre "corriger les imperfections d'intégration du tout (plus si) jeune PulseAudio".
PulseAudio a viandé dans ton cas, fonctionne dans le miens. J'ai autant de mal avec l'argument du "chez moi sa marche" qu'avec celui du "chez moi sa marche pas". Si on ne vois pas les avantages de PulseAudio (quand il marche), effectivement, ça vaut pas trop le coup de passer du temps a essayer de le faire marché.
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par ariasuni . Évalué à 0.
+1
<grammar_nazi>«fonctionne dans le mien»
«si on ne voit pas»
«chez moi ça marche».
«ça vaut pas trop le coup de passer du temps à essayer de le faire marcher»
</grammar_nazi>Moinsez-moi moinsez-moi moinsez-moi…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par Albert_ . Évalué à 3.
Sauf que Alsa est inclus au kernel et que PA n'est qu'une n'ieme surcouche au dessus de Alsa. Donc ok Alsa c'est pourrit mais bon c'est toujours la et a la fin c'est ca qui fonctionne (avec ou sans PA).
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par navaati . Évalué à 5.
Toi t'as toujours pas compris que Alsa c'est pas UN gros truc, c'est plusieurs morceaux. La partie de Alsa contenue dans le kernel, oui, on veut la garder, ça s'appelle "des pilotes de carte son" et on s'appuiera toujours dessus. La lib Alsa en userspace on veut la virer et la remplacer par PA pour le consumer et Jack pour le pro.
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par ariasuni . Évalué à 2.
Comme les bougies?
Plus sérieusement, est-ce que le mixage effectué par PA est vraiment plus lent/consommateur de ressources que celui fait par ALSA en espace utilisateur?
Écrit en Bépo selon l’orthographe de 1990
# PulseAudio / ALSA
Posté par Padishah . Évalué à 8.
C'est quoi l'intérêt d'utiliser PulseAudio, aujourd'hui, alors qu'ALSA fait aussi du mixage logiciel ?
[^] # Re: PulseAudio / ALSA
Posté par tchaik . Évalué à 4.
C'est quoi l'intérêt d'utiliser dmix, aujourd'hui, alors que PulseAudio s'occupe du mixage logiciel ?
[^] # Re: PulseAudio / ALSA
Posté par claudex . Évalué à 8.
Si pour toi, Pulseaudio, c'est juste du mixage logiciel, c'est que tu n'as rien compris au principe.
« 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 / ALSA
Posté par Raphael Berlamont (site web personnel) . Évalué à 2.
Je ne crois pas que tous les drivers ALSA et/ou hardware supportent le mixing. Le cas échéant, on utilise le contournement DMIX, et on se cogne la tête.
[^] # Re: PulseAudio / ALSA
Posté par tchaik . Évalué à 4.
En effet, pour avoir du mixage "dans l'pilote" il faut 1] que la carte supporte le mixage matériel (quasiment aucune depuis 2000, hors matos pro), 2] que le pilote prenne en charge cette fonctionnalitée. Le mixage logiciel avec ALSA c'est dmix ou rien : ALSA ne sait pas mixe mais peux éventuellement passer le boulot à la carte si elle sait faire.
# Merci pulseaudio
Posté par chimrod (site web personnel) . Évalué à 10. Dernière modification le 18 juin 2013 à 13:45.
Ce week-end, je viens de brancher une platine vinyle sur le pc, j'ai pu configurer tout ça très facilement avec pulseaudio :
Tout ça en logiciel : c'est à dire juste deux lignes à rajouter dans le fichier de configuration. Alors oui il faut mettre les mains dans le cambouis, oui ça se fait sans interface graphique, mais sans PA, je ne crois pas que j'aurais pu mettre ça en place si rapidement.
Pour moi, PA fait partie des logiciels qui occupent une place essentielle sur mon pc !
[^] # Re: Merci pulseaudio
Posté par osmedts . Évalué à 3.
Alors essaie jack… tu dois mettre les mains dans le cambouis aussi mais c'est plus puissant, plus léger. Tu pourras renvoyer tout ce que tu veux dans les filtres que tu veux.
[^] # Re: Merci pulseaudio
Posté par chimrod (site web personnel) . Évalué à 8.
En fait j'utilisais déjà pulseaudio pour centraliser tous les sons des PCs vers un serveur unique. Ça se fait par le réseau, et ça permet de n'avoir qu'une seule sortie son (et de brancher les bonnes enceintes sur cette machine).
Je crois que ça s'appelait encore polypaudio quand j'avais mis ça en place…
[^] # Re: Merci pulseaudio
Posté par Adrien . Évalué à 7.
Idem ici, je voulais rediriger le son d'un PC vers les enceintes d'un autre, de meilleure qualité. Ça se fait super bien avec pulseaudio.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Merci pulseaudio
Posté par claudex . Évalué à 4.
Donc, tout le monde doit avoir ta config pour avoir le droit d'utiliser son PC ?
« 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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Merci pulseaudio
Posté par Moonz . Évalué à 5. Dernière modification le 19 juin 2013 à 14:19.
Ça se fait en un pipeline simple sous gstreamer. Je crois pas que ça prenne des années non plus. Point bonus tu peux même réencoder ça en vorbis et le stocker.
[^] # Re: Merci pulseaudio
Posté par chimrod (site web personnel) . Évalué à 2.
C'est vrai que je ne me suis jamais penché sur gstreamer, pour ma part je le vois comme une couche d'abstraction pour faire le lien entre les applications et les librairies, mais je suis peut être dans l'erreur…
Tu aurais une doc sur la mise en place d'un pipeline sur un pc ne disposant pas de serveur X (ce que j'ai trouvé passe obligatoirement par une interface graphique…) ?
[^] # Re: Merci pulseaudio
Posté par Moonz . Évalué à 3.
man gst-launchest un très bon début, surtout sa section Pipeline Examples.[^] # Re: Merci pulseaudio
Posté par chimrod (site web personnel) . Évalué à 2.
Merci !
[^] # Re: Merci pulseaudio
Posté par ariasuni . Évalué à 1.
Bah Gstreamer c’est une bibliothèque qui va communiquer avec soit ALSA, soit OSS soit PulseAudio.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Merci pulseaudio
Posté par chimrod (site web personnel) . Évalué à 6.
Ah c'est comme pulseaudio alors :)
----> []
# Sans pulseaudio
Posté par needs . Évalué à 10.
Sous arch, j'avais plein de problèmes avec pulseaudio :
.xinitrcpour mettre un volume par défaut…)Et pourtant, j'ai passé des heures à essayer de comprendre d’où venait les problèmes, j'ai lu énormément de doc, j'ai tenté énormément de choses.
Bon puis au final, juste après une mise à jour, je n'avais plus du tout de son et pourtant les volumes étaient bon et pulseaudio était lancé..
pacman -R pulseaudio pulseaudio-alsa pavucontrolon réinstalle quelques outils pour manipuler alsa. On configure vite fait MPD, on redémarre l'ordi (c'est devenu une habitude..) et on commence une nouvelle vie.[^] # Re: Sans pulseaudio
Posté par claudex . Évalué à 10.
Comme quoi, Arch, ce n'est pas que des bonnes expériences.
« 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: Sans pulseaudio
Posté par guildem . Évalué à 3.
Arch ou Pulseaudio ?
[^] # Re: Sans pulseaudio
Posté par claudex . Évalué à 10.
Ça a quand même tendance à marcher depuis quelques années sur les distribs qui font l'effort de l'intégrer.
« 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: Sans pulseaudio
Posté par guildem . Évalué à 4.
bah ça a marché chez moi (même si je ne l'ai pas gardé).
et surtout, ArchLinux n'intègre pas (ou très peu) les applis, du coup on peut dire que "rien n'est intégré sur Arch" :)
elle n'est pas faite pour ça, et donc pas faite pour toi, si ce qui te plait est d'avoir un système prêt, intégré et configuré.
les mauvaises expériences avec cette distribution proviennent surtout d'une incompréhension de sa philosophie.
reprocher à Arch de ne rien avoir d'intégré, c'est comme reprocher à Debian de n'avoir que des vieilles version des logiciels, ou a LFS d'être trop compliquée.
bref pour le coup rien à reprocher à Arch, juste PulseAudio qui est assez difficile à intégrer (et, avis personnel, pas super simple et stable, suivant l'utilisation qu'on en a).
[^] # Re: Sans pulseaudio
Posté par xcomcmdr . Évalué à 3.
Avec des logiciels et patchs qui restent downstream (Xubuntu : xfce4-volumed-pulse, fork de xfce4-volumed, indicator-sound-gtk2, *buntu : support de Timidity++ avec PulseAudio quel que soit la manière dont on l'a lancé alors que j'ai dû trouver LA commande qui le fait fonctionner avec PA sous Arch, etc…), malheureusement.
Reprocher à Arch de ne pas intégrer le logiciel X, c'est un peu ne pas comprendre Arch.
Et sinon, chez moi PulseAudio ça fonctionne très bien. Mais pour ça, j'ai dû :
- bien comprendre l'article sur PulseAudio sur le wiki Arch. Car comme d'habitude, l'intégration, c'est du DIY, c'est le revers de la médaille de sa philosophie KISS. Si t'en veux pas, tu prends une autre distrib' (je te conseillerais Xubuntu d'ailleurs : ça juste marche. Mais y'a pas pacman. :/ )
- compiler xfce4-volumed-pulse (je l'ai mis sur l'AUR depuis), plutôt que d'utiliser xfce4-volumed
- compiler psmixer-xfce4 depuis l'AUR pour avoir un vrai support de PulseAudio dans le tableau de bord Xfce (à la place de xfce4-mixer qui utilise le mixer de gstreamer0.10, tout comme xfce4-volumed, qui est abandonné)
- ne pas lancer pulseaudio ni xfce4-volumed-pulse grâce à leurs fichier .desktop dans /etc/xdg/autostart ! Il faut que PA soit lancé en premier pour avoir du son. Du coup je lance dans l'ordre PA, xfce4-volumed-pulse, et timidity++ dans un script situé dans ~/bin, lancé depuis un fichier .desktop présent dans ~/.config/autostart
- dire aux quelques logiciels (Audacious, SMPlayer, …) que j'utilise PA. Rien de compliqué.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Sans pulseaudio
Posté par ariasuni . Évalué à 2.
Ouais mais bon il n’y a pas beaucoup d’étapes et ça se fait tout seul en suivant le wiki (j’apprécie beaucoup Arch Linux justement pour son wiki). On ne change pas de système audio tous les deux jours et le seul truc un peu crade c’est pour faire passer les applications Java par PulseAudio.
En tout cas pour moi, ça c’est résumé à installer les paquets suivants:
pulseaudio pulseaudio-alsa lib32-libpulse lib32-alsa-plugins, et c’est tout (gstreamer faisant déjà le boulot pour nous en gros et VLC ne demandant pas de conf supplémentaire).Faut que je vérifie cependant s’il y a toujours le bug que j’ai mentionné plus haut.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Sans pulseaudio
Posté par ariasuni . Évalué à 3. Dernière modification le 18 juin 2013 à 22:31.
Ok, donc avec trois applications en même temps ça roule et PulseAudio détecte VLC à 100% de volume quand il est à 100% ou plus mais ça me dérègle complètement le son (après le son est à 100% mais le son du plugin alsa est à 30%, du coup quand je lance une autre application ça gueule mais j’entends rien avec le lecteur Flash sur Youtube). «Fonctionnalité» réglée en 10 secondes grâce au wiki d’Arch Linux.
On peut régler le son par application dans le mixeur ce qui est pas mal même si je n’avais aucun problème avec ALSA — mais on perd le réglage quand on arrête l’application on dirait (au moins pour Flash).
Je n’ai plus le bug des périphériques, mais le test de l’utilitaire de configuration dans KDE ne fonctionne pas (il n’apparait même pas dans les flux audio traitées par PulseAudio). C’est le truc le plus simple qui ne fonctionne pas (c’est peut-être dû à KDE par contre, mais avant ça marchait c’est bizarre… Si quelqu’un peut confirmer le bug).
Enfin, 6-7% d’utilisation du processeur (AMD Athlon 64 x2) avec trois applications qui utilisent le son en même temps, 3% avec une seule application et rien si aucune application n’utilise le son ça me parait raisonnable (j’ai la dernière version, Arch Linux oblige).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Sans pulseaudio
Posté par barmic . Évalué à 2.
T'as réveillé la meute !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sans pulseaudio
Posté par flagos . Évalué à -2.
Oui enfin les distribs qui sont passés courageusement après que les utilisateurs de Arch se soient cassés les dents quoi.
[^] # Re: Sans pulseaudio
Posté par Renault (site web personnel) . Évalué à 7.
C'est Fedora qui a été la distribution qui a débuté l'intégration de PulseAudio et qui l'a poussé à atteindre un très bon niveau.
Normal, c'est le but de la distribution que d'intégrer ce type d'utilitaire et déboguer les gros problèmes rencontrés à cette étape pour que les autres le fassent plus facilement si elles le souhaitent.
Les utilisateurs de ArchLinux ne sont pas des victimes hein. ;)
[^] # Re: Sans pulseaudio
Posté par ariasuni . Évalué à 3.
Chezmoiçamarche™ aussi bien qu'ALSA à part un léger bug mineur qui n'arrive qu'avec KDE (il me dit que des périphériques audio ne sont plus là ou je sais pas quoi mais en fait ça fonctionne très bien), mais pas réessayé depuis un moment (je sais ce que je vais faire ce sois… :p).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Sans pulseaudio
Posté par Albert_ . Évalué à 3.
Merci 1000 fois, apres ton poste j'ai revire pulseaudio et bien c'est impressionant. TOUT fonctionne et bien mieux en particulier le bluetooth. Certes il a fallu que je mette un peu les mains dans le cambouis mais quel plaisir de pouvoir enfin me servir du bluetooth sans que les films saccadent et donc que ce soit inutilisable.
C'est trop cool. Je croyais que c'etais mon ordi qui faisait sentir son age mais non c'est pas c'est juste … pulseaudio.
# bogue ou bogues ?
Posté par arno_b . Évalué à 2. Dernière modification le 18 juin 2013 à 15:17.
Pourquoi "bogue" reste-t-il au singulier ? Un bogue est dénombrable il me semble.
"Correction de bogue" -> "Correction de bogues", Nan ?
De même, "corrections de bogue" -> "corrections de bogues"
[^] # Re: bogue ou bogues ?
Posté par claudex . Évalué à 3.
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
# Ouais, ben…
Posté par Anonyme . Évalué à 10. Dernière modification le 19 juin 2013 à 09:59.
Ou pas…
J'ai été forcé de basculer sur PulseAudio il y a quelques mois de cela, pour pouvoir faire fonctionner la dernière mouture de Skype qui sinon plantait (freeze en allant dans les options audio ou au moindre appel).
Le bilan de ces quelques mois est que :
J'ai même tenté une réinstallation toute propre, en me disant que – peut-être – j'avais mal fait les choses, et que Pulseaudio installé par défaut fonctionnerait certainement mieux. Que nenni !
Finalement, j'en ai eu marre. Il y a une semaine, j'ai purgé ma machine de toute trace de Pulseaudio. Depuis, je revis, c'est le rêve, un paradis ! Tout fonctionne de nouveau normalement ! Plus de souffle, plus de crachotements, plus de lag, un volume qui déchire les tympans des voisins si j'ai envie, plus de processus son qui me bouffe le CPU pour rien, j'ai retrouvé mes réglages de volume parfaits, j'ai du son dans toutes mes applications à la fois, plus aucun problème à lire mes vidéos, même quand je joue à WoW.
Reste plus que Skype, l'application de la joint-venture Microsoft/NSA, qui ne me servait de toute façon plus qu'à faire de la messagerie instantanée (avantageusement remplacée par les SMS, via AirDroid si nécessaire), et que je vais prochainement virer.
[^] # Re: Ouais, ben…
Posté par Renault (site web personnel) . Évalué à 3.
Tu utilises quelle distribution ?
Car le but d'une distribution est de réaliser l'intégration propre des logiciels qu'elle maintient et si PulseAudio est proposé, elle doit faire en sorte que les applications qui l'utilisent fonctionnent bien avec.
Fedora typiquement n'a plus de problèmes conséquents avec PA depuis un bon moment (après des débuts très délicats), et les autres ont pour la plupart suivis le pas.
PulseAudio est un composant bas niveau qui a des impacts sur de nombreux logiciels et couches du système, si son intégration se fait à l'arrache c'est normal que tout plante et ce n'est pas forcément de la faute du dit programme… Le fait que certains distributions ont réussi à corriger la plupart des problèmes qui tu mentionnes tend à faire croire que le problème est plutôt dans la distribution en elle même.
[^] # Re: Ouais, ben…
Posté par Anonyme . Évalué à 7. Dernière modification le 19 juin 2013 à 10:20.
Debian Testing.
Je n'ai strictement rien à reprocher à l'intégration des logiciels par Debian, avant Pulseaudio, tout allait bien, après Pulseaudio, tout allait bien. Et depuis des années que je suis dessus, jamais un véritable problème.
Ouais, mais Fedora non merci. Si c'est pour que Pulseaudio fonctionne mais que tout le reste ait des problèmes d'intégration… Fedora est bien trop instable à mon goût.
Quand un programme comme Pulseaudio entend révolutionner le son sous Linux et devenir LA référence, la moindre des choses, c'est qu'il arrive à faire mieux que la concurrence plus facilement.
Et là, c'est l'échec complet. J'ai beau avoir une certain bagage dans l'informatique, je ne me considère plus que comme un simple utilisateur avancé, je ne veux plus m'emmerder pour avoir un système qui fonctionne et que je puisse utiliser simplement pour faire les tâches les plus basiques qui soient.
Et de ce point de vue, Pulseaudio est une grosse merde ! Alsa ne m'a demandé strictement aucune configuration pour parfaitement fonctionner (allez, j'ai du fixer le canal PCM à 80% dans alsamixer parce que sinon le son à fond j'avais un léger souffle, trop de la bidouille c'est vrai…).
[^] # Re: Ouais, ben…
Posté par Renault (site web personnel) . Évalué à 2.
Je ne dis pas que Debian fait de la merde, amis elle peut sur un logiciel rater l'intégration, ce n'est pas exclu. Tu as regardé les rapports de bogues sur ta distribution pour voir si le problème était courant là bas ? Car cela serait triste que ton expérience sur le sujet n'aide pas à améliorer la situation.
T'inquiète pas, quand PulseAudio fonctionne directement (et c'est un cas assez courant maintenant), cela fonctionne très bien et c'est très puissant pour nombre de situations un peu plus complexe que d'avoir une seule paire d'enceinte. T'en fais pas qu'à l'usage il est bien intéressant et est facile. Seulement par essence le logiciel est plus complexe que Alsa et nécessite plus d'efforts d'intégration que Alsa pour que cela aboutisse proprement (et je signalerai qu'à la transition OSS-> ALSA il y a un paquet d'années, les problèmes de compatibilités ont été légions sans que ALSA soit réellement dénoncé comme le responsable).
Je n'ai pas touché à la configuration de PA depuis au moins 2 ans et cela fonctionne réellement sans problèmes. Il y a des problèmes c'est vrai mais ils sont de moins en moins rares et je t'invite à rapporter les bogues le cas échéant pour que cela ne se reproduise plus. ;)
[^] # Re: Ouais, ben…
Posté par Anonyme . Évalué à 3. Dernière modification le 19 juin 2013 à 10:43.
J'ai bien compris, et je ne l'exclu pas non plus, je ne tourne même pas en stable.
J'ai fouillé le net avec Google, j'ai testé diverses manips qui tenaient de la bidouille à l'aveugle, rien à faire ou situation pire (genre pousser l'amplification pulseaudio à plus de 100%).
Honnêtement, je n'ai plus la patience ni la passion pour m'investir à ce point dans le fonctionnement de ma machine. Je veux quelque chose qui simplement fonctionne au quotidien, sans avoir à me prendre la tête régulièrement. Éditer du fichier de config à tour de bras pour avoir un semblant de son, c'est un coup à me faire manger une pomme.
Les problèmes que m'a posé Pulseaudio sont d'autant plus rédhibitoires que sans lui tout fonctionne à merveille (et que dire de Pulseaudio qui désactive les haut-parleurs lorsqu'un casque est branché, tout ça sans offrir la possibilité de choisir simplement la sortie ?).
Si j'avais besoin d'un usage complexe du son, je pense que je me pencherais sur jackd. J'ai besoin d'un usage élémentaire du son, que le son fonctionne, qu'il exploite correctement mon matériel et me donne accès aux réglages matériels de ma carte son, qu'il mixe correctement le son de différentes applications simultanément, tout ça sans que je n'ai rien besoin de faire autre que bouger quelques jauges initialement, et celle du volume (Master) ensuite.
Je n'en ai rien à cirer de pouvoir gérer le son de chaque application indépendamment via pulseaudio, chaque application qui produit du son intègre déjà une propre jauge du volume si j'ai besoin de la gérer individuellement. Et en fait, toutes sont à 100%, et je ne joue que sur le volume général. Je n'en ai rien à cirer de pouvoir envoyer du son par le réseau, sur mes hypothétiques haut-parleurs bluetooth ou sur la lune, ça ne m'intéresse pas.
Complexe, le mot est faible. Pulseaudio est une usine à gaz de mon point de vue, et pas une qui sent bon.
Soit ta fangue à lourché, soit ton inconscient t'a trahi. :)
[^] # Re: Ouais, ben…
Posté par Renault (site web personnel) . Évalué à 3.
C'est bizarre, tu dis toi même que tu utilises une version non stable et tu te plains de ce genre de problèmes qui peuvent avoir pour origine ton choix de la version de la distribution. Quelqu'un qui utilise sciemment Debian-testing ne devrait pas au minima s'attendre à bidouiller à l'occasion et rapporter des bogues éventuels ?
Ses utilitaires permettent d'avoir le comportement que tu veux, je le sais car je le fais.
Son comportement par défaut reste logique (c'est rare de brancher un casque pour écouter ses hauts parleurs).
Il le fait très bien chez de nombreuses personnes.
Mine de rien, pourquoi ne pas en discuter sur le système de rapport de bogues de Debian ? Soit la distribution est fautive et dans ce cas ils vont bosser pour mieux l'intégrer, soit c'est un bogue de PulseAudio et ils le corrigeront. Dans les deux cas la communauté s'en sortirait avec un meilleur confort d'utilisation…
Je vais faire une critique qui n'est pas personnellement contre toi mais que je retrouve régulièrement. Ce n'est pas parce que tout le monde n'a pas besoin de toutes les options du logiciel qu'il faut virer ces dites fonctions. PA a de nombreuses options et possibilités qui sont très appréciées par ceux qui en ont besoin ou l'usage. Personnellement j'ai le même usage que toi mais je pense important que les autres aient la solution générique à leur besoin qui est une surcouche du notre.
Donc non, tu n'as pas besoin de PA pour ton cas, cela ne remet pas en cause son utilité en général seulement il faut travailler pour qu'il s'adapte à chaque situation.
Complexe ne signifie pas usine à gaz, ses fonctionnalités se limite au cas d'usage pour lequel il a été conçu et ne va pas au delà (ce n'est pas comme X11). Seulement PA est au centre de multiples interactions entre de nombreux composants logiciels ce qui implique forcément une intégration délicate et une certaine complexité du système.
Tu sais très bien que j'ai voulu dire que les problèmes sont de plus en plus rares, je me base non seulement sur mon expérience et celle de mon entourage mais aussi des endroits que je fréquente (le bugzilla de Fedora et les forums de la distribution posent de moins en moins de requêtes au sujet de PA ce qui est un bon indicateur de transparence et de bon fonctionnement).
[^] # Re: Ouais, ben…
Posté par Anonyme . Évalué à 2. Dernière modification le 19 juin 2013 à 11:18.
Avant d'être en testing, je suis longtemps resté en stable, et j'y avais déjà essayé Pulseaudio avant de le virer. Ce n'est que Skype 4.x qui m'a forcé à passer de nouveau à Pulseaudio il y a quelques mois.
Testing est parfaitement adaptée à ce que j'attends d'une distribution : un système qui se met à jour tout seul et avance lentement mais sûrement, avec des logiciels décemment à jour sans avoir à m'investir dans le déboguage, et qui très occasionnellement va peut-être m'occasionner un problème mineur qui sera très rapidement corrigé.
Ce n'est pas rare d'avoir une tour sous le bureau, et même s'il y a une prise casque en façade, c'est chiant d'avoir à se pencher pour débrancher le casque afin d'avoir du son sur les haut-parleurs. Avec Alsa, j'ai les deux branchés, quand je veux écouter avec mon casque je coupe les haut-parleurs, sinon je pose le casque sur le bureau et j'allume les haut-parleurs.
C'est donc une attente illogique que dans le cas d'un logiciel « complexe » comme Pulseaudio avoir la possibilité de choisir simplement la sortie son souhaitée (hp/casque/tout/etc.) en fonction du besoin ? Une simple liste déroulante dans les options c'est trop compliqué pour le complexe Pulseaudio ?
C'est une attente illogique qu'avant de vouloir balancer le son sur ses haut-parleurs bluetooth, on veuille avant tout pouvoir régler les volumes de son système surround et de son caisson de basses ?
Parce que je n'ai ni la patience, ni la passion. C'est comme pour tout, ce genre de choses s'érodent. Peut-être l'âge et les changements de priorité qui veulent ça.
Ce n'est pas parce que un pouillardième des utilisateurs se branle la nouille en écoutant sa musique qui crachote et lag sur ses haut-parleurs bluetooth qu'il faut pour autant imposer un fonctionnement de base dégradé à l'immense majorité des autres. La solution précédente fonctionnait bien mieux. C'est tout ce que je constate et qui m'importe en tant que simple utilisateur final.
Ou peut-être est-ce que de guerre lasse, la majorité a fini par faire comme moi, et a viré Pulseaudio ? :p
[^] # Re: Ouais, ben…
Posté par Renault (site web personnel) . Évalué à 4.
Mais l'utilitaire de PA permet de faire ça justement, je ne te parlais que du comportement par défaut…
[^] # Re: Ouais, ben…
Posté par Anonyme . Évalué à 5.
Tu parles de pavucontrol ?
Si c'est le cas, alors non. Il m'affiche bien quelques infos (genre je ne peux régler que les canaux droit et gauche, adieu le surround et les basses, je n'ai droit qu'à du audio interne stéréo analogique (et ce même sans le casque) et pour choix de sortie même s'il me liste bien « Sortie analogique » et « Casques analogiques », quand le casque est branché, rien ne sort sur les haut-parleurs, quelle que soit ma sélection.
[^] # Re: Ouais, ben…
Posté par Padishah . Évalué à 3. Dernière modification le 19 juin 2013 à 14:02.
PA se place entre ALSA et les applications. Et dans la majorité des cas, aujourd'hui, cela ne sert à rien puisqu'ALSA fait du mixage logciel. Donc sauf cas exotique, PA est totalement dispensable alors vouloir en faire le serveur de son de référence sous Linux…
[^] # Re: Ouais, ben…
Posté par xcomcmdr . Évalué à 3.
Effectivement, en général, ce n'est pas pour ça qu'on utilise PulseAudio. Sans aller jusqu'aux cas d'utilisation impliquant la diffusion du son par le réseau, voici quelques intérêts sur une utilisation de type desktop "grand public" :
- Éviter d'avoir le volume sonore globale qui change constamment. Je tiens à mes tympans, surtout quand j'ai des écouteurs dans les oreilles. Alors quand j'ai de la musique qui tourne avec le volume sonore à 35%, et que l'application X s'initialise et en profite pour mettre le volume à 100% et me péter les tympans, ça fait toujours plaisir (ou pas).
Et dans l'interface graphique pavucontrol plus spécifiquement :
- Pouvoir mettre une application en particulier à 100% (voire jusqu'à 150 % quand la piste sonore est basse) sans que tout le monde se retrouve à ce même niveau.
- Que ces états/niveaux sonores soient sauvegardés et restaurés automatiquement pour chaque application.
- Avoir un volume sonore différent pour les haut-parleurs, les écouteurs, le micro, …
- Configurer le volume en entrée pour les applications enregistrant du son (et là aussi c'est sauvegardé automatiquement).
Bref, tout ce que permet le mixer logiciel de Windows depuis Windows Vista (il y a pas que des mauvaises idées chez la concurrence).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ouais, ben…
Posté par Anonyme . Évalué à 1. Dernière modification le 19 juin 2013 à 16:25.
Je ne comprends pas trop, tu as une telle différence de niveau sonore entre tes applications, et ce de manière aussi aléatoire, que tu as davantage besoin de pulseaudio que des jauge de volume de chacune des applications en question ?
Personnellement, si j'avais besoin de retoucher les volumes, je le ferais dans kmix pour le micro ou le casque (qui ont des canaux spécifiques), et dans chacune des applications que j'utilise si besoin était, genre kaffeine, vlc, youtube, amarok, etc. qui conserve leur réglage entre chaque démarrage. Qu'apporte Pulseaudio qui n'existe pas déjà à ce niveau ?
Maintenant, pour être honnête, j'avoue que j'ai rarement besoin de retoucher le volume, j'ai l'impression que toutes mes applications sont grosso-modo au même niveau sonore. À moins que ce ne soit ma distribution qui intègre un système de normalisation audio ?
Toujours est-il que toutes mes applis ont le volume calé à 100%, j'ai réglé le micro pile poil pour que mon correspondant ait un son parfait, mon casque pour ne pas qu'il me pète les oreilles, et le reste, ben j'ai le master à 75%, et le bouton du volume de mes haut-parleurs à portée de main, ou mieux, les 3 touches de réglage (volume down, volume up, mute) sur mon clavier. Les rares fois où cela est nécessaire, en moins de deux le son est au niveau qui me convient.
Bref, à part une surcouche inutile et coûteuse en ressources, en plus d'être particulièrement inefficace, je ne vois pas ce qu'apporte Pulseaudio, clairement.
[^] # Re: Ouais, ben…
Posté par xcomcmdr . Évalué à 4. Dernière modification le 19 juin 2013 à 16:42.
PulseAudio m'évite d'avoir cet aspect aléatoire, justement.
Avec ALSA seul, tout le monde modifie constamment le volume globale, et tout le monde se réfère au volume globale.
A moins de bloquer le volume globale (ça semble possible avec alsamixer - ce qui n'est pas une solution très pratique non plus), je me fais régulièrement zigouiller les esgourdes.
Avec PA, c'est l'utilisateur qui maitrise le volume globale, et au besoin celui de chaque application, constamment et automatiquement.
Je n'ai pas de bidule pour gérer le volume sur mes écouteurs, ni sur mes hauts-parleurs. Et avoir le volume calé à 100% n'est pas une solution, du coup (comme par exemple certains musiques dans Audacious qui ont un volume plus fort que d'autres)
Pour moi c'est une surcouche légère, très pratique. Je maîtrise enfin le volume sonore globalement, et par applications, sans y revenir toutes les 5 minutes. Et j'ai enfin fini d'avoir un mixing audio des années 1990, cassé par dessus le marché.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ouais, ben…
Posté par Anonyme . Évalué à 1. Dernière modification le 19 juin 2013 à 17:09.
Je crois comprendre le problème que tu décris, et je ne le rencontre pas.
Par exemple, je viens de vérifier, si je touche à la jauge de volume de Kaffeine, aucune des jauges de kmix et encore moins celle du volume global (Master dans mon cas) n'est affectée. C'est uniquement le volume sonore de Kaffeine qui est changé. De même pour Clémentine, que je viens de vérifier, ainsi que Youtube (là rien d'étonnant). Pareil pour Amarok. Idem pour VLC.
Ton problème ne serait-il pas lié à une histoire d'option de mixer matériel/mixer logiciel que certaines applications proposent dans leurs préférences ? (genre surtout les applications Gnome, tel Gnome-Mplayer par exemple) L'un des choix reposant – je pense – sur le volume global, et l'autre gérant le volume de manière interne à l'application (pure hypothèse de ma part).
Justement non, je n'ai pas envie de réinstaller PA pour le confirmer, mais je crois bien me souvenir avoir été emmerdé, lorsque Pulseaudio était installé, par le fait que modifier le son dans Amarok/Kaffeine/etc. affectait directement mon canal Master. Mais bon, mes bidouillages avec Pulseaudio remontent à il y a quelques mois, et je ne me rappelle plus exactement des conditions dans lesquelles j'ai fait ces observations (et comme je disais, la flemme de réinstaller pour vérifier).
Je ne sais pas quel environnement de bureau tu utilises, mais si tu étais sous KDE, je te proposerais de faire un tour dans Configuration système -> Raccourcis et gestes -> Raccourcis globaux de clavier -> Kmix et là tu affectes une combinaison de touches pour Augmenter le volume (genre Méta + +), Diminuer le volume (genre Méta + -) et Muet (genre Méta + /), et à toi les fonctionnalités qui te manquent d'un clavier multimédia ou d'un potentiomètre ! :)
De même sans la surcouche PA. :)
[^] # Re: Ouais, ben…
Posté par xcomcmdr . Évalué à 1. Dernière modification le 19 juin 2013 à 17:34.
J'ai déjà xfce4-volumed (mixer gstreamer, qui appelle celui de ALSA), remplacé par xfce4-volumed-pulse (qui provient de Xubuntu) pour gérer le mute/unmute globale et le volume globale vite fait avec les touches [Fn]-[F10]/[F11]/F[12]. ;-)
Mais ça ne fait que utiliser ALSA ou PA, et non pas rajouter un contrôle de volume "analogique" (dans le même genre je n'ai pas de quoi éteindre mes hauts parleurs, c'est un ordi portable : donc pas de mute à moins de passer par un mixer logiciel ou d'éteindre l'ordi, ou de blacklister le module snd_hda_intel. C'est un peu trop permanent, tout ça…)
Intéressant. Quelle est ta distribution ?
Arch est connue pour être proche de l'upstream (on évite au maximum les patchs maison).
J'en sais rien. J'ai bien pourtant un mixing logiciel ou matériel quelque part, vu que sans rien faire, et avec ALSA seul, j'ai le son de plusieurs applications en même temps sans problème.
En tout cas c'était bel et bien toutes les applications : SMPlayer, Audacious, Flash, Parole, DOSBox, …
Seul Audacious (un clone de XMMS) me permet d'utiliser un mixing logciel propre à Audacious. Cette option est déconseillée (et je crois comprendre pourquoi, vu qu'elle introduit de la latence : le nouveau volume met quelque temps à être effectif, et le contrôle du volume d'Audacious répond moins vite).
Avec ALSA seul, ça évite de modifier le volume globale quand je modifie le volume d'Audacious. C'est cool, mais c'est pour une seule application.
Avec PA, ça sert juste à ce que la modification du volume d'Audacious ne modifie pas le volume de l'application dans PA (le volume d'Audacious est bien modifié, c'est juste qu'Audacious n"utilise plus PA pour son volume sonore).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ouais, ben…
Posté par ariasuni . Évalué à 1.
https://wiki.archlinux.org/index.php/Pulseaudio#Clients_alter_master_output_volume_.28aka_volume_jumps_to_100.25_after_running_appliaction.29
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Ouais, ben…
Posté par Adrien . Évalué à 5.
J'ajouterais trois autres avantages pour Pulseaudio :
– pouvoir gérer le volume de toutes les applications en un seul endroit, dans kmix par ex.
– la suppression de l'echo, indispensable pour les applications de VoIP
– l'aspect réseau, pour envoyer le son sur une autre machine. Ça nécessite un peu de manip, mais c'est quand même vachement pratique quand tu as plusieurs ordinateurs dans une maison.
Sur le papier, le module-role-ducking à l'air très intéressant. On est effectivement à des années lumières de la gestion du son par ALSA.
[^] # Re: Ouais, ben…
Posté par Albert_ . Évalué à 1.
– pouvoir gérer le volume de toutes les applications en un seul endroit, dans kmix par ex.
Ca marche aussi dans kmix avec Alsa seul.
Sur le papier, le module-role-ducking à l'air très intéressant. On est effectivement à des années lumières de la gestion du son par ALSA.
Ben disons que en dehors de prendre du CPU et de faire saccader la lecture video quand je le connecte au bluetooth (alors que avec Alsa seul il n'y a pas de probleme) c'est genial comme truc mais pas pour MON utilisation basic…
[^] # Re: Ouais, ben…
Posté par ariasuni . Évalué à 2.
T'utilises ALSA en BASIC?
→ […]
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Ouais, ben…
Posté par briaeros007 . Évalué à 2.
Je n'ai jamais compris cette aspect "d'intégration" d'un serveur.
L'intégration d'une gui pour qu'elle offre un look& feel et une ergonomie identique au reste du système je comprend.
L'intégration d'un soft dans une infrastrucure (réseau, autres logiciels, …) aussi je comprends
Mais là on parle d'un soft qui
-> en entrée a son propre connecteur et protocoel
-> en sortie utilise le noyau linux et plus précisément la couche alsa, qui est standard
Il peut y avoir quelle intégration avec ça ?
[^] # Re: Ouais, ben…
Posté par Renault (site web personnel) . Évalué à 3.
Il faut s'assurer que tous les composants qui sont liés à PulseAudio de près et de loin ne sont pas impactés par sa présence. Mais aussi il faut que toutes ces applications exploitent les possibilités de PA au mieux.
Tu n'es pas naïf au point de croire que parce qu'il y a des I/O standards pour les dialogues entre certains composants du système qu'aucun effet de bords est possible ? Un logiciel tel que PA demande beaucoup d'effort d'intégration car de nombreuses applications y sont touchées (celles susceptibles de fournir du son), dans une couche intermédiaire et qui doit dialoguer avec de nombreux composants distincts pour réaliser sa tâche.
Ce n'est vraiment pas si simple et une distribution doit gérer cet aspect.
[^] # Re: Ouais, ben…
Posté par briaeros007 . Évalué à 4.
Le respect des standard et des protocoles sert à ça.
Je suis "naif" car quand un soft est bien codé, il n'y a presque pas d'effet de bord.
Je n'ai encore jamais eu à "intégrer" un apache avec un firefox.
Et si j'ai un quelconque problème, je regarde qui ne respecte pas le standard ietf.
C'est quand même marrant où 99% des softs "daemon" fonctionnent sans avoir besoin d'intégration poussé (le chemin des fichiers de conf, et les scripts d'init et c'est à peu près tout), mais que pour 1%, sans raison, l'intégration ressemble à du voudou (le soft fonctionne mais prend bizarrement 15% du cpu sans raison à un moment X, …)
Pour prendre une comparaison automobile : quand je met un sac dans mon coffre, je ne m'attend pas à devoir changer de bouchon de radiateur.
euh faut pas déconner, elles communiquent avec PA avec le "langage" propre à PA (ie son api)
Si il n'est pas capable de comprendre son propre "langage" sans avoir besoin qu'on le bichonne, c'est qu'elle est mal codé, point.
[^] # Re: Ouais, ben…
Posté par bayo . Évalué à 2.
Ahahah énorme ! C'est ptêtre bien un problème d'intégration. Cela dit c'est curieux qu'ils ne proposent pas d'autres connecteurs que PA.
Je suis tombé sur ce bout de FAQ qui indique comment utiliser ALSA si ça peut aider.
[^] # Re: Ouais, ben…
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Bonjour,
si audio intel, alors
SND_HDA_PREALLOC
de rien.
# c>n|k
Posté par Doug Le Tough (site web personnel) . Évalué à 3.
C'est malin, tu me dois un clavier !
[^] # Re: c>n|k
Posté par Jarvis . Évalué à 1.
Ce n'est pas bayo qui a écrit ce passage à troll. Je connais le coupable mais je ne dénonce jamais.
[^] # Re: c>n|k
Posté par antistress (site web personnel) . Évalué à 2.
Et tu fais bien, l'auteur pourrait en dénoncer d'autres à son tour ;)
[^] # Re: c>n|k
Posté par bayo . Évalué à 1.
J'avais bien compris ma condition de fusible… il est de combien le turnover de pseudo chez linuxfr ?
[^] # Re: c>n|k
Posté par antistress (site web personnel) . Évalué à 2.
La prochaine fois on signera "Lennart" ces dépêches sur PulseAudio et Systemd
# Pour y voir plus clair
Posté par antistress (site web personnel) . Évalué à 2.
J'ai trouvé cet article avec cette illustration :
En fait faudrait lancer sur Wikipédia une page Pile son Linux comme celle de la Pile graphique Linux
[^] # Re: Pour y voir plus clair
Posté par antistress (site web personnel) . Évalué à 3. Dernière modification le 20 juin 2013 à 02:47.
D'ailleurs, "Pile son Linux" ou "Pile sonore Linux" ou "Pile audio Linux" ?
[^] # Re: Pour y voir plus clair
Posté par claudex . Évalué à 3.
C'est un peu bizarre comme illustration. Xine n'utilise pas Gstreamer et Phonon n'est pas obligatoire (c'est spécifique KDE/Qt).
« 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: Pour y voir plus clair
Posté par ariasuni . Évalué à 1.
Oui normalement Phonon peut utiliser Xine, Gstreamer ou VLC, Gstreamer et Xine peuvent communiquer avec ALSA ou OSS ainsi que PulseAudio pour Gstreamer.
Donc c’est n’importe quoi™.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pour y voir plus clair
Posté par bayo . Évalué à 2.
C'est un schéma simplifié pour ressembler à une pile. C'est pédagogique, mais je doute qu'il y ai vraiment des belles couches et tout.
Pour les faignants, la vraie « pile » est beaucoup plus sexy…
[^] # Re: Pour y voir plus clair
Posté par antistress (site web personnel) . Évalué à 5.
Ce schéma aurait été fait avec objectif de décrédibiliser la pile son Linux d'après ce que j'ai pu en lire, en étant inutilement et partialement complexe
[^] # Re: Pour y voir plus clair
Posté par antistress (site web personnel) . Évalué à 2.
(par Adobe) http://blogs.adobe.com/penguinswf/2007/05/welcome_to_the_jungle.html
[^] # Re: Pour y voir plus clair
Posté par ariasuni . Évalué à 3.
Oui il y a pleins de flèches en trop (des flèches entre ALSA et OSS?!?), Xine a été renplacé partout par Gstreamer, ESD a été abandonné depuis un moment par GNOME, OSS n'est plus utilisé sous Linux depuis belle lurette, aRts n'est plus maintenu depuis 2004.
Sans tout ça, le nombre de flèches est divisé par deux.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pour y voir plus clair
Posté par Moonz . Évalué à 3.
Oui, Alsa peut utiliser OSS (Alsa -> OSS -> output device) tout comme une application OSS peut « utiliser » alsa (via la couche de compatibilité).
[^] # Re: Pour y voir plus clair
Posté par ariasuni . Évalué à 1.
C'est utilisé ça? Je veux dire, de nos jours où on utilise Gstreamer & co?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pour y voir plus clair
Posté par Moonz . Évalué à 2.
OSSv4 est à nouveau libre, dispo sous Linux, et a quelques fonctionnalités en plus que Alsa (dont un niveau de son par application, comme PulseAudio). Donc certains l’utilisent, oui.
[^] # Re: Pour y voir plus clair
Posté par ariasuni . Évalué à 1.
Bah j'ai l'impression que c'est assez rare, et je ne suis pas né assez tôt pour avoir vécu la transition d'OSS à ALSA. J'essaierais OSS à l'occasion, mais c'est à peu près équivalent à ALSA non?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pour y voir plus clair
Posté par ariasuni . Évalué à 1.
Il y a une bonne comparaison entre OSS et ALSA sur le wiki d’Arch Linux.
Néanmoins, quand je vois que la documentation n’a pas été mis à jour depuis 2007, qu’aucune version n’est sortie depuis 19 mois et aucune modification n’a eu lieu depuis 15 mois et que la liste de diffusion pointe vers /dev/null, ça donne quand même pas très envie.
Mais!?! Il y a une annonce de nouvelle version qui date de Juin 2013!?! Un gros bordel.
Je testerais à l’occasion (les fonctionnalités ont l’air intéressantes), mais demain j’ai contrôle donc vaut mieux que je reste pas jusqu’à 3h du mat’ à bidouiller mon serveur de son! xD
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pour y voir plus clair
Posté par antistress (site web personnel) . Évalué à 2.
Mais il reste d'actualité pour Enlightenment ?
[^] # Re: Pour y voir plus clair
Posté par ariasuni . Évalué à 2.
Je ne trouve pas de paquet pour esd ni sur Debian ni sur Arch, à part un paquet sur AUR qui n'a pas été mis à jour depuis janvier 2009.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pour y voir plus clair
Posté par antistress (site web personnel) . Évalué à 3.
bon ben c'est vraiment obsolète alors
[^] # Re: Pour y voir plus clair
Posté par Moonz . Évalué à 4.
C’est pas une pile audio, c’est une liste de libs audio avec des flèches indiquant qui peut utiliser quoi comme backend juste pour faire croire que c’est compliqué.
Remplace Alsa par CoreAudio et le schéma est tout aussi valide sous MacOS X (à une ou deux exceptions).
[^] # Re: Pour y voir plus clair
Posté par bayo . Évalué à 3.
Je sais, mais ça montre bien qu'il n'y a pas de pile audio sous Linux. Tout le monde fait tout pour tout le monde avec des connecteurs qui vont bien au cas ou.
[^] # Re: Pour y voir plus clair
Posté par Moonz . Évalué à 5. Dernière modification le 20 juin 2013 à 13:57.
Et c’est un problème, parce que… ?
Et en quoi est-ce spécifique à Linux ? Phonon, SDL, Xine, Gstreamer que tu retrouves dans le schéma fonctionnent aussi sous Windows. Windows qui lui-même a plusieurs API audio (DirectSound, Core Audio API, DirectMusic…)
[^] # Re: Pour y voir plus clair
Posté par bayo . Évalué à 1.
Ai-je dit que c'en était un ?
[^] # Re: Pour y voir plus clair
Posté par bayo . Évalué à 1. Dernière modification le 20 juin 2013 à 14:02.
oups dup
# JACK
Posté par Marotte ⛧ . Évalué à 2.
Pourquoi ne pas utiliser JACK (avec ALSA comme backend) par défaut sous GNU/Linux. La plupart des utilisateurs n'ont pas besoin des fonctionnalités de routage entre applications que propose JACK mais partant du principe que « qui peut le plus peut le moins » pourquoi pas ?
Est-ce que c'est parce que trop peu d'applications supportent JACK ? Est-ce parce qu'il « bouge » encore trop ?
[^] # Re: JACK
Posté par ariasuni . Évalué à 2.
Parce qu'il pompe toute les ressources pour faire du temps réel. Et depuis le temps que Jack existe on a eu le temps de réfléchir à la mise en place de Jack par défaut.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: JACK
Posté par Marotte ⛧ . Évalué à 2.
JACK peut fonctionner en temps réel mais ce n'est pas obligatoire.
Bah oui, d'où ma question : Pourquoi ? Comme je dis, le coup du temps réel ce n'est pas une raison.
[^] # Re: JACK
Posté par bayo . Évalué à 4.
De ce que j'ai lu, je n'ai jamais bidouillé à aussi bas niveau.
JACK est fait pour de la faible latence ce qui est plus gourmand en CPU. Paradoxalement l'API est bien plus simple que PulseAudio.
Normalement PulseAudio a été architecturé pour réduire son emprunte sur le CPU, c'est ce qu'on attend d'une utilisation grand public : il va adapter les latences à juste ce qu'il faut ; il ne va se réveiller que lorsque c'est nécessaire ; il peut utiliser des algo mois coûteux.
Pour les API, je pense qu'elles sont toutes deux extrêmement stable. Il y a tellement de trucs qui reposent sur les deux que j'espère pour eux…
# Page "Pile audio Linux" sur Wikipédia
Posté par antistress (site web personnel) . Évalué à 3.
Allez, ne soyez pas timides, il serait dommage de laisser tout ce savoir inexploité, aidez à compléter la page Pile audio Linux de Wikipédia !
# ca pulse in the place ?
Posté par mlinux . Évalué à 3.
hello :)
du coup je me demandai :
quelles sont les distros qui n'utilisent pas encore pulse audio ?
les polémiques sur Pottering c'est fini ? C'était de la résistance au changement ?
# Finalement, tout baigne avec la pile audio de Linux ?
Posté par antistress (site web personnel) . Évalué à 3.
Je vois PulseAudio évoluer, certains composants devenir obsolètes sous Linux (ESD, OSS, Xine, aRts, Phonon).
Au final la pile audio n'est plus si compliquée si je comprends bien, avec essentiellement :
En plus je comprends que PulseAudio est assez polyvalent (notamment sur les latences)
Du coup, on est plus à la ramasse par rapport à Windows/MacOS ?
[^] # Re: Finalement, tout baigne avec la pile audio de Linux ?
Posté par wismerhill . Évalué à 5.
Phonon n'est pas obsolète, c'est la couche d'abstraction de KDE4, et ça le sera probablement encore dans le framework 5.
[^] # Re: Finalement, tout baigne avec la pile audio de Linux ?
Posté par karteum59 . Évalué à 2.
Et y'a aussi OSSv4 qui juste marche…
# comparaison à sndio (OpenBSD)
Posté par TeXitoi (site web personnel) . Évalué à 1.
Est-ce que quelqu'un est capable de comparer jack et pulseaudio au système de son d'OpenBSD (sndio) ? Par curiosité, car sndio a l'air pas mal dans le genre, sûrement beaucoup plus simple, possiblement plus gourmand en ressources.
http://www.sndio.org/
[^] # Re: comparaison à sndio (OpenBSD)
Posté par ariasuni . Évalué à 1.
Ah ouais, ça peut être intéressant… Mais bon le premier lien pointe vers http://www.opebsd.org/. Ça la fout mal quand même. (j’ai envoyé un courriel à l’auteur)
Mais pourquoi faire un nouveau système de son? Sans doute parce que malgré ses qualités OSS est trop limité au niveau des fonctionnalités (ce pourquoi on pousse ALSA et PulseAudio sous GNU/Linux).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: comparaison à sndio (OpenBSD)
Posté par Albert_ . Évalué à 2.
Mais pourquoi faire un nouveau système de son? Sans doute parce que malgré ses qualités OSS est trop limité au niveau des fonctionnalités (ce pourquoi on pousse ALSA et PulseAudio sous GNU/Linux).
Euh… Alsa a remplace OSS dans le kernel a cause d'une histoire de licence.
[^] # Re: comparaison à sndio (OpenBSD)
Posté par ariasuni . Évalué à 1.
J’ai pas dit le contraire, mais actuellement pourquoi on n’a pas OSS dans le noyau Linux vu que la version 4 est libre?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: comparaison à sndio (OpenBSD)
Posté par wismerhill . Évalué à 2.
Ben, est-ce que les développeurs d'OSS4 veulent qu'il soit intégré au noyau?
[^] # Re: comparaison à sndio (OpenBSD)
Posté par ariasuni . Évalué à 0.
Est-ce que les utilisateurs de Linux veulent que ça soit intégré à Linux?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: comparaison à sndio (OpenBSD)
Posté par wismerhill . Évalué à 2.
On s'en fout, si les développeurs ne veulent pas, ça ne se fera pas.
[^] # Re: comparaison à sndio (OpenBSD)
Posté par ariasuni . Évalué à 1.
Ce que je veux c’est que si OSSv4 était si génial que ça il serait déjà par défaut dans Linux nan? Je dis pas que c’est naze, mais comme PulseAudio ça correspond à des usages plus modernes de l’audio, même si ça s’accompagne d’une plus forte latence et de pile audio plus lourde.
Écrit en Bépo selon l’orthographe de 1990
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.