Sous Mageia 2 sont pourtant installés les paquets libsamplerate0,
lib64samplerate0, libsamplerate-devel, lib64samplerate-devel,
libsamplerate-progs, alsa-tools et alsa-utils et forcément leurs dépendances.
Sous Mageia 2 sont pourtant installés les paquets libsamplerate0, lib64samplerate0, libsamplerate-devel, lib64samplerate-devel, libsamplerate-progs, alsa-tools et alsa-utils et forcément leurs dépendances.
Qu'est-ce qui me manque encore ?
Il faudrait probablement recompiler alsaloop avec libsamplerate. Essaie --resample à tout hasard. Ou bien -P plughw:0,0.
Geo Cherchetout , dans le message <km84dr$1qdn$1@obelix.gegeweb.org>, a
écrit :
Je souhaiterais utiliser la commande alsaloop pour renvoyer la sortie d'une
carte son vers l'entrée d'une autre carte son, mais :
Sous Mageia 2 sont pourtant installés les paquets libsamplerate0,
lib64samplerate0, libsamplerate-devel, lib64samplerate-devel,
libsamplerate-progs, alsa-tools et alsa-utils et forcément leurs dépendances.
Qu'est-ce qui me manque encore ?
Il faudrait probablement recompiler alsaloop avec libsamplerate. Essaie
--resample à tout hasard. Ou bien -P plughw:0,0.
Sous Mageia 2 sont pourtant installés les paquets libsamplerate0, lib64samplerate0, libsamplerate-devel, lib64samplerate-devel, libsamplerate-progs, alsa-tools et alsa-utils et forcément leurs dépendances.
Qu'est-ce qui me manque encore ?
Il faudrait probablement recompiler alsaloop avec libsamplerate. Essaie --resample à tout hasard. Ou bien -P plughw:0,0.
Geo Cherchetout
Le 06/05/2013 13:45, *Nicolas George* a écrit fort à propos :
Quel est le but final.
Faire émettre un son enregistré dans un fichier par un softphone ne proposant pas cette fonctionnalité (Ekiga) tout en évitant l'interconnexion par câble entre cartes.
Qu'est-ce qui me manque encore ?
Il faudrait probablement recompiler alsaloop avec libsamplerate. Essaie --resample à tout hasard. Ou bien -P plughw:0,0.
Je viens d'essayer. Merci mais j'obtiens toujours le même message d'erreur.
J'ai regardé le fichier specs du rpm.src d'alsa-utils sans y voir aucune référence à libsamplerate.
Poussant un peu plus loin, quand dans les sources d'alsa-utils je fais ./configure --help (ou help=recursive), aucune option concernant libsamplerate n'est proposée. Quelle formule magique puis-je essayer ?
Le 06/05/2013 13:45, *Nicolas George* a écrit fort à propos :
Quel est le but final.
Faire émettre un son enregistré dans un fichier par un softphone ne
proposant pas cette fonctionnalité (Ekiga) tout en évitant l'interconnexion
par câble entre cartes.
Qu'est-ce qui me manque encore ?
Il faudrait probablement recompiler alsaloop avec libsamplerate. Essaie
--resample à tout hasard. Ou bien -P plughw:0,0.
Je viens d'essayer. Merci mais j'obtiens toujours le même message d'erreur.
J'ai regardé le fichier specs du rpm.src d'alsa-utils sans y voir aucune
référence à libsamplerate.
Poussant un peu plus loin, quand dans les sources d'alsa-utils je fais
./configure --help (ou help=recursive), aucune option concernant
libsamplerate n'est proposée. Quelle formule magique puis-je essayer ?
Le 06/05/2013 13:45, *Nicolas George* a écrit fort à propos :
Quel est le but final.
Faire émettre un son enregistré dans un fichier par un softphone ne proposant pas cette fonctionnalité (Ekiga) tout en évitant l'interconnexion par câble entre cartes.
Qu'est-ce qui me manque encore ?
Il faudrait probablement recompiler alsaloop avec libsamplerate. Essaie --resample à tout hasard. Ou bien -P plughw:0,0.
Je viens d'essayer. Merci mais j'obtiens toujours le même message d'erreur.
J'ai regardé le fichier specs du rpm.src d'alsa-utils sans y voir aucune référence à libsamplerate.
Poussant un peu plus loin, quand dans les sources d'alsa-utils je fais ./configure --help (ou help=recursive), aucune option concernant libsamplerate n'est proposée. Quelle formule magique puis-je essayer ?
Nicolas George
Geo Cherchetout , dans le message <km888d$21qv$, a écrit :
Faire émettre un son enregistré dans un fichier par un softphone ne proposant pas cette fonctionnalité (Ekiga) tout en évitant l'interconnexion par câble entre cartes.
Si ekiga utilise effectivement ALSA, alors il me semble nettement plus efficace d'utiliser un plugin file:
pcm.from_file { type file infile "/path/to/the/file" }
Poussant un peu plus loin, quand dans les sources d'alsa-utils je fais ./configure --help (ou help=recursive), aucune option concernant libsamplerate n'est proposée. Quelle formule magique puis-je essayer ?
Est-ce que libsamplerate est mentionnée dans le code de configure ?
Geo Cherchetout , dans le message <km888d$21qv$1@obelix.gegeweb.org>, a
écrit :
Faire émettre un son enregistré dans un fichier par un softphone ne
proposant pas cette fonctionnalité (Ekiga) tout en évitant l'interconnexion
par câble entre cartes.
Si ekiga utilise effectivement ALSA, alors il me semble nettement plus
efficace d'utiliser un plugin file:
pcm.from_file {
type file
infile "/path/to/the/file"
}
Poussant un peu plus loin, quand dans les sources d'alsa-utils je fais
./configure --help (ou help=recursive), aucune option concernant
libsamplerate n'est proposée. Quelle formule magique puis-je essayer ?
Est-ce que libsamplerate est mentionnée dans le code de configure ?
Geo Cherchetout , dans le message <km888d$21qv$, a écrit :
Faire émettre un son enregistré dans un fichier par un softphone ne proposant pas cette fonctionnalité (Ekiga) tout en évitant l'interconnexion par câble entre cartes.
Si ekiga utilise effectivement ALSA, alors il me semble nettement plus efficace d'utiliser un plugin file:
pcm.from_file { type file infile "/path/to/the/file" }
Poussant un peu plus loin, quand dans les sources d'alsa-utils je fais ./configure --help (ou help=recursive), aucune option concernant libsamplerate n'est proposée. Quelle formule magique puis-je essayer ?
Est-ce que libsamplerate est mentionnée dans le code de configure ?
Geo Cherchetout
Le 06/05/2013 14:52, *Nicolas George* a écrit fort à propos :
Faire émettre un son enregistré dans un fichier par un softphone ne proposant pas cette fonctionnalité (Ekiga) tout en évitant l'interconnexion par câble entre cartes.
Si ekiga utilise effectivement ALSA, alors il me semble nettement plus efficace d'utiliser un plugin file:
pcm.from_file { type file infile "/path/to/the/file" }
Pour un essai, j'ai donc mis ceci dans ~/.asoundrc
pcm.from_file { type file infile "/home/toto/Musique/la-440-8000.wav" }
et avec gconf-editor, dans la section des devices audio d'Ekiga, donné à input_device la valeur from_file. Ekiga ne se plaint pas mais n'affiche qu'en grisé ce périphérique dans son panneau de configuration et ne l'utilise pas lors d'une communication. L'application détecte bien et utilise sans difficulté les autres périphériques ALSA.
D'autre part, quand je fais arecord -l aucun from_file ne figure dans la réponse. Il y a peut-être autre chose à faire ?
Le 06/05/2013 14:52, *Nicolas George* a écrit fort à propos :
Faire émettre un son enregistré dans un fichier par un softphone ne
proposant pas cette fonctionnalité (Ekiga) tout en évitant l'interconnexion
par câble entre cartes.
Si ekiga utilise effectivement ALSA, alors il me semble nettement plus
efficace d'utiliser un plugin file:
pcm.from_file {
type file
infile "/path/to/the/file"
}
Pour un essai, j'ai donc mis ceci dans ~/.asoundrc
pcm.from_file {
type file
infile "/home/toto/Musique/la-440-8000.wav"
}
et avec gconf-editor, dans la section des devices audio d'Ekiga, donné à
input_device la valeur from_file. Ekiga ne se plaint pas mais n'affiche
qu'en grisé ce périphérique dans son panneau de configuration et ne
l'utilise pas lors d'une communication. L'application détecte bien et
utilise sans difficulté les autres périphériques ALSA.
D'autre part, quand je fais arecord -l aucun from_file ne figure dans la
réponse. Il y a peut-être autre chose à faire ?
Le 06/05/2013 14:52, *Nicolas George* a écrit fort à propos :
Faire émettre un son enregistré dans un fichier par un softphone ne proposant pas cette fonctionnalité (Ekiga) tout en évitant l'interconnexion par câble entre cartes.
Si ekiga utilise effectivement ALSA, alors il me semble nettement plus efficace d'utiliser un plugin file:
pcm.from_file { type file infile "/path/to/the/file" }
Pour un essai, j'ai donc mis ceci dans ~/.asoundrc
pcm.from_file { type file infile "/home/toto/Musique/la-440-8000.wav" }
et avec gconf-editor, dans la section des devices audio d'Ekiga, donné à input_device la valeur from_file. Ekiga ne se plaint pas mais n'affiche qu'en grisé ce périphérique dans son panneau de configuration et ne l'utilise pas lors d'une communication. L'application détecte bien et utilise sans difficulté les autres périphériques ALSA.
D'autre part, quand je fais arecord -l aucun from_file ne figure dans la réponse. Il y a peut-être autre chose à faire ?
Geo Cherchetout
Le 06/05/2013 14:52, *Nicolas George* a écrit fort à propos :
Poussant un peu plus loin, quand dans les sources d'alsa-utils je fais ./configure --help (ou help=recursive), aucune option concernant libsamplerate n'est proposée. Quelle formule magique puis-je essayer ?
Est-ce que libsamplerate est mentionnée dans le code de configure ?
Non, cette chaîne de caractères n'y figure pas.
Le 06/05/2013 14:52, *Nicolas George* a écrit fort à propos :
Poussant un peu plus loin, quand dans les sources d'alsa-utils je fais
./configure --help (ou help=recursive), aucune option concernant
libsamplerate n'est proposée. Quelle formule magique puis-je essayer ?
Est-ce que libsamplerate est mentionnée dans le code de configure ?
Le 06/05/2013 14:52, *Nicolas George* a écrit fort à propos :
Poussant un peu plus loin, quand dans les sources d'alsa-utils je fais ./configure --help (ou help=recursive), aucune option concernant libsamplerate n'est proposée. Quelle formule magique puis-je essayer ?
Est-ce que libsamplerate est mentionnée dans le code de configure ?
Non, cette chaîne de caractères n'y figure pas.
Geo Cherchetout
Le 06/05/2013 13:33, j'ai écrit :
Je souhaiterais utiliser la commande alsaloop pour renvoyer la sortie d'une carte son vers l'entrée d'une autre carte son, mais :
J'ai fini par reconstruire dans mon biotope local le rpm à partir du src.rpm sans rien y modifier et, une fois installé, la commande fonctionne. :-) Je ferai des essais plus prolongés demain avant de rédiger un rapport de bug.
Le 06/05/2013 13:33, j'ai écrit :
Je souhaiterais utiliser la commande alsaloop pour renvoyer la sortie d'une
carte son vers l'entrée d'une autre carte son, mais :
J'ai fini par reconstruire dans mon biotope local le rpm à partir du src.rpm
sans rien y modifier et, une fois installé, la commande fonctionne. :-) Je
ferai des essais plus prolongés demain avant de rédiger un rapport de bug.
J'ai fini par reconstruire dans mon biotope local le rpm à partir du src.rpm sans rien y modifier et, une fois installé, la commande fonctionne. :-) Je ferai des essais plus prolongés demain avant de rédiger un rapport de bug.
dyrmak
En 31 lignes Geo Cherchetout a écrit dans news:km8hbt$2jm5$ le lundi, 06 mai 2013 à 17:14:05 :
Le 06/05/2013 14:52, *Nicolas George* a écrit fort à propos :
Faire émettre un son enregistré dans un fichier par un softphone ne proposant pas cette fonctionnalité (Ekiga) tout en évitant l'interconnexion par câble entre cartes.
Si ekiga utilise effectivement ALSA, alors il me semble nettement plus efficace d'utiliser un plugin file:
pcm.from_file { type file infile "/path/to/the/file" }
Pour un essai, j'ai donc mis ceci dans ~/.asoundrc
pcm.from_file { type file infile "/home/toto/Musique/la-440-8000.wav" }
et avec gconf-editor, dans la section des devices audio d'Ekiga, donné à input_device la valeur from_file. Ekiga ne se plaint pas mais n'affiche qu'en grisé ce périphérique dans son panneau de configuration et ne l'utilise pas lors d'une communication. L'application détecte bien et utilise sans difficulté les autres périphériques ALSA.
Cette méthode ne fonctionne pas du tout chez-moi, mais la méthode pulse-audio fonctionne. Pourquoi ne pas laisser la valeur d'origine dans gconf-editor ( ne pas y toucher ) et détecter les périphériques avec l'interface d'Ekiga ? (Édition --> Préférences --> Audio) Et relancer ensuite Ekiga voir si ça le détecte ?
Quand je dis que ça marche chez-moi, sans deux cartes son:
- Enregistrement de pulse-audio sous monitor - audacious ( on lit ce qu'on veut, fichier, CD, radio ) - Appel à partir d'un autre soft-phone et on écoute dès que l'appel est accepté.
Bémol bien sûr , intervention manuelle pour répondre.
dyrmak -- Las llantas desinfladas ++++ --- ++++ Linux operating system ++++ --- ++++
En 31 lignes Geo Cherchetout a écrit
dans news:km8hbt$2jm5$1@obelix.gegeweb.org
le lundi, 06 mai 2013 à 17:14:05 :
Le 06/05/2013 14:52, *Nicolas George* a écrit fort à propos :
Faire émettre un son enregistré dans un fichier par un softphone ne
proposant pas cette fonctionnalité (Ekiga) tout en évitant l'interconnexion
par câble entre cartes.
Si ekiga utilise effectivement ALSA, alors il me semble nettement plus
efficace d'utiliser un plugin file:
pcm.from_file {
type file
infile "/path/to/the/file"
}
Pour un essai, j'ai donc mis ceci dans ~/.asoundrc
pcm.from_file {
type file
infile "/home/toto/Musique/la-440-8000.wav"
}
et avec gconf-editor, dans la section des devices audio d'Ekiga, donné à
input_device la valeur from_file. Ekiga ne se plaint pas mais n'affiche
qu'en grisé ce périphérique dans son panneau de configuration et ne
l'utilise pas lors d'une communication. L'application détecte bien et
utilise sans difficulté les autres périphériques ALSA.
Cette méthode ne fonctionne pas du tout chez-moi, mais la méthode
pulse-audio fonctionne. Pourquoi ne pas laisser la valeur d'origine
dans gconf-editor ( ne pas y toucher ) et détecter les périphériques
avec l'interface d'Ekiga ? (Édition --> Préférences --> Audio) Et relancer
ensuite Ekiga voir si ça le détecte ?
Quand je dis que ça marche chez-moi, sans deux cartes son:
- Enregistrement de pulse-audio sous monitor
- audacious ( on lit ce qu'on veut, fichier, CD, radio )
- Appel à partir d'un autre soft-phone et on écoute dès
que l'appel est accepté.
Bémol bien sûr , intervention manuelle pour répondre.
dyrmak
--
Las llantas desinfladas
++++ --- ++++
Linux operating system
++++ --- ++++
En 31 lignes Geo Cherchetout a écrit dans news:km8hbt$2jm5$ le lundi, 06 mai 2013 à 17:14:05 :
Le 06/05/2013 14:52, *Nicolas George* a écrit fort à propos :
Faire émettre un son enregistré dans un fichier par un softphone ne proposant pas cette fonctionnalité (Ekiga) tout en évitant l'interconnexion par câble entre cartes.
Si ekiga utilise effectivement ALSA, alors il me semble nettement plus efficace d'utiliser un plugin file:
pcm.from_file { type file infile "/path/to/the/file" }
Pour un essai, j'ai donc mis ceci dans ~/.asoundrc
pcm.from_file { type file infile "/home/toto/Musique/la-440-8000.wav" }
et avec gconf-editor, dans la section des devices audio d'Ekiga, donné à input_device la valeur from_file. Ekiga ne se plaint pas mais n'affiche qu'en grisé ce périphérique dans son panneau de configuration et ne l'utilise pas lors d'une communication. L'application détecte bien et utilise sans difficulté les autres périphériques ALSA.
Cette méthode ne fonctionne pas du tout chez-moi, mais la méthode pulse-audio fonctionne. Pourquoi ne pas laisser la valeur d'origine dans gconf-editor ( ne pas y toucher ) et détecter les périphériques avec l'interface d'Ekiga ? (Édition --> Préférences --> Audio) Et relancer ensuite Ekiga voir si ça le détecte ?
Quand je dis que ça marche chez-moi, sans deux cartes son:
- Enregistrement de pulse-audio sous monitor - audacious ( on lit ce qu'on veut, fichier, CD, radio ) - Appel à partir d'un autre soft-phone et on écoute dès que l'appel est accepté.
Bémol bien sûr , intervention manuelle pour répondre.
dyrmak -- Las llantas desinfladas ++++ --- ++++ Linux operating system ++++ --- ++++
Geo Cherchetout
Le 07/05/2013 10:23, *dyrmak* a écrit fort à propos :
Cette méthode ne fonctionne pas du tout chez-moi, mais la méthode pulse-audio fonctionne. Pourquoi ne pas laisser la valeur d'origine dans gconf-editor ( ne pas y toucher ) et détecter les périphériques avec l'interface d'Ekiga ? (Édition --> Préférences --> Audio) Et relancer ensuite Ekiga voir si ça le détecte ? Quand je dis que ça marche chez-moi, sans deux cartes son:
- Enregistrement de pulse-audio sous monitor - audacious ( on lit ce qu'on veut, fichier, CD, radio ) - Appel à partir d'un autre soft-phone et on écoute dès que l'appel est accepté.
Bémol bien sûr , intervention manuelle pour répondre.
dyrmak
Le bon résultat obtenu hier soir, probablement par erreur, avec alsaloop n'étant pas reproductible aujourd'hui, j'ai suivi ton conseil sans bien comprendre tes explications. Après force tâtonnements, je dois reconnaître que ça marche, je me demande par quel miracle. :-) Merci. Le son transmis de cette façon semble de moins bonne qualité qu'avec le grossier procédé du cordon reliant la sortie d'une carte à l'entrée de l'autre. Réponse plus faible dans les aiguës. Mais c'est peut-être Audacious qui est mal réglé...
Le 07/05/2013 10:23, *dyrmak* a écrit fort à propos :
Cette méthode ne fonctionne pas du tout chez-moi, mais la méthode
pulse-audio fonctionne. Pourquoi ne pas laisser la valeur d'origine
dans gconf-editor ( ne pas y toucher ) et détecter les périphériques
avec l'interface d'Ekiga ? (Édition --> Préférences --> Audio) Et relancer
ensuite Ekiga voir si ça le détecte ?
Quand je dis que ça marche chez-moi, sans deux cartes son:
- Enregistrement de pulse-audio sous monitor
- audacious ( on lit ce qu'on veut, fichier, CD, radio )
- Appel à partir d'un autre soft-phone et on écoute dès
que l'appel est accepté.
Bémol bien sûr , intervention manuelle pour répondre.
dyrmak
Le bon résultat obtenu hier soir, probablement par erreur, avec alsaloop
n'étant pas reproductible aujourd'hui, j'ai suivi ton conseil sans bien
comprendre tes explications. Après force tâtonnements, je dois reconnaître
que ça marche, je me demande par quel miracle. :-) Merci.
Le son transmis de cette façon semble de moins bonne qualité qu'avec le
grossier procédé du cordon reliant la sortie d'une carte à l'entrée de
l'autre. Réponse plus faible dans les aiguës. Mais c'est peut-être Audacious
qui est mal réglé...
Le 07/05/2013 10:23, *dyrmak* a écrit fort à propos :
Cette méthode ne fonctionne pas du tout chez-moi, mais la méthode pulse-audio fonctionne. Pourquoi ne pas laisser la valeur d'origine dans gconf-editor ( ne pas y toucher ) et détecter les périphériques avec l'interface d'Ekiga ? (Édition --> Préférences --> Audio) Et relancer ensuite Ekiga voir si ça le détecte ? Quand je dis que ça marche chez-moi, sans deux cartes son:
- Enregistrement de pulse-audio sous monitor - audacious ( on lit ce qu'on veut, fichier, CD, radio ) - Appel à partir d'un autre soft-phone et on écoute dès que l'appel est accepté.
Bémol bien sûr , intervention manuelle pour répondre.
dyrmak
Le bon résultat obtenu hier soir, probablement par erreur, avec alsaloop n'étant pas reproductible aujourd'hui, j'ai suivi ton conseil sans bien comprendre tes explications. Après force tâtonnements, je dois reconnaître que ça marche, je me demande par quel miracle. :-) Merci. Le son transmis de cette façon semble de moins bonne qualité qu'avec le grossier procédé du cordon reliant la sortie d'une carte à l'entrée de l'autre. Réponse plus faible dans les aiguës. Mais c'est peut-être Audacious qui est mal réglé...
Geo Cherchetout
Le son transmis de cette façon semble de moins bonne qualité qu'avec le grossier procédé du cordon reliant la sortie d'une carte à l'entrée de l'autre. Réponse plus faible dans les aiguës. Mais c'est peut-être Audacious qui est mal réglé...
Non, c'est pareil avec Audacity comme lecteur. Et puis le son transmis est interrompu pendant 3 secondes toutes les 23 secondes. (20" on, 3" off, etc) Encore une histoire de buffer qui déborde ou qui se vide... Tu n'as pas ce problème, Dyrmak ?
Le son transmis de cette façon semble de moins bonne qualité qu'avec le
grossier procédé du cordon reliant la sortie d'une carte à l'entrée de
l'autre. Réponse plus faible dans les aiguës. Mais c'est peut-être Audacious
qui est mal réglé...
Non, c'est pareil avec Audacity comme lecteur. Et puis le son transmis est
interrompu pendant 3 secondes toutes les 23 secondes. (20" on, 3" off, etc)
Encore une histoire de buffer qui déborde ou qui se vide... Tu n'as pas ce
problème, Dyrmak ?
Le son transmis de cette façon semble de moins bonne qualité qu'avec le grossier procédé du cordon reliant la sortie d'une carte à l'entrée de l'autre. Réponse plus faible dans les aiguës. Mais c'est peut-être Audacious qui est mal réglé...
Non, c'est pareil avec Audacity comme lecteur. Et puis le son transmis est interrompu pendant 3 secondes toutes les 23 secondes. (20" on, 3" off, etc) Encore une histoire de buffer qui déborde ou qui se vide... Tu n'as pas ce problème, Dyrmak ?
dyrmak
En 28 lignes Geo Cherchetout a écrit dans news:kmb3un$21lt$ le mardi, 07 mai 2013 à 16:43:34 :
Quand je dis que ça marche chez-moi, sans deux cartes son:
- Enregistrement de pulse-audio sous monitor - audacious ( on lit ce qu'on veut, fichier, CD, radio ) - Appel à partir d'un autre soft-phone et on écoute dès que l'appel est accepté.
Bémol bien sûr , intervention manuelle pour répondre.
dyrmak
Le bon résultat obtenu hier soir, probablement par erreur, avec alsaloop n'étant pas reproductible aujourd'hui, j'ai suivi ton conseil sans bien comprendre tes explications. Après force tâtonnements, je dois reconnaître que ça marche, je me demande par quel miracle. :-) Merci. Le son transmis de cette façon semble de moins bonne qualité qu'avec le grossier procédé du cordon reliant la sortie d'une carte à l'entrée de l'autre. Réponse plus faible dans les aiguës. Mais c'est peut-être Audacious qui est mal réglé...
Mettre pulse-audio en mode moniteur ( bricole à faire à l'aide de pavucontrol ) veut dire ceci pour un visiophone:
Un microphone virtuel remplace le microphone réel (ligne ou webcam intégrée ) et ce microphone virtuel va capter le son de TOUTE application qui sera lancée dans la machine de ce visiophone.
Ce qui fait que si un correspondant parle à travers son microphone, sa voix va être reproduite par l'application videophone et sa voix rebrousse chemin à travers le microphone virtuel ( c'est l'echo ).
Le son est de moins bonne qualité, un peu métallique, c'est effectivement mieux en injectant une source sonore à travers l'entrée microphone de ligne.
dyrmak -- Nadie lo quizo, nadie lo amó ++++ --- ++++ Linux operating system ++++ --- ++++
En 28 lignes Geo Cherchetout a écrit
dans news:kmb3un$21lt$1@obelix.gegeweb.org
le mardi, 07 mai 2013 à 16:43:34 :
Quand je dis que ça marche chez-moi, sans deux cartes son:
- Enregistrement de pulse-audio sous monitor
- audacious ( on lit ce qu'on veut, fichier, CD, radio )
- Appel à partir d'un autre soft-phone et on écoute dès
que l'appel est accepté.
Bémol bien sûr , intervention manuelle pour répondre.
dyrmak
Le bon résultat obtenu hier soir, probablement par erreur, avec alsaloop
n'étant pas reproductible aujourd'hui, j'ai suivi ton conseil sans bien
comprendre tes explications. Après force tâtonnements, je dois reconnaître
que ça marche, je me demande par quel miracle. :-) Merci.
Le son transmis de cette façon semble de moins bonne qualité qu'avec le
grossier procédé du cordon reliant la sortie d'une carte à l'entrée de
l'autre. Réponse plus faible dans les aiguës. Mais c'est peut-être Audacious
qui est mal réglé...
Mettre pulse-audio en mode moniteur ( bricole à faire à l'aide de
pavucontrol ) veut dire ceci pour un visiophone:
Un microphone virtuel remplace le microphone réel (ligne ou webcam
intégrée ) et ce microphone virtuel va capter le son de TOUTE
application qui sera lancée dans la machine de ce visiophone.
Ce qui fait que si un correspondant parle à travers son microphone, sa
voix va être reproduite par l'application videophone et sa voix
rebrousse chemin à travers le microphone virtuel ( c'est l'echo ).
Le son est de moins bonne qualité, un peu métallique, c'est
effectivement mieux en injectant une source sonore à travers l'entrée
microphone de ligne.
dyrmak
--
Nadie lo quizo, nadie lo amó
++++ --- ++++
Linux operating system
++++ --- ++++
En 28 lignes Geo Cherchetout a écrit dans news:kmb3un$21lt$ le mardi, 07 mai 2013 à 16:43:34 :
Quand je dis que ça marche chez-moi, sans deux cartes son:
- Enregistrement de pulse-audio sous monitor - audacious ( on lit ce qu'on veut, fichier, CD, radio ) - Appel à partir d'un autre soft-phone et on écoute dès que l'appel est accepté.
Bémol bien sûr , intervention manuelle pour répondre.
dyrmak
Le bon résultat obtenu hier soir, probablement par erreur, avec alsaloop n'étant pas reproductible aujourd'hui, j'ai suivi ton conseil sans bien comprendre tes explications. Après force tâtonnements, je dois reconnaître que ça marche, je me demande par quel miracle. :-) Merci. Le son transmis de cette façon semble de moins bonne qualité qu'avec le grossier procédé du cordon reliant la sortie d'une carte à l'entrée de l'autre. Réponse plus faible dans les aiguës. Mais c'est peut-être Audacious qui est mal réglé...
Mettre pulse-audio en mode moniteur ( bricole à faire à l'aide de pavucontrol ) veut dire ceci pour un visiophone:
Un microphone virtuel remplace le microphone réel (ligne ou webcam intégrée ) et ce microphone virtuel va capter le son de TOUTE application qui sera lancée dans la machine de ce visiophone.
Ce qui fait que si un correspondant parle à travers son microphone, sa voix va être reproduite par l'application videophone et sa voix rebrousse chemin à travers le microphone virtuel ( c'est l'echo ).
Le son est de moins bonne qualité, un peu métallique, c'est effectivement mieux en injectant une source sonore à travers l'entrée microphone de ligne.
dyrmak -- Nadie lo quizo, nadie lo amó ++++ --- ++++ Linux operating system ++++ --- ++++