Si j'ai bien compris, ça faisait longtemps qu'OSS était émulé au dessus d'ALSA, mais l'émulation était faite dans le noyau. Or c'est quelque chose de compliqué, lourd et bogué. Et puis, personne ne voulait plus le maintenir. J'ai bon ?
En fait dès que OSS est passé en source fermées, il est simultanément devenu très problématique au niveau technique.
De façon générale OSS considère qu'il ne devrait y avoir qu'une seule API qui gouverne le Hardware en mode kernel et qui soit accessible via les fonctions POSIX d'accès fichier de base, avec juste une modification pour savoir si il y a du changement de fréquence ou pas. Ensuite charge à l'appli et au noyal de se démerder pour que le buffer son ne se remplisse pas et qu'il se vide correctement et dans les temps.
Pour Alsa c'est assez différent, en fait on peut aussi accéder aux son Alsa via les méthodes POSIX de base, ou via 250 000 autres interfaces ou méthodes dont au moins 6 sont doccumentées. Alsa est conçu pour ne pas faire de lock exclusif en mode kernel du hardware (du moins en théorie, parcequ'en pratique ca plante si on essaye de partager) et de plus les API d'ouverture, de buffer ou de mixage ne sont pas nécessairement dans le noyeau mais peuvent être reportées en user space (ce qui plante aussi dans 90% des cas - et de toute façon la plupart des méthodespour faire ce genre de choses sont non documentées)
De fait tout le monde utilise la bibliothèque libaudio, et au sein des 800 000 fonctions tout le monde utilise les 4 ou 5 mêmes... Bref à aujourd'hui Alsa a à peut près tous les défauts d'OSS tout en étant vraiment moins bien documenté.
Généralement dès que quelqu'un arrive à faire marcher un truc dans Alsa de façon à peu près reproductible, ca devient de facto le standard. C'est pour çà qu'on a aujourd'hui l'appli sur gstreamer sur pulse audio sur Alsa... Avec les conséquences que celà peut avoir sur la lecture gapless par exemple. Si personne n'y arrive, l'API Alsa est modifiée en profondeur. Par exemple pour le mixage on a eu tout et le reste : Avant pulse audio (qui commence à marcher péniblement quand on le chatouille pas trop fort) on a eu le droit a un buffer software, un facteur d'amplification dans la connexion sonore, des devices virtuels à créer à la main, des devices virtuels qui se créaient tout seuls au besoin etc.
Je fais parti des gens qui pensent que OSS4 est plutôt plus utilisable qu'Alsa au jour le jour.
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par Jerome Herman . En réponse à la dépêche Des nouvelles du noyau Debian. Évalué à 10.
En fait dès que OSS est passé en source fermées, il est simultanément devenu très problématique au niveau technique.
De façon générale OSS considère qu'il ne devrait y avoir qu'une seule API qui gouverne le Hardware en mode kernel et qui soit accessible via les fonctions POSIX d'accès fichier de base, avec juste une modification pour savoir si il y a du changement de fréquence ou pas. Ensuite charge à l'appli et au noyal de se démerder pour que le buffer son ne se remplisse pas et qu'il se vide correctement et dans les temps.
Pour Alsa c'est assez différent, en fait on peut aussi accéder aux son Alsa via les méthodes POSIX de base, ou via 250 000 autres interfaces ou méthodes dont au moins 6 sont doccumentées. Alsa est conçu pour ne pas faire de lock exclusif en mode kernel du hardware (du moins en théorie, parcequ'en pratique ca plante si on essaye de partager) et de plus les API d'ouverture, de buffer ou de mixage ne sont pas nécessairement dans le noyeau mais peuvent être reportées en user space (ce qui plante aussi dans 90% des cas - et de toute façon la plupart des méthodespour faire ce genre de choses sont non documentées)
De fait tout le monde utilise la bibliothèque libaudio, et au sein des 800 000 fonctions tout le monde utilise les 4 ou 5 mêmes... Bref à aujourd'hui Alsa a à peut près tous les défauts d'OSS tout en étant vraiment moins bien documenté.
Généralement dès que quelqu'un arrive à faire marcher un truc dans Alsa de façon à peu près reproductible, ca devient de facto le standard. C'est pour çà qu'on a aujourd'hui l'appli sur gstreamer sur pulse audio sur Alsa... Avec les conséquences que celà peut avoir sur la lecture gapless par exemple. Si personne n'y arrive, l'API Alsa est modifiée en profondeur. Par exemple pour le mixage on a eu tout et le reste : Avant pulse audio (qui commence à marcher péniblement quand on le chatouille pas trop fort) on a eu le droit a un buffer software, un facteur d'amplification dans la connexion sonore, des devices virtuels à créer à la main, des devices virtuels qui se créaient tout seuls au besoin etc.
Je fais parti des gens qui pensent que OSS4 est plutôt plus utilisable qu'Alsa au jour le jour.