J'ai découvert au passage la commande aoss, qui fait (je sais pas comment) que les applis OSS peuvent cohabiter avec ALSA.
En fait avec aoss, oss et ALSA ne cohabitent pas, aoss permet de faire en sorte que la totalité du son soie gérée par alsa, et sans passer par le driver alsa-oss.
aoss utilise LD_PRELOAD pour définir une librairie à charger en priorité sur celle par défaut (pas dans un chemin de ldconfig, ou modifier la priorités entre /usr/lib et /lib par exemple).
Après je ne connais pas le détail, mais pour te donner une idée, ca permet de redéfinir fopen(), garder le comportement standard sauf quand tu a un fopen("/dev/dsp"), ou la tu vas donner la main a alsa pour les fwrite() - ou autre - sur ce file handle. Et hop, tout ce qui sera écrit sera renvoyé a alsa plutôt qu'au driver oss, même si c'est une émulation alsa-oss.
[^] # Re: Pavé dans la marre :)
Posté par Anonyme . En réponse au journal Pendant que Linux progresse.... Évalué à 2.
En fait avec aoss, oss et ALSA ne cohabitent pas, aoss permet de faire en sorte que la totalité du son soie gérée par alsa, et sans passer par le driver alsa-oss.
aoss utilise LD_PRELOAD pour définir une librairie à charger en priorité sur celle par défaut (pas dans un chemin de ldconfig, ou modifier la priorités entre /usr/lib et /lib par exemple).
Après je ne connais pas le détail, mais pour te donner une idée, ca permet de redéfinir fopen(), garder le comportement standard sauf quand tu a un fopen("/dev/dsp"), ou la tu vas donner la main a alsa pour les fwrite() - ou autre - sur ce file handle. Et hop, tout ce qui sera écrit sera renvoyé a alsa plutôt qu'au driver oss, même si c'est une émulation alsa-oss.
Qui a dit "hack pourri" ?