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é.
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…
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.
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.
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.
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.
Si tu lisais le journal, tu éviterais de faire des commentaires "bateau", JACK est en espace utilisateur, ce qui a un surcoût en latence donc pour compenser il faut diminuer la taille des buffers d'où une utilisation de CPU importante.
JACK ne crée PAS de latence supplémentaire, et ça n'a de toutes façons rien a voir avec le fait qu'il travail en espace utilisateur. C'est la taille du tampon et le taux d’échantillonnage qui influent sur la latence : latence ∝ taille_tampon / taux_échantillonnage.
Si c'était aussi simple… OSS et ALSA (et FFADO) sont les couches d'abstraction au matériel (pilotes) mais pas que ! Pour OSS je sais pas mais ALSA (via dmix) permet de faire du mixage logiciel (et du mixage matériel aussi pour certaines cartes).
Dans la famille des serveurs de son tu oublit un peu vite les ESD et autres aRts… Note, ils reposent tous soit sur ALSA soit sur OSS (voir sur FFADO).
Tout le reste cause soit à ALSA/OSS directement, soit à un des serveurs, soit croit parler à ALSA/OSS (voir même ESD/…) mais crache ses dB à une couche de compatibilitée fourni par l'un des serveurs. Selon le cas (GStreamer par exemple), ils peuvent aussi fournir des fonctions de mixage.
Phonon, qui est sans doute l'API de plus haut niveau, fourni un service unifié au dessus de tout ça. On peut tout de même lui faire le reproche de ne faire qu'ajouter une couche au bord** exitant…
Non.
Jack n'a clairement pas une vocation bureautique ! C'est un serveur à destination des pros, par des pros pour du matos de pros. Je veux bien qu'on me donne la plus-value qu'on peut lui trouver pour écouter son clip préféré sur YouTube depuis FireFox…
Pulseaudio est là pour ça (qui utilise d'ailleur souvent ALSA sous linux). Et soyons honnête, s'il a connu des déboires à son lancement, il est aujourd'hui robuste. Si on regarde le journal d'activité du greffon Pulseaudio de GStreamer, on peux répondre à M. Melanson que des solutions simples ne sont pas hors de portée !
Il faut bien reconnaitre le m***** de le pile audio Linux. Mais si les vieillards voulaient bien mourrir gentillement, ALSA se cantonner a une couche de streaming et les utilisateurs oublier leurs sales préjugés autour de Pulseaudio, on y verrait plus clair !
Non ?
# Près de Chez Nous
Posté par tchaik . En réponse à la dépêche Un annuaire des producteurs locaux en Open-Source. Évalué à 5 (+4/-0).
Dans l'existant il y a aussi Près de Chez Nous, une initiative du Mouvement Colibris, Le Marché Citoyen et d'OpenAtlas qui ont fusionné leurs bases de données respectives et développé l'outil de carto. libre GoGoCarto (plus de détails sur leur site). Je ne connais pas l'état d'activité du projet cependant…
[^] # Re: Bitwarden
Posté par tchaik . En réponse à la dépêche KeePass, ou apprendre à gérer correctement ses mots de passe. Évalué à 5.
Et Passbolt aussi !
[^] # Re: Le CERN
Posté par tchaik . En réponse au journal Qui fait des trucs "cools" en France et en Europe?. Évalué à 2.
En effet : http://www.joaquimrocha.com/2015/09/01/announcing-libradosfs/
[^] # Re: Réinventer la roue, NIH ?
Posté par tchaik . En réponse à la dépêche systemd 208 : logind et Wayland. Évalué à 10.
Overview > premier point
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par tchaik . En réponse à la dépêche Sortie de PulseAudio 4.0. É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 tchaik . En réponse à la dépêche Sortie de PulseAudio 4.0. É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 tchaik . En réponse à la dépêche Sortie de PulseAudio 4.0. É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 tchaik . En réponse à la dépêche Sortie de PulseAudio 4.0. Évalué à 3.
Oui, et le magicien s'appelle bluez-alsa probablement.
[^] # Re: PulseAudio / ALSA
Posté par tchaik . En réponse à la dépêche Sortie de PulseAudio 4.0. É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.
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par tchaik . En réponse à la dépêche Sortie de PulseAudio 4.0. É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: PulseAudio / ALSA
Posté par tchaik . En réponse à la dépêche Sortie de PulseAudio 4.0. Évalué à 4.
C'est quoi l'intérêt d'utiliser dmix, aujourd'hui, alors que PulseAudio s'occupe du mixage logiciel ?
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par tchaik . En réponse à la dépêche Sortie de PulseAudio 4.0. É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.
# Teach me master
Posté par tchaik . En réponse au journal Recette pour burgers. Évalué à 6.
Mouah ah ah !
[^] # Re: Jack et le temps réel
Posté par tchaik . En réponse à la dépêche KLANG - Kernel Level Audio Next Generation. Évalué à 0.
JACK ne crée PAS de latence supplémentaire, et ça n'a de toutes façons rien a voir avec le fait qu'il travail en espace utilisateur. C'est la taille du tampon et le taux d’échantillonnage qui influent sur la latence : latence ∝ taille_tampon / taux_échantillonnage.
# Paul Davis se fâche
Posté par tchaik . En réponse à la dépêche KLANG - Kernel Level Audio Next Generation. Évalué à 10.
Réaction de Paul Davis, développeur principal de Ardour (station audio-numérique à vocation professionnelle) :
> http://ardour.org/pd_on_klang
Le fil de discussion sur la linux-audio-mailing-list :
> http://lalists.stanford.edu/lau/2012/08/
[^] # Re: confusions sur le son
Posté par tchaik . En réponse au journal Linux a des défauts sur le bureau. Évalué à 2. Dernière modification le 27 juillet 2012 à 09:10.
Pulseaudio est multi-plateformes.
Phonon ne cause pas directement ni à ALSA ni à OSS…
[^] # Re: confusions sur le son
Posté par tchaik . En réponse au journal Linux a des défauts sur le bureau. Évalué à 3.
Si c'était aussi simple… OSS et ALSA (et FFADO) sont les couches d'abstraction au matériel (pilotes) mais pas que ! Pour OSS je sais pas mais ALSA (via dmix) permet de faire du mixage logiciel (et du mixage matériel aussi pour certaines cartes).
Dans la famille des serveurs de son tu oublit un peu vite les ESD et autres aRts… Note, ils reposent tous soit sur ALSA soit sur OSS (voir sur FFADO).
Tout le reste cause soit à ALSA/OSS directement, soit à un des serveurs, soit croit parler à ALSA/OSS (voir même ESD/…) mais crache ses dB à une couche de compatibilitée fourni par l'un des serveurs. Selon le cas (GStreamer par exemple), ils peuvent aussi fournir des fonctions de mixage.
Phonon, qui est sans doute l'API de plus haut niveau, fourni un service unifié au dessus de tout ça. On peut tout de même lui faire le reproche de ne faire qu'ajouter une couche au bord** exitant…
[^] # Re: son
Posté par tchaik . En réponse au journal Linux a des défauts sur le bureau. Évalué à 6.
Non.
Jack n'a clairement pas une vocation bureautique ! C'est un serveur à destination des pros, par des pros pour du matos de pros. Je veux bien qu'on me donne la plus-value qu'on peut lui trouver pour écouter son clip préféré sur YouTube depuis FireFox…
Pulseaudio est là pour ça (qui utilise d'ailleur souvent ALSA sous linux). Et soyons honnête, s'il a connu des déboires à son lancement, il est aujourd'hui robuste. Si on regarde le journal d'activité du greffon Pulseaudio de GStreamer, on peux répondre à M. Melanson que des solutions simples ne sont pas hors de portée !
Il faut bien reconnaitre le m***** de le pile audio Linux. Mais si les vieillards voulaient bien mourrir gentillement, ALSA se cantonner a une couche de streaming et les utilisateurs oublier leurs sales préjugés autour de Pulseaudio, on y verrait plus clair !
Non ?