Bon moi aussi, je suis passé à OSS après avoir lu ce blog, et je dois dire que ça marche bien, voire même, de nombreuses applis "juste marchent".
En particulier, de nombreuses API (utilisées par des jeux ou autres applis) qui ont des problèmes à utiliser ALSA + Dmix comme backend et fonctionnent avec PulseAudio mais avec une latence à coucher dehors, n'ont aucun problème avec OSS.
Là je peux lancer des tonnes d'applis en même temps sans ajouter de latence sensible, ni même dégrader la qualité du son (pas de blips) ou accaparer le processeur.
Cependant, je me suis aussi tappé la lecture des commentaires du blog, ainsi que de nombreux liens qui y sont donnés, et je commence à être convaincu qu'OSS n'est pas la solution.
En vrac:
Problèmes qui pourraient être résolus avec plus ou moins de facilité:
- pas de support de la mise en veille (il faut relancer OSS quand on sort d'hibernation, ça fait tache :/)
- tendance des applis modernes à ne pas avoir de support pour OSS (j'utilise Phonon au travers de xine et pulseaudio sur OSS pour le son sous KDE... j'essayerai le backend VLC plus tard ; et kmix ne marche simplement pas)
- 2 gusses dans un garage, dont un au chômage, c'est un peu léger pour supporter un tel bouzin à long terme (solution : convertir les gusses d'ALSA... mouais difficile quand-même).
Mais surtout:*
- opérations flottantes dans le noyau pour le mixage
- en général trop de choses dans le noyau
- moins de possibilités qu'ALSA (ne me demandez pas les détails, c'est hors de mes compétences)
- paradigme dépassé et inadapté pour certaines situations (itou)
Alors je ne sais pas trop quelle est la vraie solution. Comme l'auteur du blog j'ai tendance à penser que PulseAudio ne sert à rien pour la plupart des usages. Je veux dire tant que j'ai du son et la possibilité de mixer les sorties sons de plusieurs applis sans me prendre la tête, je suis heureux.
Or c'est ce qu'est censé faire ALSA + Dmix. Dans ce cas, à quoi bon ajouter une autre couche, qui plus est, dans le cas de PulseAudio, une couche qui a tendance à prendre un paquet de temps CPU et ajouter un paquet de latence ? (la transparence réseau et le branchement à chaud sont des raisons valides... mais loins d'être une priorité pour l'utilisateur lambda que je suis).
Donc j'aurais tendance naïvement à penser que les applis devraient mieux supporter ALSA + Dmix... mais pour une raison que j'ignore, cela semble parfois difficile.
* : notez que je parle des pilotes OSS, et non pas de l'API OSS (le fameux /dev/dsp). Il est actuellement possible d'utiliser avec plus ou moins de bonheur l'API OSS sur ALSA (la fameuse émulation OSS), ou l'API ALSA sur OSS.
Je ne connais pas la difficulté de la tâche, mais améliorer le support de l'API OSS sur les pilotes ALSA (en particulier avec Dmix, ce qui ne marche pas à l'heure actuelle) pourrait résoudre de nombreux problèmes: API facile à utiliser pour les développeurs, avec toute la souplesse d'ALSA derrière.
# OSSv4
Posté par Aldoo . En réponse au journal Test de Debian et Open Sound System version 4. Évalué à 8.
En particulier, de nombreuses API (utilisées par des jeux ou autres applis) qui ont des problèmes à utiliser ALSA + Dmix comme backend et fonctionnent avec PulseAudio mais avec une latence à coucher dehors, n'ont aucun problème avec OSS.
Là je peux lancer des tonnes d'applis en même temps sans ajouter de latence sensible, ni même dégrader la qualité du son (pas de blips) ou accaparer le processeur.
Cependant, je me suis aussi tappé la lecture des commentaires du blog, ainsi que de nombreux liens qui y sont donnés, et je commence à être convaincu qu'OSS n'est pas la solution.
En vrac:
Problèmes qui pourraient être résolus avec plus ou moins de facilité:
- pas de support de la mise en veille (il faut relancer OSS quand on sort d'hibernation, ça fait tache :/)
- tendance des applis modernes à ne pas avoir de support pour OSS (j'utilise Phonon au travers de xine et pulseaudio sur OSS pour le son sous KDE... j'essayerai le backend VLC plus tard ; et kmix ne marche simplement pas)
- 2 gusses dans un garage, dont un au chômage, c'est un peu léger pour supporter un tel bouzin à long terme (solution : convertir les gusses d'ALSA... mouais difficile quand-même).
Mais surtout:*
- opérations flottantes dans le noyau pour le mixage
- en général trop de choses dans le noyau
- moins de possibilités qu'ALSA (ne me demandez pas les détails, c'est hors de mes compétences)
- paradigme dépassé et inadapté pour certaines situations (itou)
Alors je ne sais pas trop quelle est la vraie solution. Comme l'auteur du blog j'ai tendance à penser que PulseAudio ne sert à rien pour la plupart des usages. Je veux dire tant que j'ai du son et la possibilité de mixer les sorties sons de plusieurs applis sans me prendre la tête, je suis heureux.
Or c'est ce qu'est censé faire ALSA + Dmix. Dans ce cas, à quoi bon ajouter une autre couche, qui plus est, dans le cas de PulseAudio, une couche qui a tendance à prendre un paquet de temps CPU et ajouter un paquet de latence ? (la transparence réseau et le branchement à chaud sont des raisons valides... mais loins d'être une priorité pour l'utilisateur lambda que je suis).
Donc j'aurais tendance naïvement à penser que les applis devraient mieux supporter ALSA + Dmix... mais pour une raison que j'ignore, cela semble parfois difficile.
* : notez que je parle des pilotes OSS, et non pas de l'API OSS (le fameux /dev/dsp). Il est actuellement possible d'utiliser avec plus ou moins de bonheur l'API OSS sur ALSA (la fameuse émulation OSS), ou l'API ALSA sur OSS.
Je ne connais pas la difficulté de la tâche, mais améliorer le support de l'API OSS sur les pilotes ALSA (en particulier avec Dmix, ce qui ne marche pas à l'heure actuelle) pourrait résoudre de nombreux problèmes: API facile à utiliser pour les développeurs, avec toute la souplesse d'ALSA derrière.