Non, il faut une abstraction du mixeur pour qu'en userland on n'ait pas à se demander si la carte son a un mixer ou pas.
Si la carte a un mixeur l'api noyau l'utilise. Sinon l'API noyau la remplace en logiciel. Dans tous les cas le programme qui accède au son n'a pas à faire un test pour se demander s'il passe par un mixeur HW, si un mixeur logiciel est installé, ou s'il faut jouer le son directement.
Linux est un unix, et unix c'est aussi des questions de portabilité. Il faut que les api soient compatible avec *BSD, Hurd, etc.
Avant il y eu les programmes qui se concurrençaient, il fallait fermer le navigateur pour qu'un autre programme puisse accéder au son. On a eu droit aux mixeurs logiciels en daemon (esd), puis alsa est arrivé, et maintenant on nous remet une couche supplémentaire avec pulseaudio. Plus ça se complique et moins c'est bien.
[^] # Re: Histoire du son et conclusion
Posté par fleny68 . En réponse au journal PulseAudio ou comment casser ce qui marche (pour le plaisir de casser). Évalué à 1.
Non, il faut une abstraction du mixeur pour qu'en userland on n'ait pas à se demander si la carte son a un mixer ou pas.
Si la carte a un mixeur l'api noyau l'utilise. Sinon l'API noyau la remplace en logiciel. Dans tous les cas le programme qui accède au son n'a pas à faire un test pour se demander s'il passe par un mixeur HW, si un mixeur logiciel est installé, ou s'il faut jouer le son directement.
Linux est un unix, et unix c'est aussi des questions de portabilité. Il faut que les api soient compatible avec *BSD, Hurd, etc.
Avant il y eu les programmes qui se concurrençaient, il fallait fermer le navigateur pour qu'un autre programme puisse accéder au son. On a eu droit aux mixeurs logiciels en daemon (esd), puis alsa est arrivé, et maintenant on nous remet une couche supplémentaire avec pulseaudio. Plus ça se complique et moins c'est bien.