Mais j'ai l'impression d'une occasion manqué pour l'instant avec Pulse sur le spaguetti mille feuille de la pile audio Linuxienne (Alsa and co, OSS, Jack, ....).
« Mille feuille » ?
La pile audio Linux moderne, c’est :
– les pilotes ALSA dans le noyau ;
– la partie "userspace" de ALSA (libasound) ;
– un serveur son, PulseAudio.
On est quand même loin d’un mille-feuille et d’un « beau bordel ».
La couche de compatibilité OSS que fournit ALSA n’est là que pour permettre à des programmes ne supportant que l’API OSS de fonctionner de manière transparente. On pourrait s’en passer, mais elle ne gène personne. Quant au vrai OSS, je ne le considère pas comme faisant partie de la pile audio Linux classique, on peut l’utiliser à la place d’ALSA mais ça relève d’un choix délibéré d’un utilisateur qui a ses raisons de préférer OSS.
Jack est un serveur de son spécialisé, là encore je ne le classerais pas dans la pile audio classique. Ceux qui n’en ont pas besoin peuvent ignorer jusqu’à son existence. Le fait que la pile audio Linux se divise en deux branches au niveau du serveur son (PulseAudio pour l’usage général, Jack pour l’audio pro) n’est pas particulièrement choquant, pour rappel on a quelque chose de similaire sous Windows avec la pile ASIO. Il y a de bonnes raisons à cela, sur lesquelles tant les développeurs de Jack que ceux de PulseAudio sont d’accord.
Et pitié, ne ressortez pas le schéma ignoble pondu par Adobe il y a quelques années — la flemme de le retrouver, mais je suis sûr que vous voyez de quel schéma je parle : ce schéma dans laquelle on nous présente OpenAL, SDL, Allegro, GStreamer et une dizaine d’autres bibliothèques comme faisant partie de la pile audio Linux et censé illustrer sa complexité démente. Oui, un programmeur sous Linux a le choix entre de nombreuses bibliothèques s’il ne veut pas utiliser libasound ou libpulse directement. Et alors ? Sous Windows aussi un programmeur peut utiliser la SDL pour jouer du son, qui prétendra que la SDL fait partie de la pile audio Windows et que celle-ci est trop compliquée ?
il y a probablement des gains a trouver en virant/simplifiant la couche alsa entre le noyau et Pulse
A priori, je suppose que PulseAudio pourrait effectivement se passer de libasound et communiquer directement avec la partie noyau de ALSA via /dev/snd/. Ses développeurs n’ont peut-être pas voulu ré-implémenter dans PulseAudio ce que libasound fait déjà. Quoi qu’il en soit, un tel changement ne serait qu’un détail d’implémentation de PulseAudio, il n’y a nul besoin de réclamer une refonte complète de la pile audio pour ça.
Et toujours un beau bordel au niveau de la pile audio.... Et j'aimerai que Lennart, fort de son expérience, nous refasse maintenant une 2eme passe pour changer tout cela...
Tu devrais peut-être lui fournir un cahier des charges un peu plus précis que « changer tout cela », non ? Je n’ai pas vu de griefs précisément formulés dans ton message.
[^] # Re: fin de l'histoire ?
Posté par gouttegd . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 10.
« Mille feuille » ?
La pile audio Linux moderne, c’est :
– les pilotes ALSA dans le noyau ;
– la partie "userspace" de ALSA (libasound) ;
– un serveur son, PulseAudio.
On est quand même loin d’un mille-feuille et d’un « beau bordel ».
La couche de compatibilité OSS que fournit ALSA n’est là que pour permettre à des programmes ne supportant que l’API OSS de fonctionner de manière transparente. On pourrait s’en passer, mais elle ne gène personne. Quant au vrai OSS, je ne le considère pas comme faisant partie de la pile audio Linux classique, on peut l’utiliser à la place d’ALSA mais ça relève d’un choix délibéré d’un utilisateur qui a ses raisons de préférer OSS.
Jack est un serveur de son spécialisé, là encore je ne le classerais pas dans la pile audio classique. Ceux qui n’en ont pas besoin peuvent ignorer jusqu’à son existence. Le fait que la pile audio Linux se divise en deux branches au niveau du serveur son (PulseAudio pour l’usage général, Jack pour l’audio pro) n’est pas particulièrement choquant, pour rappel on a quelque chose de similaire sous Windows avec la pile ASIO. Il y a de bonnes raisons à cela, sur lesquelles tant les développeurs de Jack que ceux de PulseAudio sont d’accord.
Et pitié, ne ressortez pas le schéma ignoble pondu par Adobe il y a quelques années — la flemme de le retrouver, mais je suis sûr que vous voyez de quel schéma je parle : ce schéma dans laquelle on nous présente OpenAL, SDL, Allegro, GStreamer et une dizaine d’autres bibliothèques comme faisant partie de la pile audio Linux et censé illustrer sa complexité démente. Oui, un programmeur sous Linux a le choix entre de nombreuses bibliothèques s’il ne veut pas utiliser libasound ou libpulse directement. Et alors ? Sous Windows aussi un programmeur peut utiliser la SDL pour jouer du son, qui prétendra que la SDL fait partie de la pile audio Windows et que celle-ci est trop compliquée ?
A priori, je suppose que PulseAudio pourrait effectivement se passer de libasound et communiquer directement avec la partie noyau de ALSA via
/dev/snd/. Ses développeurs n’ont peut-être pas voulu ré-implémenter dans PulseAudio ce que libasound fait déjà. Quoi qu’il en soit, un tel changement ne serait qu’un détail d’implémentation de PulseAudio, il n’y a nul besoin de réclamer une refonte complète de la pile audio pour ça.Tu devrais peut-être lui fournir un cahier des charges un peu plus précis que « changer tout cela », non ? Je n’ai pas vu de griefs précisément formulés dans ton message.