Existe-t-il une configuration d'ALSA/dmix qui permette d'enregistrer "à
la volée" ce qui s'entend au niveau des speakers ?
Je m'explique : on suppose qu'à tout instant, les applications sonores
(disons plusieurs instances de mplayer) ont configuré leur sortie sur
ALSA et qu'ALSA a été configuré pour accepter simultanément un nombre
quelconque de sources sonores. Le résultat sonore (grâce notamment à
l'instructif tutoriel de Nicolas George --
http://www.mjc-athena.org/mediawiki/index.php/Partage_du_son --) est une
superposition des sources. Comment alors enregistrer ce flux dans un
fichier flux.wav par exemple?
J'ai bien essayé d'adapter le tutoriel
http://alsa.opensrc.org/index.php/Record_from_pcm mais sur mon EeePc je
n'ai pas de composant 'Mix' et flux.wav est désespérement silencieux.
Le résultat du test aadebug (http://alsa.opensrc.org/index.php/Aadebug)
m'a fourni :
Hardware --------------------------------------------------
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML
Express Processor to DRAM Controller (rev 04)
"
Même si un conflit semble inévitable (capture et playback ont le même
canal), n'y a-t-il pas un moyen purement ALSA/dmix (pas de jack) pour
récupérer (le temps de latence m'important peu) le flux produit par le
mixer ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
kkwweett wrote in message <48819cf9$0$965$:
J'ai bien essayé d'adapter le tutoriel http://alsa.opensrc.org/index.php/Record_from_pcm mais sur mon EeePc je n'ai pas de composant 'Mix' et flux.wav est désespérement silencieux.
La méthode décrite là travaille avec l'aide matérielle de la carte son : le son sort sur la carte, et elle le fait re-rentrer. C'est assez inélégant. De plus, je ne serais pas surpris d'apprendre que le signal fait un passage en analogique avec certaines cartes.
Avec ALSA, il y a bien plus efficace, purement logiciel.
Le mohtage normal de dmix avec ALSA ressemble à ça :
Il est alors très facile de remplacer [carte son] par [fichier]+[carte son]. Sauf que ça ne va pas marcher, donc ne suis pas les instructions tout de suite.
Si tu as suivi mon tutoriel (je suis très content qu'il serve), alors la carte son est définie par quelque chose comme :
pcm.c2 { type hw card AudioPCI device 1 }
Pour stocker dans un fichier, on définit en plus :
pcm.c2file { type file slave.pcm c2 file "/tmp/capture.raw" }
Il reste à remplacer partout ailleurs c2 par c2file (sauf dans la définition de c2, évidemment). Quand on a bien vérifié que ça marchait, on peut utiliser des variables d'environnement et faire un branchement conditionnel, pour activer la capture sans changer le fichier de config.
Quelques remarques :
- Le fichier résultant, capture.raw, est du PCM brut, sans entêtes. Pour le convertir en wav ou autre, on peut utiliser ffmpeg par exemple :
Dans les deux cas, il faut connaître les paramètres (format, ici 16 bits signés little endian ; taux d'échantillonnage ; nombre de canaux), ce qui est mon point suivant.
- Si on joue un fichier directement sur c2file avec une application stupide (par exemple aplay -D c2file), alors le fichier capture.raw montrera exactement ce que l'application a joué. Avec un peu de chance, le format sera écrit dans les messages de diagnostic de l'application. Mais ça échouera si ce format n'est pas directement supporté par le matériel de la carte son.
Si on change la définition « slave.pcm c2 » pour insérer un plugin plug entre c2file et c2 (écrire plug:c2 à la place de c2 suffit pour un essai rapide), alors ce plugin adaptera comme il faut, et le ce dernier problème disparaît.
- Un dmix ne peut pas se brancher que directement sur une carte son, on ne peut pas insérer de plugin entre dmix et hw. Donc la structure que tu vas devoir adopter va être la suivante :
Évidemment, j'ai dessiné trois fois [plug] et [file], mais dans le fichier de configuration, ça n'apparaît qu'une fois.
Si tu ne changes rien, à chaque fois que tu lances une application, elle va commencer à écrire dans le fichier capture.raw, et ça risque d'être moche (soit elle efface le fichier de l'instance précédente, soit les deux écritures dans le fichier se mélangent). Donc il faut trouver un moyen pour configurer à la volée le fichier de sortie. Ça va donner quelque chose comme (non testé ; en supposant que plug+dmix s'appelle dmixplug) :
pcm.capture-yes { type file @args [ FILE ] @args.file { type string default { @fonc getenv vars [ ALSA_CAPTURE_FILE ] default "/dev/null" } } file $FILE slave.pcm dmixplug }
pcm.capture-no { @func refer name "pcm.dmixplug" }
pcm.!default { @func refer name "pcm.capture-or-not" }
La variable d'environnement ALSA_CAPTURE, qui doit valoir yes ou no (ou ne pas être définie) active ou désactive la capture, et ALSA_CAPTURE_FILE indique le fichier.
On notera que j'ai utilisé partout des @func refer plutôt que type plug, pour éviter d'insérer des plugins plug à tout bout de champ. Le résultat est que la cpature, si elle a lieu, est directement branchée à l'application, sans changement de format.
Bonne chance pour faire marcher ça.
kkwweett wrote in message <48819cf9$0$965$ba4acef3@news.orange.fr>:
J'ai bien essayé d'adapter le tutoriel
http://alsa.opensrc.org/index.php/Record_from_pcm mais sur mon EeePc je
n'ai pas de composant 'Mix' et flux.wav est désespérement silencieux.
La méthode décrite là travaille avec l'aide matérielle de la carte son : le
son sort sur la carte, et elle le fait re-rentrer. C'est assez inélégant. De
plus, je ne serais pas surpris d'apprendre que le signal fait un passage en
analogique avec certaines cartes.
Avec ALSA, il y a bien plus efficace, purement logiciel.
Le mohtage normal de dmix avec ALSA ressemble à ça :
Il est alors très facile de remplacer [carte son] par [fichier]+[carte son].
Sauf que ça ne va pas marcher, donc ne suis pas les instructions tout de
suite.
Si tu as suivi mon tutoriel (je suis très content qu'il serve), alors la
carte son est définie par quelque chose comme :
pcm.c2 {
type hw
card AudioPCI
device 1
}
Pour stocker dans un fichier, on définit en plus :
pcm.c2file {
type file
slave.pcm c2
file "/tmp/capture.raw"
}
Il reste à remplacer partout ailleurs c2 par c2file (sauf dans la définition
de c2, évidemment). Quand on a bien vérifié que ça marchait, on peut
utiliser des variables d'environnement et faire un branchement conditionnel,
pour activer la capture sans changer le fichier de config.
Quelques remarques :
- Le fichier résultant, capture.raw, est du PCM brut, sans entêtes. Pour le
convertir en wav ou autre, on peut utiliser ffmpeg par exemple :
Dans les deux cas, il faut connaître les paramètres (format, ici 16 bits
signés little endian ; taux d'échantillonnage ; nombre de canaux), ce qui
est mon point suivant.
- Si on joue un fichier directement sur c2file avec une application stupide
(par exemple aplay -D c2file), alors le fichier capture.raw montrera
exactement ce que l'application a joué. Avec un peu de chance, le format
sera écrit dans les messages de diagnostic de l'application. Mais ça
échouera si ce format n'est pas directement supporté par le matériel de la
carte son.
Si on change la définition « slave.pcm c2 » pour insérer un plugin plug
entre c2file et c2 (écrire plug:c2 à la place de c2 suffit pour un essai
rapide), alors ce plugin adaptera comme il faut, et le ce dernier problème
disparaît.
- Un dmix ne peut pas se brancher que directement sur une carte son, on ne
peut pas insérer de plugin entre dmix et hw. Donc la structure que tu vas
devoir adopter va être la suivante :
Évidemment, j'ai dessiné trois fois [plug] et [file], mais dans le fichier
de configuration, ça n'apparaît qu'une fois.
Si tu ne changes rien, à chaque fois que tu lances une application, elle
va commencer à écrire dans le fichier capture.raw, et ça risque d'être
moche (soit elle efface le fichier de l'instance précédente, soit les deux
écritures dans le fichier se mélangent). Donc il faut trouver un moyen
pour configurer à la volée le fichier de sortie. Ça va donner quelque
chose comme (non testé ; en supposant que plug+dmix s'appelle dmixplug) :
pcm.capture-yes {
type file
@args [ FILE ]
@args.file {
type string default {
@fonc getenv vars [ ALSA_CAPTURE_FILE ] default "/dev/null"
}
}
file $FILE
slave.pcm dmixplug
}
pcm.capture-no {
@func refer
name "pcm.dmixplug"
}
pcm.!default {
@func refer
name "pcm.capture-or-not"
}
La variable d'environnement ALSA_CAPTURE, qui doit valoir yes ou no (ou ne
pas être définie) active ou désactive la capture, et ALSA_CAPTURE_FILE
indique le fichier.
On notera que j'ai utilisé partout des @func refer plutôt que type plug,
pour éviter d'insérer des plugins plug à tout bout de champ. Le résultat
est que la cpature, si elle a lieu, est directement branchée à
l'application, sans changement de format.
J'ai bien essayé d'adapter le tutoriel http://alsa.opensrc.org/index.php/Record_from_pcm mais sur mon EeePc je n'ai pas de composant 'Mix' et flux.wav est désespérement silencieux.
La méthode décrite là travaille avec l'aide matérielle de la carte son : le son sort sur la carte, et elle le fait re-rentrer. C'est assez inélégant. De plus, je ne serais pas surpris d'apprendre que le signal fait un passage en analogique avec certaines cartes.
Avec ALSA, il y a bien plus efficace, purement logiciel.
Le mohtage normal de dmix avec ALSA ressemble à ça :
Il est alors très facile de remplacer [carte son] par [fichier]+[carte son]. Sauf que ça ne va pas marcher, donc ne suis pas les instructions tout de suite.
Si tu as suivi mon tutoriel (je suis très content qu'il serve), alors la carte son est définie par quelque chose comme :
pcm.c2 { type hw card AudioPCI device 1 }
Pour stocker dans un fichier, on définit en plus :
pcm.c2file { type file slave.pcm c2 file "/tmp/capture.raw" }
Il reste à remplacer partout ailleurs c2 par c2file (sauf dans la définition de c2, évidemment). Quand on a bien vérifié que ça marchait, on peut utiliser des variables d'environnement et faire un branchement conditionnel, pour activer la capture sans changer le fichier de config.
Quelques remarques :
- Le fichier résultant, capture.raw, est du PCM brut, sans entêtes. Pour le convertir en wav ou autre, on peut utiliser ffmpeg par exemple :
Dans les deux cas, il faut connaître les paramètres (format, ici 16 bits signés little endian ; taux d'échantillonnage ; nombre de canaux), ce qui est mon point suivant.
- Si on joue un fichier directement sur c2file avec une application stupide (par exemple aplay -D c2file), alors le fichier capture.raw montrera exactement ce que l'application a joué. Avec un peu de chance, le format sera écrit dans les messages de diagnostic de l'application. Mais ça échouera si ce format n'est pas directement supporté par le matériel de la carte son.
Si on change la définition « slave.pcm c2 » pour insérer un plugin plug entre c2file et c2 (écrire plug:c2 à la place de c2 suffit pour un essai rapide), alors ce plugin adaptera comme il faut, et le ce dernier problème disparaît.
- Un dmix ne peut pas se brancher que directement sur une carte son, on ne peut pas insérer de plugin entre dmix et hw. Donc la structure que tu vas devoir adopter va être la suivante :
Évidemment, j'ai dessiné trois fois [plug] et [file], mais dans le fichier de configuration, ça n'apparaît qu'une fois.
Si tu ne changes rien, à chaque fois que tu lances une application, elle va commencer à écrire dans le fichier capture.raw, et ça risque d'être moche (soit elle efface le fichier de l'instance précédente, soit les deux écritures dans le fichier se mélangent). Donc il faut trouver un moyen pour configurer à la volée le fichier de sortie. Ça va donner quelque chose comme (non testé ; en supposant que plug+dmix s'appelle dmixplug) :
pcm.capture-yes { type file @args [ FILE ] @args.file { type string default { @fonc getenv vars [ ALSA_CAPTURE_FILE ] default "/dev/null" } } file $FILE slave.pcm dmixplug }
pcm.capture-no { @func refer name "pcm.dmixplug" }
pcm.!default { @func refer name "pcm.capture-or-not" }
La variable d'environnement ALSA_CAPTURE, qui doit valoir yes ou no (ou ne pas être définie) active ou désactive la capture, et ALSA_CAPTURE_FILE indique le fichier.
On notera que j'ai utilisé partout des @func refer plutôt que type plug, pour éviter d'insérer des plugins plug à tout bout de champ. Le résultat est que la cpature, si elle a lieu, est directement branchée à l'application, sans changement de format.
Bonne chance pour faire marcher ça.
Jean-Pierre
>Existe-t-il une configuration d'ALSA/dmix qui permette d'enregistrer "à la volée" ce qui s'entend au niveau des speakers ?
il me semble que vsound (que j'ai utilisé y'a une paye) le permet mais je ne sais pas si ça fonctionne avec alsa? Ou à tester!...
bon courage.
--
Ah l'informatique! Ou pourquoi faire simple quand on peut faire compliqué!...
Jean-Pierre.
>Existe-t-il une configuration d'ALSA/dmix qui permette d'enregistrer "à
la volée" ce qui s'entend au niveau des speakers ?
il me semble que vsound (que j'ai utilisé y'a une paye) le permet mais je ne
sais pas si ça fonctionne avec alsa?
Ou à tester!...
bon courage.
--
Ah l'informatique! Ou pourquoi faire simple quand on peut faire
compliqué!...
>Existe-t-il une configuration d'ALSA/dmix qui permette d'enregistrer "à la volée" ce qui s'entend au niveau des speakers ?
il me semble que vsound (que j'ai utilisé y'a une paye) le permet mais je ne sais pas si ça fonctionne avec alsa? Ou à tester!...
bon courage.
--
Ah l'informatique! Ou pourquoi faire simple quand on peut faire compliqué!...
Jean-Pierre.
kkwweett
Nicolas George a écrit : > > Bonne chance pour faire marcher ça.
Merci, je m'y mets....
...tout de suite, une question : Qu'entends-tu par :
Quand on a bien vérifié que ça marchait, on peut utiliser des variables d'environnement et faire un branchement conditionnel, pour activer la capture sans changer le fichier de config.
?
tu veux dire un if dans le asoundrc ou alors lors de l'appel de aplay ?
Nicolas George a écrit :
>
> Bonne chance pour faire marcher ça.
Merci, je m'y mets....
...tout de suite, une question : Qu'entends-tu par :
Quand on a bien vérifié que ça marchait, on peut
utiliser des variables d'environnement et faire un branchement conditionnel,
pour activer la capture sans changer le fichier de config.
?
tu veux dire un if dans le asoundrc ou alors lors de l'appel de aplay ?
Nicolas George a écrit : > > Bonne chance pour faire marcher ça.
Merci, je m'y mets....
...tout de suite, une question : Qu'entends-tu par :
Quand on a bien vérifié que ça marchait, on peut utiliser des variables d'environnement et faire un branchement conditionnel, pour activer la capture sans changer le fichier de config.
?
tu veux dire un if dans le asoundrc ou alors lors de l'appel de aplay ?
kkwweett
Jean-Pierre a écrit :
il me semble que vsound (que j'ai utilisé y'a une paye) le permet mais je ne sais pas si ça fonctionne avec alsa? Ou à tester!...
vsound n'est pas par défaut dans eeepc 701 et, de toute facon, je suis plus tenté par l'approche ALSA qui semble plus propre (ou disons plus cohérente) que celle de sox (sur lequel repose vsound apparemment), mais merci du tuyau
bon courage.
merci !
Jean-Pierre a écrit :
il me semble que vsound (que j'ai utilisé y'a une paye) le permet mais je ne
sais pas si ça fonctionne avec alsa?
Ou à tester!...
vsound n'est pas par défaut dans eeepc 701 et, de toute facon, je suis
plus tenté par l'approche ALSA qui semble plus propre (ou disons plus
cohérente) que celle de sox (sur lequel repose vsound apparemment), mais
merci du tuyau
il me semble que vsound (que j'ai utilisé y'a une paye) le permet mais je ne sais pas si ça fonctionne avec alsa? Ou à tester!...
vsound n'est pas par défaut dans eeepc 701 et, de toute facon, je suis plus tenté par l'approche ALSA qui semble plus propre (ou disons plus cohérente) que celle de sox (sur lequel repose vsound apparemment), mais merci du tuyau
bon courage.
merci !
kkwweett
Nicolas George a écrit :
> > Bonne chance pour faire marcher ça.
Merci : j'ai un peu avancé :
de c2, évidemment). Quand on a bien vérifié que ça marchait, on peut
Ok (je peux désormais enregistrer du PCM grâce à ta remarque sur plug).
Après, je bloque :
utiliser des variables d'environnement et faire un branchement conditionnel, pour activer la capture sans changer le fichier de config.
- Un dmix ne peut pas se brancher que directement sur une carte son, on ne peut pas insérer de plugin entre dmix et hw. Donc la structure que tu vas devoir adopter va être la suivante :
Évidemment, j'ai dessiné trois fois [plug] et [file], mais dans le fichier de configuration, ça n'apparaît qu'une fois.
ok mais à l'usage, j'en déduis que je (ou plutôt ALSA) vais jongler avec (ici) trois fichiers.
Si tu ne changes rien, à chaque fois que tu lances une application, elle va commencer à écrire dans le fichier capture.raw, et ça risque d'être moche (soit elle efface le fichier de l'instance précédente, soit les deux écritures dans le fichier se mélangent). Donc il faut trouver un moyen
ok, ici, tu parles encore de 3 fichiers
pour configurer à la volée le fichier de sortie. Ça va donner quelque
Ici, il n'y a plus qu'un fichier ?
chose comme (non testé ; en supposant que plug+dmix s'appelle dmixplug) :
pcm.capture-yes { type file @args [ FILE ] @args.file { type string default { @fonc getenv vars [ ALSA_CAPTURE_FILE ] default "/dev/null" } } file $FILE slave.pcm dmixplug }
pcm.capture-no { @func refer name "pcm.dmixplug" }
pcm.!default { @func refer name "pcm.capture-or-not" }
La variable d'environnement ALSA_CAPTURE, qui doit valoir yes ou no (ou ne pas être définie) active ou désactive la capture, et ALSA_CAPTURE_FILE indique le fichier.
si je n'indique qu'un seul nom de fichier, je retombe sur le risque de mocheté que tu évoquais avant, non ?
On notera que j'ai utilisé partout des @func refer plutôt que type plug, pour éviter d'insérer des plugins plug à tout bout de champ. Le résultat
As-tu des tutoriels à me conseiller pour apprendre à apprivoiser ce langage (notamment sur ces @func refer) assez peu intuitif ?
> est que la cpature, si elle a lieu, est directement branchée à > l'application, sans changement de format.
Nicolas George a écrit :
>
> Bonne chance pour faire marcher ça.
Merci : j'ai un peu avancé :
de c2, évidemment). Quand on a bien vérifié que ça marchait, on peut
Ok (je peux désormais enregistrer du PCM grâce à ta remarque sur plug).
Après, je bloque :
utiliser des variables d'environnement et faire un branchement conditionnel,
pour activer la capture sans changer le fichier de config.
- Un dmix ne peut pas se brancher que directement sur une carte son, on ne
peut pas insérer de plugin entre dmix et hw. Donc la structure que tu vas
devoir adopter va être la suivante :
Évidemment, j'ai dessiné trois fois [plug] et [file], mais dans le fichier
de configuration, ça n'apparaît qu'une fois.
ok mais à l'usage, j'en déduis que je (ou plutôt ALSA) vais jongler avec
(ici) trois fichiers.
Si tu ne changes rien, à chaque fois que tu lances une application, elle
va commencer à écrire dans le fichier capture.raw, et ça risque d'être
moche (soit elle efface le fichier de l'instance précédente, soit les deux
écritures dans le fichier se mélangent). Donc il faut trouver un moyen
ok, ici, tu parles encore de 3 fichiers
pour configurer à la volée le fichier de sortie. Ça va donner quelque
Ici, il n'y a plus qu'un fichier ?
chose comme (non testé ; en supposant que plug+dmix s'appelle dmixplug) :
pcm.capture-yes {
type file
@args [ FILE ]
@args.file {
type string default {
@fonc getenv vars [ ALSA_CAPTURE_FILE ] default "/dev/null"
}
}
file $FILE
slave.pcm dmixplug
}
pcm.capture-no {
@func refer
name "pcm.dmixplug"
}
pcm.!default {
@func refer
name "pcm.capture-or-not"
}
La variable d'environnement ALSA_CAPTURE, qui doit valoir yes ou no (ou ne
pas être définie) active ou désactive la capture, et ALSA_CAPTURE_FILE
indique le fichier.
si je n'indique qu'un seul nom de fichier, je retombe sur le risque de
mocheté que tu évoquais avant, non ?
On notera que j'ai utilisé partout des @func refer plutôt que type plug,
pour éviter d'insérer des plugins plug à tout bout de champ. Le résultat
As-tu des tutoriels à me conseiller pour apprendre à apprivoiser ce
langage (notamment sur ces @func refer) assez peu intuitif ?
> est que la cpature, si elle a lieu, est directement branchée à
> l'application, sans changement de format.
de c2, évidemment). Quand on a bien vérifié que ça marchait, on peut
Ok (je peux désormais enregistrer du PCM grâce à ta remarque sur plug).
Après, je bloque :
utiliser des variables d'environnement et faire un branchement conditionnel, pour activer la capture sans changer le fichier de config.
- Un dmix ne peut pas se brancher que directement sur une carte son, on ne peut pas insérer de plugin entre dmix et hw. Donc la structure que tu vas devoir adopter va être la suivante :
Évidemment, j'ai dessiné trois fois [plug] et [file], mais dans le fichier de configuration, ça n'apparaît qu'une fois.
ok mais à l'usage, j'en déduis que je (ou plutôt ALSA) vais jongler avec (ici) trois fichiers.
Si tu ne changes rien, à chaque fois que tu lances une application, elle va commencer à écrire dans le fichier capture.raw, et ça risque d'être moche (soit elle efface le fichier de l'instance précédente, soit les deux écritures dans le fichier se mélangent). Donc il faut trouver un moyen
ok, ici, tu parles encore de 3 fichiers
pour configurer à la volée le fichier de sortie. Ça va donner quelque
Ici, il n'y a plus qu'un fichier ?
chose comme (non testé ; en supposant que plug+dmix s'appelle dmixplug) :
pcm.capture-yes { type file @args [ FILE ] @args.file { type string default { @fonc getenv vars [ ALSA_CAPTURE_FILE ] default "/dev/null" } } file $FILE slave.pcm dmixplug }
pcm.capture-no { @func refer name "pcm.dmixplug" }
pcm.!default { @func refer name "pcm.capture-or-not" }
La variable d'environnement ALSA_CAPTURE, qui doit valoir yes ou no (ou ne pas être définie) active ou désactive la capture, et ALSA_CAPTURE_FILE indique le fichier.
si je n'indique qu'un seul nom de fichier, je retombe sur le risque de mocheté que tu évoquais avant, non ?
On notera que j'ai utilisé partout des @func refer plutôt que type plug, pour éviter d'insérer des plugins plug à tout bout de champ. Le résultat
As-tu des tutoriels à me conseiller pour apprendre à apprivoiser ce langage (notamment sur ces @func refer) assez peu intuitif ?
> est que la cpature, si elle a lieu, est directement branchée à > l'application, sans changement de format.
Nicolas George
kkwweett wrote in message <4881ca03$0$929$:
ok mais à l'usage, j'en déduis que je (ou plutôt ALSA) vais jongler avec (ici) trois fichiers.
Non, tel quel c'est trois fois le même fichier.
Ici, il n'y a plus qu'un fichier ?
Non, au contraire, maintenant il y a trois fichiers différents, justement.
si je n'indique qu'un seul nom de fichier, je retombe sur le risque de mocheté que tu évoquais avant, non ?
Oui.
As-tu des tutoriels à me conseiller pour apprendre à apprivoiser ce langage (notamment sur ces @func refer) assez peu intuitif ?
oui, j'étais tombé sur cette page (le Plugin: asym m'avait d'ailleurs semblé intéressant pour ce que je cherche) mais faute d'exemples concrets, j'ai vite été découragé.
Nicolas George a écrit :
kkwweett wrote in message <4881ca03$0$929$ba4acef3@news.orange.fr>:
ok mais à l'usage, j'en déduis que je (ou plutôt ALSA) vais jongler avec
(ici) trois fichiers.
Non, tel quel c'est trois fois le même fichier.
Ici, il n'y a plus qu'un fichier ?
Non, au contraire, maintenant il y a trois fichiers différents, justement.
tu veux dire que je dois "export ALSA_CAPTURE_FILE=" avec un nom
différent pour chacune des sources considérées ?
oui, j'étais tombé sur cette page (le Plugin: asym m'avait d'ailleurs
semblé intéressant pour ce que je cherche) mais faute d'exemples
concrets, j'ai vite été découragé.
oui, j'étais tombé sur cette page (le Plugin: asym m'avait d'ailleurs semblé intéressant pour ce que je cherche) mais faute d'exemples concrets, j'ai vite été découragé.
Nicolas George
kkwweett wrote in message <4881e475$0$916$:
tu veux dire que je dois "export ALSA_CAPTURE_FILE=" avec un nom différent pour chacune des sources considérées ?
Oui, précisément.
kkwweett wrote in message <4881e475$0$916$ba4acef3@news.orange.fr>:
tu veux dire que je dois "export ALSA_CAPTURE_FILE=" avec un nom
différent pour chacune des sources considérées ?
tu veux dire que je dois "export ALSA_CAPTURE_FILE=" avec un nom différent pour chacune des sources considérées ?
Oui, précisément.
kkwweett
Nicolas George a écrit :
kkwweett wrote in message <4881e475$0$916$:
tu veux dire que je dois "export ALSA_CAPTURE_FILE=" avec un nom différent pour chacune des sources considérées ?
Oui, précisément.
Bon, ça implique que je dois moi-même mixer les résultats partiels pour finaliser mon flux.wav ...
ça a de bons côtés (retoucher les gains...) mais c'est dommage de devoir refaire le travail qui est fait en parallèle par dmix si celui-ci est convenable (à l'oreille)...
Sur la page de l'ALSA project que tu m'as indiquée, il y a aussi le plugin: copy. Je vais voir ce que je peux en tirer
Merci pour tous ces éclairements
Nicolas George a écrit :
kkwweett wrote in message <4881e475$0$916$ba4acef3@news.orange.fr>:
tu veux dire que je dois "export ALSA_CAPTURE_FILE=" avec un nom
différent pour chacune des sources considérées ?
Oui, précisément.
Bon, ça implique que je dois moi-même mixer les résultats partiels pour
finaliser mon flux.wav ...
ça a de bons côtés (retoucher les gains...) mais c'est dommage de devoir
refaire le travail qui est fait en parallèle par dmix si celui-ci est
convenable (à l'oreille)...
Sur la page de l'ALSA project que tu m'as indiquée, il y a aussi le
plugin: copy. Je vais voir ce que je peux en tirer
tu veux dire que je dois "export ALSA_CAPTURE_FILE=" avec un nom différent pour chacune des sources considérées ?
Oui, précisément.
Bon, ça implique que je dois moi-même mixer les résultats partiels pour finaliser mon flux.wav ...
ça a de bons côtés (retoucher les gains...) mais c'est dommage de devoir refaire le travail qui est fait en parallèle par dmix si celui-ci est convenable (à l'oreille)...
Sur la page de l'ALSA project que tu m'as indiquée, il y a aussi le plugin: copy. Je vais voir ce que je peux en tirer
