A moins que tu souhaites vraiment faire des torsions avec les bindings python de libXtract (ça marche, ça ?) (voir PySndObj ou Py-PA
En fait, je ne produis ni ne capture moi-même du son, je laisse cette tâche à Gstreamer. Mais pour construire mes pipelines Gstreamer, j'ai besoin d'en savoir un peu plus sur ce que font mes cartes.
Avec l'usage d'un module de conversion de format binaire (S16_LE, S32_LE…) nommé audioconvert et un module de resampling (44100, 48000…) nommé audioresample, tandis que Alsa charge lui aussi le module plug (qui fait la reconversion binaire et le rééchantillonnage) et le module dmix pour faire le mixage (dont je n'ai pas besoin).
Le problème, c'est que c'est ce que font les logiciels, aujourd'hui. Ils prennent ceinture et bretelle. Tel logiciel utilise Gstreamer parce que c'est cool, et pour être sûr de ne pas être bloqué avec un format ou un échantillonnage improbable, glissent les deux modules audioconvert et audioresample au cas où, notamment dans le cas où l'utilisateur indique dans ses préférences que sa carte son est hw:0 et non default:hw:0 ni plug:hw:0.
Mais en fait, dans la majorité des cas, la carte par défaut de l'utilisateur est default, c'est à dire default:hw:0.
Alors quand l'appli est un logiciel de lecture de musique (rhythmbox, banshee…) ça ne pose aucun problème. Quand tu ne fait que capturer le son pour le monter de manière non linéaire plus tard, la latence ne pose pas problème.
C'est pourquoi malgré qu'Alsa soit un gros merdier difficilement exploitable, il n'y a pas grand monde pour râler parce que dans 99% des cas, les gens utilisent une abstraction sur une abstraction sur une abstraction, par exemple Gstreamer sur PulseAudio sur Alsa, trois couches où peuvent être faits du rééchantillonage et de la conversion de format, deux couches où peut être fait le mixage. Et oui, quand vous écoutez votre musique préférée avec Rhythmbox, il se passe certainement tout cela sur votre ordinateur.
Même quand vous faites « _aplay monfichier.wav_ », vous passez par deux étapes de rééchantillonnage, celui d' aplay, et celui d' alsa, parce que aplay rééchantillonne par défaut, et utilise par défaut la carte son default et donc le module plug. Tout ça « au cas où », toujours.
Bref cette façon de faire, avec ceintures et bretelles est cool pour celui qui ne se soucie pas de la latence, il sait qu'il peut parler comme il veut, la carte sortira le son. Il peut faire de 5 canal en F32_LE à 48000 Hz sur une carte son stéréo qui ne supporte que le S16_LE à 44100, le son sortira, l'utilisateur sera content.
Sauf que… moi je fais de la radio FM, je transfère du son sur le réseau, je relie des studios entre eux pour faire des duplex, ou un studios mobile au départ émetteur du studio pour faire un direct en extérieur. Je veux être au plus strict sur la latence. Donc, pas de audioconvert inutile, pas de audioresample inutile, pas de plug, ni de dmix/dsnoop parce que je mixe déjà les sons en amont. Mais pour faire ça, il faut que je connaisse mon matériel.
Aussi, je veux pouvoir indiquer dans l'interface utilisateur ce qu'il a le droit de faire, du genre « OK gars, tu as 2 stéréo (4 entrées mono) sur telle carte en S32_LE et pas moins, avec de l'échantillonnage jusqu'à 192Khz, mais sur cette autre carte tu as 1 entrée stéréo (2 entrées mono) en S16_LE et pas plus, avec de l'échantillonnage jusqu'à 44100 ». Et quand l'utilisateur demande « je veux 5 canaux de capture », mon logiciel configure le pipeline de capture de la première carte en capturant tous les canaux avec un module audioconvert mais de pas de audioresample parce que derrière il y a un jackd en F32_LE, tandis que le pipeline de la seconde carte utilise à la fois le module audioconvert et le module audioresample, mais ne capture qu'un seul canal, le gauche.
La plupart des logiciels demandent à l'utilisateur « quel son veux tu lire ? », mais mon logiciel demande à l'utilisateur « que veux-tu faire avec ta carte son ? ». Et pour faire ça, c'est la galère.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: PyAlsaAudio python3
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Exposer un ou des modules Python sur D-Bus [proof of concept]. Évalué à 6.
En fait, je ne produis ni ne capture moi-même du son, je laisse cette tâche à Gstreamer. Mais pour construire mes pipelines Gstreamer, j'ai besoin d'en savoir un peu plus sur ce que font mes cartes.
Je veux éviter ce genre de pipeline :
Avec l'usage d'un module de conversion de format binaire (S16_LE, S32_LE…) nommé
audioconvertet un module de resampling (44100, 48000…) nomméaudioresample, tandis que Alsa charge lui aussi le moduleplug(qui fait la reconversion binaire et le rééchantillonnage) et le moduledmixpour faire le mixage (dont je n'ai pas besoin).Le problème, c'est que c'est ce que font les logiciels, aujourd'hui. Ils prennent ceinture et bretelle. Tel logiciel utilise Gstreamer parce que c'est cool, et pour être sûr de ne pas être bloqué avec un format ou un échantillonnage improbable, glissent les deux modules
audioconvertetaudioresampleau cas où, notamment dans le cas où l'utilisateur indique dans ses préférences que sa carte son esthw:0et nondefault:hw:0niplug:hw:0.Mais en fait, dans la majorité des cas, la carte par défaut de l'utilisateur est
default, c'est à diredefault:hw:0.Alors quand l'appli est un logiciel de lecture de musique (rhythmbox, banshee…) ça ne pose aucun problème. Quand tu ne fait que capturer le son pour le monter de manière non linéaire plus tard, la latence ne pose pas problème.
C'est pourquoi malgré qu'Alsa soit un gros merdier difficilement exploitable, il n'y a pas grand monde pour râler parce que dans 99% des cas, les gens utilisent une abstraction sur une abstraction sur une abstraction, par exemple Gstreamer sur PulseAudio sur Alsa, trois couches où peuvent être faits du rééchantillonage et de la conversion de format, deux couches où peut être fait le mixage. Et oui, quand vous écoutez votre musique préférée avec Rhythmbox, il se passe certainement tout cela sur votre ordinateur.
Même quand vous faites « _aplay monfichier.wav_ », vous passez par deux étapes de rééchantillonnage, celui d' aplay, et celui d' alsa, parce que aplay rééchantillonne par défaut, et utilise par défaut la carte son
defaultet donc le moduleplug. Tout ça « au cas où », toujours.Bref cette façon de faire, avec ceintures et bretelles est cool pour celui qui ne se soucie pas de la latence, il sait qu'il peut parler comme il veut, la carte sortira le son. Il peut faire de 5 canal en F32_LE à 48000 Hz sur une carte son stéréo qui ne supporte que le S16_LE à 44100, le son sortira, l'utilisateur sera content.
Sauf que… moi je fais de la radio FM, je transfère du son sur le réseau, je relie des studios entre eux pour faire des duplex, ou un studios mobile au départ émetteur du studio pour faire un direct en extérieur. Je veux être au plus strict sur la latence. Donc, pas de
audioconvertinutile, pas deaudioresampleinutile, pas deplug, ni dedmix/dsnoopparce que je mixe déjà les sons en amont. Mais pour faire ça, il faut que je connaisse mon matériel.Aussi, je veux pouvoir indiquer dans l'interface utilisateur ce qu'il a le droit de faire, du genre « OK gars, tu as 2 stéréo (4 entrées mono) sur telle carte en S32_LE et pas moins, avec de l'échantillonnage jusqu'à 192Khz, mais sur cette autre carte tu as 1 entrée stéréo (2 entrées mono) en S16_LE et pas plus, avec de l'échantillonnage jusqu'à 44100 ». Et quand l'utilisateur demande « je veux 5 canaux de capture », mon logiciel configure le pipeline de capture de la première carte en capturant tous les canaux avec un module
audioconvertmais de pas deaudioresampleparce que derrière il y a un jackd en F32_LE, tandis que le pipeline de la seconde carte utilise à la fois le moduleaudioconvertet le moduleaudioresample, mais ne capture qu'un seul canal, le gauche.La plupart des logiciels demandent à l'utilisateur « quel son veux tu lire ? », mais mon logiciel demande à l'utilisateur « que veux-tu faire avec ta carte son ? ». Et pour faire ça, c'est la galère.
ce commentaire est sous licence cc by 4 et précédentes