Le « pas vraiment » me gêne : pourquoi ? Ce n'est pas parce qu'on n'a pas poussé cette solution pour l'audio sous linux que « ce n'est pas comme ça qu'on doit faire sous linux ».
Je ne faisais que parler de l'état des choses, pas de l'idéal. Je ne suis ni dev kernel, ni dev temps-réel (l'audio c'est du temps réel pour moi), donc je ne sais pas pourquoi c'est ainsi.
Il semblerait que OSS mettait un fichier /dev/dsp, que l'on pourrait accéder via les appels système open/close/read/write (qui sont les appels systèmes pour ouvrir/fermer/lire/écrire des fichiers, sur un système POSIX).
Du coup, la question est plutôt, pourquoi avoir arrêté d'utiliser un fichier accessible simplement pour gérer le son?
Mais l'article dont descend ce fil devrais te donner un indice: s'il suffit d'écrire dans un fichier pour émettre du son, comment faire pour centraliser la gestion du son? Enfin, c'est la première question qui me viens à l'esprit, n'ayant jamais utilisé OSS je ne sais pas comment ça marche même en terme d'utilisateur (et en terme de programmation, je n'ai utilisé ni l'un ni l'autre. Et le jour ou je devrais, je passerai par une bibliothèque, comme tout le monde).
Sinon, tu peux jouer du son en ligne de commande, il te suffit de passer tes données directement à aplay. Mais si les applications faisaient ça, je pense que nos CPUs n'aimeraient pas trop... pas sûr que les pipes texte (rappel: la philosophie UNIX c'est que tout doit être lisible par l'homme, donc du texte... pour du son, ça me parait pas très pertinent, parser ça consomme) soient très performants.
Note: vu qu'on peut accéder à OSS par un fichier dans /dev, je me demande si y'a moyen de jouer avec les socket BSD par la aussi...
[^] # Re: alternative : sndio, projet OpenBSD pour l'audio
Posté par freem . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 2.
Je ne faisais que parler de l'état des choses, pas de l'idéal. Je ne suis ni dev kernel, ni dev temps-réel (l'audio c'est du temps réel pour moi), donc je ne sais pas pourquoi c'est ainsi.
Il semblerait que OSS mettait un fichier /dev/dsp, que l'on pourrait accéder via les appels système open/close/read/write (qui sont les appels systèmes pour ouvrir/fermer/lire/écrire des fichiers, sur un système POSIX).
Du coup, la question est plutôt, pourquoi avoir arrêté d'utiliser un fichier accessible simplement pour gérer le son?
Mais l'article dont descend ce fil devrais te donner un indice: s'il suffit d'écrire dans un fichier pour émettre du son, comment faire pour centraliser la gestion du son? Enfin, c'est la première question qui me viens à l'esprit, n'ayant jamais utilisé OSS je ne sais pas comment ça marche même en terme d'utilisateur (et en terme de programmation, je n'ai utilisé ni l'un ni l'autre. Et le jour ou je devrais, je passerai par une bibliothèque, comme tout le monde).
Sinon, tu peux jouer du son en ligne de commande, il te suffit de passer tes données directement à aplay. Mais si les applications faisaient ça, je pense que nos CPUs n'aimeraient pas trop... pas sûr que les pipes texte (rappel: la philosophie UNIX c'est que tout doit être lisible par l'homme, donc du texte... pour du son, ça me parait pas très pertinent, parser ça consomme) soient très performants.
Note: vu qu'on peut accéder à OSS par un fichier dans /dev, je me demande si y'a moyen de jouer avec les socket BSD par la aussi...