Ben moi ALSA je l'ai utilisé dans notre "prototype échelle 1:1" de laboratoire de langue LLSOLL qui au dernières nouvelle équipe au moins 2 salles de classe chez les helvètes.
Il permettait _facilement_ ET en même temps d'écouter plusieurs sources audio et video, de parler dans un micro qui pouvait émettre en multicast ET s'enregistrer dans un fichier et de recevoir du son multicast sur le simple casque micro de l'élève.
Juste avec de la configuration alsa logiciel, en utilisant les applications standards et qui fonctionnait sur des PIII 500 avec 256 Mo de RAM
Maintenant, je ne connais pas le travail de ceux qui écrivent du code, mais pour comprendre alsa et faire des test-case en c pour ma p.o.c, j'avais étudié les sources de aplay (qui est le même binaire que arecord) et cela ne m'avait pas _semblé_ si compliqué.
La problématique avec les éléments complexes, c'est que tout le monde (éxagération) veut que ca marche tout de suite sans investir le temps nécessaire pour obtenir la compétence dans le produit utilisé. Et c'est la même chose pour tout et dans tous les domaines.
La config alsa te permet _facilement_ de mapper des 'channels' sons vers d'autres, de rééchantillonner à la volée, (pour par exemple pallier à des bugs dans les pilotes de périphériques ou dans le hard du périphérique lui même) -> exemple micro-casques usb revox qui sont donnés en 16 bit stéréo mais qui en fait ne fonctionne (sous linux ??) qu'en 8 stéréo ou 16 mono.
C'est vrai que la doc alsa est pas forcément très complète et qu'il faut surfer des heures pour tomber sur un test case qui t'aide, et que le sujet audio est assez complexe par lui même. Mais je n'accepterais jamais qu'on dise que alsa ne fasse pas son travail.
Il le fait, bien, même si c'est complexe et pas/mal documenté.
Ensuite, ceux qui développent peuvent toujours prendre les sources d'alsa pour lire le code... On ne peut pas dire que les 'fonctions alsa' ne sont pas parlante...
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par hervé Couvelard . En réponse à la dépêche Des nouvelles du noyau Debian. Évalué à 4.
Il permettait _facilement_ ET en même temps d'écouter plusieurs sources audio et video, de parler dans un micro qui pouvait émettre en multicast ET s'enregistrer dans un fichier et de recevoir du son multicast sur le simple casque micro de l'élève.
Juste avec de la configuration alsa logiciel, en utilisant les applications standards et qui fonctionnait sur des PIII 500 avec 256 Mo de RAM
Maintenant, je ne connais pas le travail de ceux qui écrivent du code, mais pour comprendre alsa et faire des test-case en c pour ma p.o.c, j'avais étudié les sources de aplay (qui est le même binaire que arecord) et cela ne m'avait pas _semblé_ si compliqué.
La problématique avec les éléments complexes, c'est que tout le monde (éxagération) veut que ca marche tout de suite sans investir le temps nécessaire pour obtenir la compétence dans le produit utilisé. Et c'est la même chose pour tout et dans tous les domaines.
La config alsa te permet _facilement_ de mapper des 'channels' sons vers d'autres, de rééchantillonner à la volée, (pour par exemple pallier à des bugs dans les pilotes de périphériques ou dans le hard du périphérique lui même) -> exemple micro-casques usb revox qui sont donnés en 16 bit stéréo mais qui en fait ne fonctionne (sous linux ??) qu'en 8 stéréo ou 16 mono.
C'est vrai que la doc alsa est pas forcément très complète et qu'il faut surfer des heures pour tomber sur un test case qui t'aide, et que le sujet audio est assez complexe par lui même. Mais je n'accepterais jamais qu'on dise que alsa ne fasse pas son travail.
Il le fait, bien, même si c'est complexe et pas/mal documenté.
Ensuite, ceux qui développent peuvent toujours prendre les sources d'alsa pour lire le code... On ne peut pas dire que les 'fonctions alsa' ne sont pas parlante...