Quel est le lien entre ALSA et PulseAudio?


30

Tout en essayant de faire fonctionner mon son , je me posais des questions sur les rôles d'ALSA et de PulseAudio. J'ai tous les deux installé et je me demandais, par exemple, lequel d'entre eux avait besoin de connaître ma carte son.

Les deux semblent pouvoir s'utiliser, il y a un plugin pulseaudio pour ALSA, et sur mon système, alsa apparaît comme une carte son dans pulseaudio.

Laquelle des deux fait quoi, sont-elles alternatives ou complémentaires?

Réponses:


32

ALSA est le mélangeur de sons au niveau du noyau, il gère directement votre carte son. ALSA à lui seul ne peut gérer qu'une seule application à la fois. Bien sûr, il existe « dmix », qui a été écrit pour résoudre ce problème. (C'est un module ALSA.)

PulseAudio est un mélangeur de logiciels, au sommet de l'espace utilisateur (comme si vous exécutiez une application). Lorsqu'il s'exécute, il utilise Alsa - sans dmix - et gère tous les types de mixage, les appareils, les périphériques réseau, tout par lui-même.

En 2014, vous pouvez toujours exécuter uniquement ALSA. Mais à moins que vous ne compiliez vos applications pour vous-même et que vous n'activiez le support ALSA partout - ou que vous n'utilisiez une distribution basée sur la source comme Gentoo - vous risquez de rencontrer des problèmes de mixage. Les applications pré-compilées fournies par les distributions ne sont généralement construites qu'avec la prise en charge de Pulseaudio, et non de l'ALSA pur. Ubuntu préfère par exemple PulseAudio. Il est livré avec PulseAudio par défaut, donc chaque application est compilée pour utiliser uniquement PulseAudio.

PulseAudio a ses avantages. Les gens disent que c'est bon pour travailler avec de l'audio sur un réseau, et cela résout certains problèmes avec les flux audio multicanaux qui se sont produits sous ALSA pur. Il est également censé être plus facile de développer des applications pour PA. Du côté de l'utilisateur final, il est facile de sélectionner de nouveaux appareils, de contrôler le volume par application, etc.

Cependant, dans la configuration par défaut, il ajoute une latence non négligeable au mixage. C'est un gros problème pour certains types de tâches qui nécessitent une faible latence comme certains jeux et logiciels.

OSS est une alternative à ces deux, mais il n'est pas sous licence GPL, ce qui rend peu susceptible d'être adopté par les distributions.

Illustration :
systèmes de son typiques alimentés par PulseAudio, comme Ubuntu:
Kernel: ALSA -> Userland: PulseAudio -> app1, app2, app3
Dans le système Linux typique, PulseAudio mixe l'audio de toutes vos différentes applications et les transmet à ALSA.

ALSA:
Kernel: ALSA -> dmix -> Userland: app1, app2, app3
Avec ALSA pur, vous avez besoin de dmix pour mélanger plusieurs applications. Sans cela, ALSA ne peut lire qu'un flux audio à partir d'une application à la fois.

OSS:
Kernel: OSS -> Userland: app1, app2, app3
Avec OSS, les applications de l' espace utilisateur parlent directement à OSS dans le noyau, qui mélange les flux lui-même.

Donc, pour résumer, dans votre système typique de nos jours, ALSA parle directement à vos cartes son, et Pulseaudio parle à vos applications et programmes et les alimente dans ALSA.


2
En fait, chaque fois que je trouvais Pulseaudio, je trouvais des PROBLÈMES! Le plus drôle, c'est qu'il semble (au moins sur la base de mes expériences) avoir aussi des problèmes avec la version RT du noyau, c'est-à-dire ... voulez-vous un environnement linux facile pour jouer de la musique? Pensez-vous au nouveau UbuntuStudio? Eh bien,
détrompez-vous

4
Oh ne pense pas. Les graphiques sont aussi une pile de .. Linux n'est PAS pour une utilisation de bureau pour le dire simplement et sans ambages. Xorg est un serveur X, donc vous démarrez un SERVEUR et vous le regardez (quelle absurdité? Ouais). Sur MAC, Windows, Haiku, l'interface graphique fonctionne à partir du noyau (d'accord, c'est à l'intérieur du noyau). Bien. Cela aurait du sens n'est-ce pas? De plus, il n'y a pas d'interface native. Comme sous Windows, Windows.Forms. Sur MAC Cocoa. Ici, vous ne pouvez utiliser que des kits d'outils FAT, comme GTK, Qt. | Le réseau est convenu, son noyau, son OK (d'accord si le fabricant fournit un bon pilote comme Intel le fait) ... donc c'est tout.
Apache

3
On MAC, Windows, Haiku, GUI runs from the kernel (okay its inside the kernel). Well. It would make sense doesnt it? En fait, ce n'est pas le cas. Vous vous souvenez du mauvais vieux temps des "pilotes vidéo NT 4 qui ont chié le système"? Oui, c'est ce qui l'a causé - exécuter des pilotes de merde dans l'espace du noyau. À votre avis, pourquoi Microsoft a-t-il soudainement décidé de faire entrer des pilotes signés dans Windows? Bingo! Parce que les pilotes minables causaient des plantages du système. Obtenir les a signés voulu les y obtenir sélectionnés , et un smidgeon d'AQ va un long chemin ...
Avery Payne

1
Avery: Il prend désormais en charge les modules déchargeables. Donc, s'il se bloque, il rechargera simplement le module pour l'adaptateur graphique. Mais pour autant que je sache, ce sont toujours des modules. (Ne fonctionne pas dans l'espace utilisateur .. c'est impossible). | À propos de SDL: Il s..ks. Chaque auteur de jeu s'en plaint car cela donne des performances lentes, des problèmes compliqués, etc. (je ne les énumérerai pas, vérifiez par le biais d'une recherche.)
Apache

2
@Skiki - Je me rends compte que la réponse est obsolète maintenant, mais pouvez-vous s'il vous plaît fournir des références où Valve a abandonné Linux? Autant que je puisse voir, ils avancent encore à plein régime, faites attention au jeu de mots.
aggregate1166877
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.