<news:kmfgn8$q7v$
Il y a eu comme un couac de ma part, l'article en question
concerne l'echo qui se produit localement par injection
de la voix du correspondant dans le microphone virtuel du
pulse-audio en mode moniteur.
<news:kmfgn8$q7v$1@speranza.aioe.org>
Il y a eu comme un couac de ma part, l'article en question
concerne l'echo qui se produit localement par injection
de la voix du correspondant dans le microphone virtuel du
pulse-audio en mode moniteur.
<news:kmfgn8$q7v$
Il y a eu comme un couac de ma part, l'article en question
concerne l'echo qui se produit localement par injection
de la voix du correspondant dans le microphone virtuel du
pulse-audio en mode moniteur.
C'est dans libopal, --enable-t38 --enable-fax
ce qui le rend disponible pour d'autres applications dont modemt38
qu'il faut si j'y comprends quelque chose compiler soi-même
bien que sa configuration soit déjà prévue dans hylafax.
J'ai vu les réponses en fréquence des deux video-phones et bien que
celle de Linphone est assez régulière l'atténuation DB est quand même
très importante dans la zone 500HZ 3800HZ, est-ce que ce n'est
pas gênant vis-à-vis de la communication fax ? C'est dans
une zone de connaissance que j'ignore complètement ....
As-tu considéré l'utilisation de quelque chose plus léger comme
twinkle ? J'ai toujours été impressioné par la qualité sonore
de ce petit programme. C'est du pur téléphone-sip donc plus rapide
(moins gourmand). Mais voilà tiens, je ne sais pas si on peut le tester
en local ni si les codecs pour voix et fax sont utilisés.
Aussi il me semble que le protocole T38 pourrait t'affranchir de
mauvaises surprises sans besoin de re-inventer la roue, il a été
realisé pour que le tronçon T38 ( segment voip de la communication )
soit entièrement transparent entre deux machines fax classiques
par exemple, maintenant je n'ai pas lu assez pour comprendre
l'implémentation, mais il est question d'Hylafax et de compilation
d'un source modemt38 en liaison avec opal et ptlib
Au final on devrait avoir un faxstat du genre:
Hylafax scheduler
Modem ttyXX n°telvoip: Running and idle
J'avoue que cette implémentation n'est pas très claire pour moi,
un peu comme les 2fils-4fils que permettent la communication
modem local et le visiophone dont tu parles.
C'est dans libopal, --enable-t38 --enable-fax
ce qui le rend disponible pour d'autres applications dont modemt38
qu'il faut si j'y comprends quelque chose compiler soi-même
bien que sa configuration soit déjà prévue dans hylafax.
J'ai vu les réponses en fréquence des deux video-phones et bien que
celle de Linphone est assez régulière l'atténuation DB est quand même
très importante dans la zone 500HZ 3800HZ, est-ce que ce n'est
pas gênant vis-à-vis de la communication fax ? C'est dans
une zone de connaissance que j'ignore complètement ....
As-tu considéré l'utilisation de quelque chose plus léger comme
twinkle ? J'ai toujours été impressioné par la qualité sonore
de ce petit programme. C'est du pur téléphone-sip donc plus rapide
(moins gourmand). Mais voilà tiens, je ne sais pas si on peut le tester
en local ni si les codecs pour voix et fax sont utilisés.
Aussi il me semble que le protocole T38 pourrait t'affranchir de
mauvaises surprises sans besoin de re-inventer la roue, il a été
realisé pour que le tronçon T38 ( segment voip de la communication )
soit entièrement transparent entre deux machines fax classiques
par exemple, maintenant je n'ai pas lu assez pour comprendre
l'implémentation, mais il est question d'Hylafax et de compilation
d'un source modemt38 en liaison avec opal et ptlib
Au final on devrait avoir un faxstat du genre:
Hylafax scheduler
Modem ttyXX n°telvoip: Running and idle
J'avoue que cette implémentation n'est pas très claire pour moi,
un peu comme les 2fils-4fils que permettent la communication
modem local et le visiophone dont tu parles.
C'est dans libopal, --enable-t38 --enable-fax
ce qui le rend disponible pour d'autres applications dont modemt38
qu'il faut si j'y comprends quelque chose compiler soi-même
bien que sa configuration soit déjà prévue dans hylafax.
J'ai vu les réponses en fréquence des deux video-phones et bien que
celle de Linphone est assez régulière l'atténuation DB est quand même
très importante dans la zone 500HZ 3800HZ, est-ce que ce n'est
pas gênant vis-à-vis de la communication fax ? C'est dans
une zone de connaissance que j'ignore complètement ....
As-tu considéré l'utilisation de quelque chose plus léger comme
twinkle ? J'ai toujours été impressioné par la qualité sonore
de ce petit programme. C'est du pur téléphone-sip donc plus rapide
(moins gourmand). Mais voilà tiens, je ne sais pas si on peut le tester
en local ni si les codecs pour voix et fax sont utilisés.
Aussi il me semble que le protocole T38 pourrait t'affranchir de
mauvaises surprises sans besoin de re-inventer la roue, il a été
realisé pour que le tronçon T38 ( segment voip de la communication )
soit entièrement transparent entre deux machines fax classiques
par exemple, maintenant je n'ai pas lu assez pour comprendre
l'implémentation, mais il est question d'Hylafax et de compilation
d'un source modemt38 en liaison avec opal et ptlib
Au final on devrait avoir un faxstat du genre:
Hylafax scheduler
Modem ttyXX n°telvoip: Running and idle
J'avoue que cette implémentation n'est pas très claire pour moi,
un peu comme les 2fils-4fils que permettent la communication
modem local et le visiophone dont tu parles.
Tu peux donc envoyer de fax avec ta configuration actuelle et sauf
dans certains cas ça marche ?
Oui, grâce à Ekiga et mon compte OVH, mon premier succès fut l'envoi vers ma
ligne France-Telecom d'un fax de 36 pages au débit de 9600 bits/s, dont 6
avec une seule erreur et une avec 4 erreurs. Plus tard, avec une interface
deux fils/quatre fils plus simple, 15 pages au débit 14400 bits/s sans
aucune erreur. Les débits ne dépassent pas 9600 bits/s avec un vrai fax en
réception. Si la transmission risque de durer plus de quinze minutes, il
vaut mieux de toute façon se limiter à 9600 car le problème de buffer
commence à se manifester au cours de la seizième minute avec ma
configuration d'Ekiga, sans être aussi catastrophique qu'avec Linphone.
(constaté en local) J'ai réussi d'autres émissions mais j'ai des scrupules à
utiliser mon compte OVH sans autre utilité que celle de battre des records.
Pas réussi un seul envoi avec Linphone, la négociation entre terminaux
avorte immédiatement ou ne s'amorce même pas.
(En local et donc sans opérateur intermédiaire, avec Linphone aux deux
bouts, la transmission s'amorce et se poursuit sans problème pendant 20
minutes avec la valeur par défaut de audio_jitt_comp, quarante minutes en la
multipliant par deux, audio_adaptive_jitt_comp_enabled étant mis à zéro. Pas
moyen d'amorcer le dialogue entre fax avec Ekiga dans les mêmes conditions,
je ne comprends pas pourquoi.)
Quelle est alors ta configuration actuelle et comment tu fait pour
envoyer un fax ?
Je compte l'expliquer de façon détaillée un de ces jours sur ma page perso
Orange. Mes modems analogiques externes sont de marque Olitec et, côté
logiciel, efax et son script fax sont ce que j'ai trouvé de mieux pour la
réception, efax-gtk pour l'émission. Mes interfaces deux fils/quatre fils ne
comportent que deux résistances et un condensateur mais ne conviennent
qu'avec une carte son à sortie amplifiée comme mes CT4810.
On peut en parler en privé si tu veux, mon adresse de réponse est valide.
As-tu des messages correspondant à l'anomalie ?
La quelle ? J'aimerais notamment comprendre pourquoi Linphone, dont la
courbe de réponse est bien meilleure que celle d'Ekiga, ne me permet pas
d'amorcer l'envoi de fax via mon compte OVH, mais les messages délivrés par
efax et linphone ne seraient utiles qu'à quelqu'un connaissant les
protocoles de fax et SIP, pas spécialement en lien avec linux.
Tu peux donc envoyer de fax avec ta configuration actuelle et sauf
dans certains cas ça marche ?
Oui, grâce à Ekiga et mon compte OVH, mon premier succès fut l'envoi vers ma
ligne France-Telecom d'un fax de 36 pages au débit de 9600 bits/s, dont 6
avec une seule erreur et une avec 4 erreurs. Plus tard, avec une interface
deux fils/quatre fils plus simple, 15 pages au débit 14400 bits/s sans
aucune erreur. Les débits ne dépassent pas 9600 bits/s avec un vrai fax en
réception. Si la transmission risque de durer plus de quinze minutes, il
vaut mieux de toute façon se limiter à 9600 car le problème de buffer
commence à se manifester au cours de la seizième minute avec ma
configuration d'Ekiga, sans être aussi catastrophique qu'avec Linphone.
(constaté en local) J'ai réussi d'autres émissions mais j'ai des scrupules à
utiliser mon compte OVH sans autre utilité que celle de battre des records.
Pas réussi un seul envoi avec Linphone, la négociation entre terminaux
avorte immédiatement ou ne s'amorce même pas.
(En local et donc sans opérateur intermédiaire, avec Linphone aux deux
bouts, la transmission s'amorce et se poursuit sans problème pendant 20
minutes avec la valeur par défaut de audio_jitt_comp, quarante minutes en la
multipliant par deux, audio_adaptive_jitt_comp_enabled étant mis à zéro. Pas
moyen d'amorcer le dialogue entre fax avec Ekiga dans les mêmes conditions,
je ne comprends pas pourquoi.)
Quelle est alors ta configuration actuelle et comment tu fait pour
envoyer un fax ?
Je compte l'expliquer de façon détaillée un de ces jours sur ma page perso
Orange. Mes modems analogiques externes sont de marque Olitec et, côté
logiciel, efax et son script fax sont ce que j'ai trouvé de mieux pour la
réception, efax-gtk pour l'émission. Mes interfaces deux fils/quatre fils ne
comportent que deux résistances et un condensateur mais ne conviennent
qu'avec une carte son à sortie amplifiée comme mes CT4810.
On peut en parler en privé si tu veux, mon adresse de réponse est valide.
As-tu des messages correspondant à l'anomalie ?
La quelle ? J'aimerais notamment comprendre pourquoi Linphone, dont la
courbe de réponse est bien meilleure que celle d'Ekiga, ne me permet pas
d'amorcer l'envoi de fax via mon compte OVH, mais les messages délivrés par
efax et linphone ne seraient utiles qu'à quelqu'un connaissant les
protocoles de fax et SIP, pas spécialement en lien avec linux.
Tu peux donc envoyer de fax avec ta configuration actuelle et sauf
dans certains cas ça marche ?
Oui, grâce à Ekiga et mon compte OVH, mon premier succès fut l'envoi vers ma
ligne France-Telecom d'un fax de 36 pages au débit de 9600 bits/s, dont 6
avec une seule erreur et une avec 4 erreurs. Plus tard, avec une interface
deux fils/quatre fils plus simple, 15 pages au débit 14400 bits/s sans
aucune erreur. Les débits ne dépassent pas 9600 bits/s avec un vrai fax en
réception. Si la transmission risque de durer plus de quinze minutes, il
vaut mieux de toute façon se limiter à 9600 car le problème de buffer
commence à se manifester au cours de la seizième minute avec ma
configuration d'Ekiga, sans être aussi catastrophique qu'avec Linphone.
(constaté en local) J'ai réussi d'autres émissions mais j'ai des scrupules à
utiliser mon compte OVH sans autre utilité que celle de battre des records.
Pas réussi un seul envoi avec Linphone, la négociation entre terminaux
avorte immédiatement ou ne s'amorce même pas.
(En local et donc sans opérateur intermédiaire, avec Linphone aux deux
bouts, la transmission s'amorce et se poursuit sans problème pendant 20
minutes avec la valeur par défaut de audio_jitt_comp, quarante minutes en la
multipliant par deux, audio_adaptive_jitt_comp_enabled étant mis à zéro. Pas
moyen d'amorcer le dialogue entre fax avec Ekiga dans les mêmes conditions,
je ne comprends pas pourquoi.)
Quelle est alors ta configuration actuelle et comment tu fait pour
envoyer un fax ?
Je compte l'expliquer de façon détaillée un de ces jours sur ma page perso
Orange. Mes modems analogiques externes sont de marque Olitec et, côté
logiciel, efax et son script fax sont ce que j'ai trouvé de mieux pour la
réception, efax-gtk pour l'émission. Mes interfaces deux fils/quatre fils ne
comportent que deux résistances et un condensateur mais ne conviennent
qu'avec une carte son à sortie amplifiée comme mes CT4810.
On peut en parler en privé si tu veux, mon adresse de réponse est valide.
As-tu des messages correspondant à l'anomalie ?
La quelle ? J'aimerais notamment comprendre pourquoi Linphone, dont la
courbe de réponse est bien meilleure que celle d'Ekiga, ne me permet pas
d'amorcer l'envoi de fax via mon compte OVH, mais les messages délivrés par
efax et linphone ne seraient utiles qu'à quelqu'un connaissant les
protocoles de fax et SIP, pas spécialement en lien avec linux.
Le 13/05/2013 10:32, *dyrmak* a écrit fort à propos :<news:kmfgn8$q7v$
Je ne sais pas exploiter ce lien avec Seamonkey.
Il y a eu comme un couac de ma part, l'article en question
concerne l'echo qui se produit localement par injection
de la voix du correspondant dans le microphone virtuel du
pulse-audio en mode moniteur.
Ah, tiens, c'est peut-être pour ça qu'un bruit blanc transmis en utilisant
cette fonction monitor (ainsi que snd_aloop) se retrouve fortement coloré à
l'arrivée ? Je devrais même dire « bariolé » parce que le spectre a le
profil de montagnes russes. Je m'apprêtais justement à refaire des tests
pour vérifier que je n'avais pas fait un cauchemar.
Décidément, pour faire des mesures significatives, il vaut mieux injecter le
signal par l'entrée ligne de la carte son. (Ou utiliser les commandes
souncard use files et play de linphonec, mais alors on ne teste pas toute la
chaîne d'émission.)
Le 13/05/2013 10:32, *dyrmak* a écrit fort à propos :
<news:kmfgn8$q7v$1@speranza.aioe.org>
Je ne sais pas exploiter ce lien avec Seamonkey.
Il y a eu comme un couac de ma part, l'article en question
concerne l'echo qui se produit localement par injection
de la voix du correspondant dans le microphone virtuel du
pulse-audio en mode moniteur.
Ah, tiens, c'est peut-être pour ça qu'un bruit blanc transmis en utilisant
cette fonction monitor (ainsi que snd_aloop) se retrouve fortement coloré à
l'arrivée ? Je devrais même dire « bariolé » parce que le spectre a le
profil de montagnes russes. Je m'apprêtais justement à refaire des tests
pour vérifier que je n'avais pas fait un cauchemar.
Décidément, pour faire des mesures significatives, il vaut mieux injecter le
signal par l'entrée ligne de la carte son. (Ou utiliser les commandes
souncard use files et play de linphonec, mais alors on ne teste pas toute la
chaîne d'émission.)
Le 13/05/2013 10:32, *dyrmak* a écrit fort à propos :<news:kmfgn8$q7v$
Je ne sais pas exploiter ce lien avec Seamonkey.
Il y a eu comme un couac de ma part, l'article en question
concerne l'echo qui se produit localement par injection
de la voix du correspondant dans le microphone virtuel du
pulse-audio en mode moniteur.
Ah, tiens, c'est peut-être pour ça qu'un bruit blanc transmis en utilisant
cette fonction monitor (ainsi que snd_aloop) se retrouve fortement coloré à
l'arrivée ? Je devrais même dire « bariolé » parce que le spectre a le
profil de montagnes russes. Je m'apprêtais justement à refaire des tests
pour vérifier que je n'avais pas fait un cauchemar.
Décidément, pour faire des mesures significatives, il vaut mieux injecter le
signal par l'entrée ligne de la carte son. (Ou utiliser les commandes
souncard use files et play de linphonec, mais alors on ne teste pas toute la
chaîne d'émission.)
Si au moins je pourrais conseiller quelque chose, m'est avis que tu
devrais injecter le bruit blanc sur l'entrée ligne et t'y tenir sans
autre considération que d'envoyer le signal à capter à l'autre bout et
même supprimer le mode monitor de pulse-audio c'est-à-dire supprimer
le microphone virtuel.
Si au moins je pourrais conseiller quelque chose, m'est avis que tu
devrais injecter le bruit blanc sur l'entrée ligne et t'y tenir sans
autre considération que d'envoyer le signal à capter à l'autre bout et
même supprimer le mode monitor de pulse-audio c'est-à-dire supprimer
le microphone virtuel.
Si au moins je pourrais conseiller quelque chose, m'est avis que tu
devrais injecter le bruit blanc sur l'entrée ligne et t'y tenir sans
autre considération que d'envoyer le signal à capter à l'autre bout et
même supprimer le mode monitor de pulse-audio c'est-à-dire supprimer
le microphone virtuel.
<news:kmfgn8$q7v$
Je ne sais pas exploiter ce lien avec Seamonkey.
Ah bon ? C'est un URI pur et dur pourtant.Il y a eu comme un couac de ma part, l'article en question
concerne l'echo qui se produit localement par injection
de la voix du correspondant dans le microphone virtuel du
pulse-audio en mode moniteur.
<news:kmfgn8$q7v$1@speranza.aioe.org>
Je ne sais pas exploiter ce lien avec Seamonkey.
Ah bon ? C'est un URI pur et dur pourtant.
Il y a eu comme un couac de ma part, l'article en question
concerne l'echo qui se produit localement par injection
de la voix du correspondant dans le microphone virtuel du
pulse-audio en mode moniteur.
<news:kmfgn8$q7v$
Je ne sais pas exploiter ce lien avec Seamonkey.
Ah bon ? C'est un URI pur et dur pourtant.Il y a eu comme un couac de ma part, l'article en question
concerne l'echo qui se produit localement par injection
de la voix du correspondant dans le microphone virtuel du
pulse-audio en mode moniteur.
Un bon point pour ce qui concerne l'envoi en tant que tel, puisqu'il a
fallu concevoir la câblage local entre le modem et le soft-phone.
Par contre, tous les problèmes relatifs aux délais de transmission
ou de pertes de paquet ne vont pas dans le sens d'une fidèle
réproduction du signal à la sortie
sans parler du niveau ou du volume
sonore acceptable pour un modem classique.
(En local et donc sans opérateur intermédiaire, avec Linphone aux deux
bouts, la transmission s'amorce et se poursuit sans problème pendant 20
minutes avec la valeur par défaut de audio_jitt_comp, quarante minutes en la
multipliant par deux, audio_adaptive_jitt_comp_enabled étant mis à zéro.
Tu amorces la transmission mais est-ce que tu reçois le fax ?
Là tu parles de schéma électronique et forcément ça a un coté "recherche
& développement" qui n'est pas à la portée de tous, je te laisse le soin
de le détailler.
Un bon point pour ce qui concerne l'envoi en tant que tel, puisqu'il a
fallu concevoir la câblage local entre le modem et le soft-phone.
Par contre, tous les problèmes relatifs aux délais de transmission
ou de pertes de paquet ne vont pas dans le sens d'une fidèle
réproduction du signal à la sortie
sans parler du niveau ou du volume
sonore acceptable pour un modem classique.
(En local et donc sans opérateur intermédiaire, avec Linphone aux deux
bouts, la transmission s'amorce et se poursuit sans problème pendant 20
minutes avec la valeur par défaut de audio_jitt_comp, quarante minutes en la
multipliant par deux, audio_adaptive_jitt_comp_enabled étant mis à zéro.
Tu amorces la transmission mais est-ce que tu reçois le fax ?
Là tu parles de schéma électronique et forcément ça a un coté "recherche
& développement" qui n'est pas à la portée de tous, je te laisse le soin
de le détailler.
Un bon point pour ce qui concerne l'envoi en tant que tel, puisqu'il a
fallu concevoir la câblage local entre le modem et le soft-phone.
Par contre, tous les problèmes relatifs aux délais de transmission
ou de pertes de paquet ne vont pas dans le sens d'une fidèle
réproduction du signal à la sortie
sans parler du niveau ou du volume
sonore acceptable pour un modem classique.
(En local et donc sans opérateur intermédiaire, avec Linphone aux deux
bouts, la transmission s'amorce et se poursuit sans problème pendant 20
minutes avec la valeur par défaut de audio_jitt_comp, quarante minutes en la
multipliant par deux, audio_adaptive_jitt_comp_enabled étant mis à zéro.
Tu amorces la transmission mais est-ce que tu reçois le fax ?
Là tu parles de schéma électronique et forcément ça a un coté "recherche
& développement" qui n'est pas à la portée de tous, je te laisse le soin
de le détailler.
