[Alsa] redirection audio sur EeePc 701

Le
kkwweett
Bonjour,

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 :




"
ALSA Audio Debug v0.1.0 - samedi 19 juillet 2008, 00:39:11 (UTC+0200)
http://alsa.opensrc.org/aadebug
http://www.gnu.org/licenses/gpl.txt

Kernel -
Linux asus-1852668548 2.6.21.4-eeepc #2 Mon Oct 15 12:49:37 EDT 2007
i686 GNU/Linux

Loaded Modules --
snd_pcm_oss 35776 0
snd_mixer_oss 13056 1 snd_pcm_oss
snd_seq_dummy 1988 0
snd_seq 33456 1 snd_seq_dummy
snd_seq_device 4876 2 snd_seq_dummy,snd_seq
snd_hda_intel 14424 0
snd_hda_codec 191776 1 snd_hda_intel
snd_pcm 52936 3 snd_pcm_oss,snd_hda_intel,snd_hda_codec
snd_timer 15300 2 snd_seq,snd_pcm
snd 32964 8
snd_pcm_oss,snd_mixer_oss,snd_seq,snd_seq_device,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer
snd_page_alloc 6472 2 snd_hda_intel,snd_pcm

Modprobe Conf

Proc Asound --
Advanced Linux Sound Architecture Driver Version 1.0.14rc3 (Wed Mar 14
07:25:50 2007 UTC).
0 [Intel ]: HDA-Intel - HDA Intel
HDA Intel at 0xf7eb8000 irq 5
2: : timer
3: [ 0- 0]: digital audio playback
4: [ 0- 0]: digital audio capture
5: [ 0] : control
6: : sequencer
00-00: ALC861VD Analog : ALC861VD Analog : playback 1 : capture 2
Client info
cur clients : 2
peak clients : 3
max clients : 192

Client 0 : "System" [Kernel]
Port 0 : "Timer" (Rwe-)
Port 1 : "Announce" (R-e-)
Client 14 : "Midi Through" [Kernel]
Port 0 : "Midi Through Port-0" (RWe-)

Dev Snd
controlC0 pcmC0D0c pcmC0D0p pcmC0D1p seq timer

CPU -
model name : Intel(R) Celeron(R) M processor 900MHz
cpu MHz : 900.000

RAM -
MemTotal: 508328 kB
SwapTotal: 0 kB

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 ?

Merci d'avance.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #16368451
kkwweett wrote in message
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 :

[carte son]
^
|
|
[dmix]
/ |
/ |
source1 src2 source3

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 :

ffmpeg -f s16le -ar 44100 -ac 2 -i /tmp/capture.raw capture.wav

Ou sox :

sox -t raw -r 44100 -c 2 -s -w /tmp/capture.raw capture.wav

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 :

[carte son]
^
|
|
[dmix]
/ |
/ |
[plug] [plug] [plug]
| | |
| | |
[file] [file] [file]
| | |
| | |
source1 source2 source3

É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.capture-or-not {
@func refer
name {
@func concat
strings [
"pcm.capture-"
{ @func getenv vars [ ALSA_CAPTURE ] default "no" }
]
}
}

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
Le #16368711
>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
Le #16368701
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
Le #16368851
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 !
kkwweett
Le #16369281
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 :

[carte son]
^
|
|
[dmix]
/ |
/ |
[plug] [plug] [plug]
| | |
| | |
[file] [file] [file]
| | |
| | |
source1 source2 source3

É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.capture-or-not {
@func refer
name {
@func concat
strings [
"pcm.capture-"
{ @func getenv vars [ ALSA_CAPTURE ] default "no" }
]
}
}

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
Le #16369711
kkwweett wrote in message
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 ?



La doc est là :

http://www.alsa-project.org/alsa-doc/alsa-lib/conf.html
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html

Mais c'est franchement pénible à lire.
kkwweett
Le #16369981
Nicolas George a écrit :
kkwweett wrote in message
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 ?


http://www.alsa-project.org/alsa-doc/alsa-lib/conf.html
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html

Mais c'est franchement pénible à lire.



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
Le #16370151
kkwweett wrote in message
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
Le #16370261
Nicolas George a écrit :
kkwweett wrote in message
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
Publicité
Poster une réponse
Anonyme