Mais quelque soit l'avenir, il serait bon qu'Alsa soit interrogeable officiellement via D-Bus, ce qui donnerait un accès à Alsa à tout langage dès qu'il existerai un module D-Bus pour ce langage !
Tu confond plusieurs choses.
L'affaire de D-Bus dans le noyau, c'est pour avoir un bus contenant des données arbitraires avec des (hum) envois multicast fiables et ordonnés1 (hum), pour permettre d'implémenter des bus arbitraires entre les applications.
Or D-Bus, c'est un bus avec un protocole maison, qui est un peu bizarre et chiant à la fois. Personne (à ma connaissance) veut d'implémenter ça dans le noyau. Ou en tout cas, personne de sensé: le protocole D-Bus est totalement inadapté pour parler avec le noyau; D-Bus nécessite que les interfaces soient stables entre l'appelant et l'appelé, or le noyau évolue et l'userspace aussi, et les deux doivent être rétrocompatible avec des anciennes versions, et ça D-Bus le propose pas.
Et surtout, le noyau possède déjà un protocole pour parler avec l'utilisateur: generic netlink. C'est un protocole simple et extensible (les deux parties peuvent ignorer des attributs qu'ils ne connaissent pas) qui est implémenté depuis belle lurette.
Et Alsa ? c'est à la fois une API pour passer du son au noyau, et une bibliothèque utilisateur (c'est pas le noyau qui lit ~/.asoundrc) qui applique une configuration définie par l'administrateur ou l'utilisateur et qui passe ça au noyau.
Si tu veux parler Alsa via D-Bus, ça veut dire qu'il va falloir un démon qui applique la configuration qui était appliqué par libasound avant, et qui lui, parle au noyau. Franchement, il y a déjà pulseaudio pour ça.
[^] # Re: Avertissement (attention les yeux)
Posté par Batchyx . En réponse au journal Exposer un ou des modules Python sur D-Bus [proof of concept]. Évalué à 5.
Tu confond plusieurs choses.
L'affaire de D-Bus dans le noyau, c'est pour avoir un bus contenant des données arbitraires avec des (hum) envois multicast fiables et ordonnés1 (hum), pour permettre d'implémenter des bus arbitraires entre les applications.
Or D-Bus, c'est un bus avec un protocole maison, qui est un peu bizarre et chiant à la fois. Personne (à ma connaissance) veut d'implémenter ça dans le noyau. Ou en tout cas, personne de sensé: le protocole D-Bus est totalement inadapté pour parler avec le noyau; D-Bus nécessite que les interfaces soient stables entre l'appelant et l'appelé, or le noyau évolue et l'userspace aussi, et les deux doivent être rétrocompatible avec des anciennes versions, et ça D-Bus le propose pas.
Et surtout, le noyau possède déjà un protocole pour parler avec l'utilisateur: generic netlink. C'est un protocole simple et extensible (les deux parties peuvent ignorer des attributs qu'ils ne connaissent pas) qui est implémenté depuis belle lurette.
Et Alsa ? c'est à la fois une API pour passer du son au noyau, et une bibliothèque utilisateur (c'est pas le noyau qui lit ~/.asoundrc) qui applique une configuration définie par l'administrateur ou l'utilisateur et qui passe ça au noyau.
Si tu veux parler Alsa via D-Bus, ça veut dire qu'il va falloir un démon qui applique la configuration qui était appliqué par libasound avant, et qui lui, parle au noyau. Franchement, il y a déjà pulseaudio pour ça.