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?
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.
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 ...