Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

alsaloop et libsamplerate

37 réponses
Avatar
Geo Cherchetout
Bonjour,

Je souhaiterais utiliser la commande alsaloop pour renvoyer la sortie d'une
carte son vers l'entrée d'une autre carte son, mais :

$ alsaloop -P hw:0,0 -C hw:1,0 -t 50000
No libsamplerate support.

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 ?

10 réponses

1 2 3 4
Avatar
dyrmak
En 11 lignes Geo Cherchetout a écrit
dans news:kmifgu$2bnn$
le vendredi, 10 mai 2013 à 11:43:58 :

Le 10/05/2013 11:19, *Nicolas George* a écrit fort à propos :

Ça marche vraiment ? J'aurais pensé que les softphones utilisaient des
codecs optimisés pour la voix qui ruinaient complètement les signaux
numériques encodés.



C'est tout le contraire : À la différence des box qui nous relient à
l'internet, les softphones mettent à notre disposition des codecs comme
G.711-a qui sont parfaits pour cette utilisation. :-)




Et en quoi ils sont parfaits pour cette utilisation ?
Est-ce qu'on les utilise déjà pour l'envoi des télécopies ?

dyrmak
--
A la hora de la ahora
++++ --- ++++
Linux operating system
++++ --- ++++

--- news://freenews.netfront.net/ - complaints: ---
Avatar
Geo Cherchetout
Le 10/05/2013 12:06, *Nicolas George* a écrit fort à propos :

Ah, d'accord. Mais alors... Je ne suis pas sûr d'avoir bien compris la
disposition : tu as un softphone d'un côté et un softphone de l'autre, et tu
échanges du G.771-a entre les deux pour faire passer des faxes ?



C'est en effet la configuration que j'utilise pour des essais mais ça n'a
pas vraiment d'utilité pratique. Ce qui peut intéresser plus de monde, c'est
l'envoi ou la réception via un compte ouvert chez un opérateur de VoIP,
toujours en utilisant un softphone et un modem analogique et un petit
accessoire assurant l'interface deux fils/quatre fils.
On peut plus simplement utiliser un ATA (adaptateur pour téléphone
analogique) mais c'est moins amusant.

C'est quoi l'intérêt par rapport à envoyer directement le fichier ?



Il faudrait poser la question aux entreprises et administrations qui
communiquent par ce moyen...

Ou bien il y a un des côtés que tu ne contrôles pas ?



Un côté pas du tout, et l'autre difficilement. ;-)
Avatar
Geo Cherchetout
Le 10/05/2013 12:19, *dyrmak* a écrit fort à propos :

C'est tout le contraire : À la différence des box qui nous relient à
l'internet, les softphones mettent à notre disposition des codecs comme
G.711-a qui sont parfaits pour cette utilisation. :-)




Et en quoi ils sont parfaits pour cette utilisation ?
Est-ce qu'on les utilise déjà pour l'envoi des télécopies ?



G.711-a (aussi nommé PCMA ou a-law) est, depuis les années 70, le codec «
naturel » du rtc (réseau téléphonique commuté) en Europe, lequel transmet
aussi bien le fax que la parole. Outre-Atlantique c'est plutôt G.711-u,
alias PCMU, alias µ-law, qui me donne exactement les mêmes bons résultats en
local. Si tu es en France et que tu envoies un fax sur une ligne
France-Telecom, c'est donc obligatoirement G.711-a qui est utilisé.

Les box fournies par les FAI ne donnent généralement pas le choix du codec
et utilisent le plus souvent pour la téléphonie liée à l'abonnement internet
des codecs moins gourmands en bande passante mais inadaptés à la
transmission de télécopies. Personnellement, j'ai un modem qui me permet de
choisir mon codec et un compte VoIP chez OVH mais, pour une raison que je
n'ai pas encore identifiée, j'ai beaucoup de mal à envoyer de temps à autre
un petit fax d'une seule page. C'est ce qui m'a motivé à rechercher d'autres
moyens...
Avatar
dyrmak
En 26 lignes Geo Cherchetout a écrit
dans news:kminnl$2slb$
le vendredi, 10 mai 2013 à 14:04:04 :

Le 10/05/2013 12:19, *dyrmak* a écrit fort à propos :

C'est tout le contraire : À la différence des box qui nous relient à
l'internet, les softphones mettent à notre disposition des codecs comme
G.711-a qui sont parfaits pour cette utilisation. :-)




Et en quoi ils sont parfaits pour cette utilisation ?
Est-ce qu'on les utilise déjà pour l'envoi des télécopies ?



G.711-a (aussi nommé PCMA ou a-law) est, depuis les années 70, le codec «
naturel » du rtc (réseau téléphonique commuté) en Europe, lequel transmet
aussi bien le fax que la parole. Outre-Atlantique c'est plutôt G.711-u,
alias PCMU, alias µ-law, qui me donne exactement les mêmes bons résultats en
local. Si tu es en France et que tu envoies un fax sur une ligne
France-Telecom, c'est donc obligatoirement G.711-a qui est utilisé.

Les box fournies par les FAI ne donnent généralement pas le choix du codec
et utilisent le plus souvent pour la téléphonie liée à l'abonnement internet
des codecs moins gourmands en bande passante mais inadaptés à la
transmission de télécopies. Personnellement, j'ai un modem qui me permet de
choisir mon codec et un compte VoIP chez OVH mais, pour une raison que je
n'ai pas encore identifiée, j'ai beaucoup de mal à envoyer de temps à autre
un petit fax d'une seule page. C'est ce qui m'a motivé à rechercher d'autres
moyens...




Les codecs PCMA et PCMU de la liste de codecs d'Ekiga sont bien
ceux-là ?

Tu peux donc envoyer de fax avec ta configuration actuelle et sauf
dans certains cas ça marche ?

Quelle est alors ta configuration actuelle et comment tu fait pour
envoyer un fax ? As-tu des messages correspondant à l'anomalie ?

dyrmak
--
Es la hora
++++ --- ++++
Linux operating system
++++ --- ++++

--- news://freenews.netfront.net/ - complaints: ---
Avatar
Geo Cherchetout
Le 10/05/2013 11:58, *dyrmak* a écrit fort à propos :

Pour ce qui est des télécopies, j'en suis sceptique plus ou moins, du
fait déjà que je ne connais pas le protocole précis de fax, mais
le peu que j'en sais c'est que le bruit qui circule pendant une
communication de fax correspond à 98% ( je dis 98% mais
c'est énorme sans que cela soit le pourcentage exact ) à des contrôles
de transmission et seulement un chiure de mouche représente les données
réelles à transmettre.



Ce qu'on peut déjà dire, c'est qu'on utilise, dans le cas le plus favorable
de transmission sur le rtc, 64 kilobits/s pour un flux utile de 14
kilobits/s, dû à la faible efficacité du procédé de modulation et non aux
contrôles de transmission. Mais je connais très peu de choses sur les
protocoles de fax, il y a forcément d'autres pertes dont j'ignore
l'importance relative.

Le protocole T.38 est réputé moins gaspilleur de bande passante tout en
résolvant les problèmes de transmission « over IP ». J'essaierais volontiers
t38modem si je trouvais quelqu'un pour m'accompagner dans cette aventure qui
n'a rien à voir avec mes bidouilles actuelles.
http://www.voip-info.org/wiki/view/T38modem
Avatar
Geo Cherchetout
Le 10/05/2013 14:23, *dyrmak* a écrit fort à propos :

Les codecs PCMA et PCMU de la liste de codecs d'Ekiga sont bien
ceux-là ?



Oui, sous réserve de la qualité de l'implémentation, dont je ne peux pas juger.

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. Quand j'aurai
rédigé mon compte-rendu, j'envisage d'en parler aux développeurs de Linphone...
Avatar
Geo Cherchetout
Le 10/05/2013 12:08, *dyrmak* a écrit fort à propos :

Tiens, en compilant Ekiga il y a une
option fax, mais je ne sais pas à quoi cela correspond, je n'ai jamais
compilé cette option, il faudra suivre avec attention ces
développement car effectivement ils m'intéressent.



Ça c'est intéressant ! Je n'avais pas remarqué cette option en compilant la
version 3.9.90 et je n'en vois aucune mention dans le SPECS du rpm de la
4.0.1 façon Mageia. Mais c'est peut-être dans Opal ou dans ptlib ?

j'ai par ailleurs essayé Linphone ( compilé ce matin en faisant
git pull ). Il fonctionne pareil en echo avec pulse-audio mais
le son et encore plus mauvais ( ou moins bon ) qu'avec Ekiga,
mais ce n'est pas un résultat définifif, on sais jamais si en
rebootant la machine le résultat ne serait pas meilleur.



Tu veux dire lors de tests avec un robot écho comme celui d'ekiga.net ? Avec
un casque, j'ai toujours un très bon son aussi bien avec Ekiga qu'avec
Linphone en utilisant les codecs PCMA et PCMU et la vidéo étant désactivée.
Les mesures m'ont révélé une moins bonne réponse dans les aiguës avec Ekiga
mais à l'oreille cela ne se remarque pas, ça donne tout juste une tonalité
un peu plus « chaude » quand on le sait. Tu peux comparer les réponses en
fréquence d'Ekiga : http://pix.toile-libre.org/?img67698438.png et de
Linphone : http://pix.toile-libre.org/?img67698567.png
Ne pas tenir compte des raies en deçà de 1000 Hz, l'entrée microphone était
restée active alors que le bruit blanc pour la mesure était injecté par
l'entrée ligne.
(Dans les deux cas, les fonctions d'annulation et de suppression d'écho sont
désactivées.)
Avatar
dyrmak
En 31 lignes Geo Cherchetout a écrit
dans news:kmjqc7$1v13$
le vendredi, 10 mai 2013 à 23:55:19 :

Le 10/05/2013 12:08, *dyrmak* a écrit fort à propos :

Tiens, en compilant Ekiga il y a une
option fax, mais je ne sais pas à quoi cela correspond, je n'ai jamais
compilé cette option, il faudra suivre avec attention ces
développement car effectivement ils m'intéressent.



Ça c'est intéressant ! Je n'avais pas remarqué cette option en compilant la
version 3.9.90 et je n'en vois aucune mention dans le SPECS du rpm de la
4.0.1 façon Mageia. Mais c'est peut-être dans Opal ou dans ptlib ?




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.

Je crois avoir lu qu'officiellement le fax n'est pas supporté par
Ekiga cependant.

j'ai par ailleurs essayé Linphone ( compilé ce matin en faisant
git pull ). Il fonctionne pareil en echo avec pulse-audio mais
le son et encore plus mauvais ( ou moins bon ) qu'avec Ekiga,
mais ce n'est pas un résultat définifif, on sais jamais si en
rebootant la machine le résultat ne serait pas meilleur.



Tu veux dire lors de tests avec un robot écho comme celui d'ekiga.net ?



No, heureusement d'ailleurs, les autotest ont toujours bien fonctionné,
Linphone passe le test de Ekiga.net sans problème, mais je dois
dire que mes évaluations sont pifométriques et la qualité des spectres
en fréquence ne sont jamais considérées.

Je disais que ça ne marchait pas bien dans le cadre d'évaluation
signalé ici, ajouté en cours de route de ce fil tout à fait en local:

<news:

Avec un casque, j'ai toujours un très bon son aussi bien avec Ekiga qu'avec
Linphone en utilisant les codecs PCMA et PCMU et la vidéo étant désactivée.
Les mesures m'ont révélé une moins bonne réponse dans les aiguës avec Ekiga
mais à l'oreille cela ne se remarque pas, ça donne tout juste une tonalité
un peu plus « chaude » quand on le sait. Tu peux comparer les réponses en
fréquence d'Ekiga : http://pix.toile-libre.org/?img67698438.png et de
Linphone : http://pix.toile-libre.org/?img67698567.png
Ne pas tenir compte des raies en deçà de 1000 Hz, l'entrée microphone était
restée active alors que le bruit blanc pour la mesure était injecté par
l'entrée ligne.
(Dans les deux cas, les fonctions d'annulation et de suppression d'écho sont
désactivées.)




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.

dyrmak
--
¿ Cómo era aquello del rayo verde ?
++++ --- ++++
Linux operating system
++++ --- ++++

--- news://freenews.netfront.net/ - complaints: ---
Avatar
dyrmak
En 92 lignes dyrmak a écrit
dans news:
le lundi, 13 mai 2013 à 08:45:36 :

<news:



<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.

dyrmak
--
Que dijeron apariencias engañan
++++ --- ++++
Linux operating system
++++ --- ++++
Avatar
dyrmak
En 23 lignes Geo Cherchetout a écrit
dans news:kmipm3$30b4$
le vendredi, 10 mai 2013 à 14:37:23 :


Le protocole T.38 est réputé moins gaspilleur de bande passante tout en
résolvant les problèmes de transmission « over IP ». J'essaierais volontiers
t38modem si je trouvais quelqu'un pour m'accompagner dans cette aventure qui
n'a rien à voir avec mes bidouilles actuelles.
http://www.voip-info.org/wiki/view/T38modem




J'ai lu et ça semble effectivement faisable, ce qui semble encourageant
c'est le fait que T38 tient compte de la notion de stabilité de flux
entre deux machines fax. Il accélère le flux si celui-ci ralentit
ou bien ralentit le flux si celui-ci accèlère et ceci englobe les problèmes
de "guigue d'horloge" de tous les PCM et de tous les routeurs en chemin
( je dis bravo! ) en terme de délai et de perte de paquets. Maintenant,
je ne vois pas très bien comment il trouve le flux idéal à respecter
pour la communication, mais c'est sûrement un détail ?

dyrmak
--
Noche serena
++++ --- ++++
Linux operating system
++++ --- ++++
1 2 3 4