seb24 a écritCa vient du fait que PulseAudio doit à terme simplifier l'ensemble de la gestion du son sous GNU/Linux.
C'est bien là un des problèmes : Pulseaudio est présenté comme LE système audio universel pour linux, alors qu'il ne l'est pas. Par exemple, il ne gère pas l'aspect matériel de la chaîne audio. C'est à dire qu'il n'accède pas directement aux composants, et s'appuie pour cela sur les couches Alsa et OSS. C'est d'ailleurs pour cela que Pulseaudio ne sait pas exploiter toutes les possibilités offertes par les carte audio, comme les mixeurs matériels; tout ce qu'il sait faire, c'est déclarer une interface virtuelle et demander à ce qu'on lui envoi le son dessus (je simplifie; pour ceux que ça intéresse il existe des articles très complets dans les archives des ML). Il propose alors aux applications d'utiliser ses API afin de distribuer le son au reste du système (ce qui veut dire qu'il faut développer des produits en ayant Pulseaudio en tête)
Là où ça coince, c'est que les mécanismes existant offrent déjà toutes les fonctionnalités de Pulseaudio : mixage, distribution, accès concurrents, etc. D'où cette question qui reste toujours : pourquoi un système audio de plus alors qu'il en existe déjà deux majeurs qui tournent depuis des années ? Et qui plus est, pouvant prendre en charge la totalité de la chaîne audio ?
Pour synthétiser : utiliser Pulse audio oblige à utiliser Alsa; mais Alsa est capable de proposer tous les services nécessaires. Donc quel est l'intérêt de Pulseaudio par rapport aux éléments existants ? Si tu as uen réponse de Canonical, faut la faire tourner 🙂
Déjà il me semble que OSS à était éjecté définitivement pour Lucid, ou ca le sera d'ici peu.
Ola non, surtout pas. OSS4 est bien présent, aucun soucis de ce côté. Pas mal de choses dépendent d'OSS pour sa gestion du matériel. Alsa et lui se recouvrent largement, mais OSS a la capacité d'exploiter des firmwares spécifiques à du matériel audio qui ne peuvent être pris en charge par rien d'autre pour le moment.
