Problème de restitution de flux audio

Le 19/04/2013 12:29, *dyrmak* a écrit fort à propos :

J'ai enfin réussi à le configurer de façon à pouvoir établir une
communication video-phonique locale, je ne dirais pas que c'est plus
simple qu'Ekiga, en particulier, une communication linphone < ---> linphone
ne dit pas clairement quels codecs sont utilisés pendant l'échange,
la communication Ekiga < ---> Linphone est plus explicite puisque
lors de l'échange Ekiga affiche les codecs utilisés par défaut.

La solution que j'emploie pour mes essais est de n'activer qu'un seul et
même codec aux deux extrémités. :-) Mais on peut faire plus subtil.
Un des avantages de Linphone est que tous les paramètres indispensables sont
accessibles depuis son interface graphique. Mais j'ai découvert récemment
qu'il en existe quelques autres qu'on peut aisément inclure dans
~/.linphonerc :
https://www.linphone.org/eng/documentation/dev/tuning-linphone.html

Ekiga < ----- > linphone fonctionne ( toutes mes versions toto-compilées
d'ekiga 3.2.7 3.3.2 et 4.0.0 )
avec les codecs speex/theora ou avec speex/MP4V-ES.
Mes ekiga totocompilés ont justement ce MP4V-ES oufff.

Par contre, des difficultés notoires avec une communication
linphone <----> linphone; j'ai des microcoupures de flux sonore
aléatoires mais persistantes, j'ai forcé les vbr=off des
codecs speex ce qui semble améliorer la communication mais
rien de vraiment certain à ce sujet.

Merci pour le tuyau. Je n'utilise que PCMA et PCMU mais ça peut toujours
servir un jour ou l'autre.

Il faudrait que je compile la version 3.5.2 de linphone.
Je vais m'y pencher dès que possible.

Je m'apprêtais justement à révéler la seule version qui, installée aux deux
bouts, résoud parfaitement ce grave problème de trous. Cette version est la
3.5.99.0 (Version git) : https://www.linphone.org/eng/download/git.html
Je te la recommande vivement.

L'utilisation de pulseaudio me semble très utile, en fait, c'est très
facile une fois qu'on a compris que pulse audio anticipe ou s'adapte
aux actions de l'utilisateur, par exemple si on écoute avec un casque, le
fait de débrancher le casque bascule le flux directement sur le
hauts-parleurs, ou l'inverse, l'utilisation d'un casque coupe
automatiquement les hauts-parleurs.

Tu penses que c'est pulseaudio qui fait la bascule ? N'est-ce pas tout
simplement un contact électrique dans la prise jack comme sur les postes à
transistors ? Pulseaudio est en sursis sur mon netbook mais, partout
ailleurs, j'ai été conduit à le désactiver parce qu'il y a toujours quelque
chose qui ne marche pas. Je n'ai pas compris ce qu'apporte cette
complication supplémentaire...
(Mes cartes son, auxquelles je tiens beaucoup, n'ont qu'une sortie, mais une
sortie amplifiée à laquelle je peux raccorder directement des enceintes
passives.)

Deux outils importants pour Ekiga et pulseaudio

gconf-editor

Après des années de farfouillages laborieux dans les fichier xml, j'ai
découvert presque par hasard ce très utile gconf-editor... qui plante
souvent plus vite que son ombre.

pavucontrol.

Oui oui mais moi je préfère alsamixer. :-)

En 68 lignes Geo Cherchetout a écrit
dans news:kkrb7g$1op8$1@obelix.gegeweb.org
le vendredi, 19 avril 2013 à 13:53:19 :

La solution que j'emploie pour mes essais est de n'activer qu'un seul et
même codec aux deux extrémités. :-) Mais on peut faire plus subtil.
Un des avantages de Linphone est que tous les paramètres indispensables sont
accessibles depuis son interface graphique. Mais j'ai découvert récemment
qu'il en existe quelques autres qu'on peut aisément inclure dans
~/.linphonerc :

J'ai voulu moi aussi choisir une configuration limitée de codecs, mais
vu le nombre d'essais qui ont échoué j'ai choisi de ne plus toucher à
ces codecs. En plus je ne cesse de revenir à une communication
Ekiga/Ekiga quand les autres semblent gripées ( ekiga/linphone qui
pour une raison ou autre perdaient la video ou linphone/linphone
dont le flux sonores sont infectés de microcoupures ). Dans un sens
ce très décevant de voir que d'une part tout roule et que de l'autre
il y a toujours un son qui cloche.

https://www.linphone.org/eng/documentation/dev/tuning-linphone.html

Je dois dire que je n'ai pas consulté la documentation. Pas encore mais
je vais sûrement le faire prochainement.

Merci pour le tuyau. Je n'utilise que PCMA et PCMU mais ça peut toujours
servir un jour ou l'autre.

Ce dont je me souviens et qui me semble gênant dans les versions
linphone 3.3.2 c'est qu'en modifiant les paramètres si on quitte
l'application, les paramètres reviennent toujours à la configuration
d'origine, ça m'a pas rendu optimiste à vrai dire.

Il faudrait que je compile la version 3.5.2 de linphone.
Je vais m'y pencher dès que possible.

Je m'apprêtais justement à révéler la seule version qui, installée aux deux
bouts, résoud parfaitement ce grave problème de trous. Cette version est la
3.5.99.0 (Version git) : https://www.linphone.org/eng/download/git.html
Je te la recommande vivement.

Ah! ok... Est-ce qu'on peut dire que cette version a résolu tous les
problèmes rencontrés jusqu'en ce moment ?

Je vais télécharger donc cette version et limiter mes essais avec
celle-ci.

L'utilisation de pulseaudio me semble très utile, en fait, c'est très
facile une fois qu'on a compris que pulse audio anticipe ou s'adapte
aux actions de l'utilisateur, par exemple si on écoute avec un casque, le
fait de débrancher le casque bascule le flux directement sur le
hauts-parleurs, ou l'inverse, l'utilisation d'un casque coupe
automatiquement les hauts-parleurs.

Tu penses que c'est pulseaudio qui fait la bascule ? N'est-ce pas tout
simplement un contact électrique dans la prise jack comme sur les postes à
transistors ? Pulseaudio est en sursis sur mon netbook mais, partout
ailleurs, j'ai été conduit à le désactiver parce qu'il y a toujours quelque
chose qui ne marche pas. Je n'ai pas compris ce qu'apporte cette
complication supplémentaire...
(Mes cartes son, auxquelles je tiens beaucoup, n'ont qu'une sortie, mais une
sortie amplifiée à laquelle je peux raccorder directement des enceintes
passives.)

Deux outils importants pour Ekiga et pulseaudio

gconf-editor

Après des années de farfouillages laborieux dans les fichier xml, j'ai
découvert presque par hasard ce très utile gconf-editor... qui plante
souvent plus vite que son ombre.

pavucontrol.

Oui oui mais moi je préfère alsamixer. :-)

Je le disais pour les cas où ! Personnellement il y a bien longtemps que
je n'utilise que pavucontrol et pulseaudio. Et j'ai de la chance avec
gconf-editor, chez moi il n'a jamais planté.

Et c'est pas que j'aime pas alsamixer, je l'ai toujours et il m'arrive
de l'utiliser, mais avec recul je m'aperçois qu'il est bon pour
écouter les sources sonores, il me semble moins précis dès qu'on veut
non seulement les écouter mais aussi les enregistrer, de plus, plusieurs
sources sonores à des niveaux d'écoute différents se gèrent facilement
avec pavucontrol et c'est pas vraiment compliqué à utiliser.

dyrmak

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

Le 19/04/2013 14:44, *dyrmak* a écrit fort à propos :

Je m'apprêtais justement à révéler la seule version qui, installée aux deux
bouts, résoud parfaitement ce grave problème de trous. Cette version est la
3.5.99.0 (Version git) : https://www.linphone.org/eng/download/git.html
Je te la recommande vivement.

Ah! ok... Est-ce qu'on peut dire que cette version a résolu tous les
problèmes rencontrés jusqu'en ce moment ?

Rencontrés par Toto et Titi, oui, mais « parfaitement » n'est peut-être pas
le mot juste. Ce matin ils ont pu converser pendant presque deux heures sans
remarquer de trous mais nous allons vérifier en émettant une tonalité
continue et en l'enregistrant côté réception.
Linphone permet désormais l'enregistrement depuis son interface graphique,
mais je ne sais pas si ce qu'on enregistre est vraiment ce qu'on entend,
parce que ce n'est pas vrai avec linphonec.

Et c'est pas que j'aime pas alsamixer, je l'ai toujours et il m'arrive
de l'utiliser, mais avec recul je m'aperçois qu'il est bon pour
écouter les sources sonores, il me semble moins précis dès qu'on veut
non seulement les écouter mais aussi les enregistrer, de plus, plusieurs
sources sonores à des niveaux d'écoute différents se gèrent facilement
avec pavucontrol et c'est pas vraiment compliqué à utiliser.

Je dois reconnaître que je n'ai pas beaucoup insisté. J'apprendrai peut-être
plus facilement quand j'aurai trouvé un schéma synoptique intelligible de
mes cartes son et compris ce qu'on règle réellement avec les curseurs
d'alsamixer ou autre mixer... Cartes CT4810 avec ampli de puissance comme
celle du milieu ici : http://www.leboncoin.fr/informatique/416960677.htm?ca_s

En 32 lignes Geo Cherchetout a écrit
dans news:kkrgs5$242t$1@obelix.gegeweb.org
le vendredi, 19 avril 2013 à 15:29:41 :

Je m'apprêtais justement à révéler la seule version qui, installée aux deux
bouts, résoud parfaitement ce grave problème de trous. Cette version est la
3.5.99.0 (Version git) : https://www.linphone.org/eng/download/git.html
Je te la recommande vivement.

Ah! ok... Est-ce qu'on peut dire que cette version a résolu tous les
problèmes rencontrés jusqu'en ce moment ?

Rencontrés par Toto et Titi, oui, mais « parfaitement » n'est peut-être pas
le mot juste. Ce matin ils ont pu converser pendant presque deux heures sans
remarquer de trous mais nous allons vérifier en émettant une tonalité
continue et en l'enregistrant côté réception.
Linphone permet désormais l'enregistrement depuis son interface graphique,
mais je ne sais pas si ce qu'on enregistre est vraiment ce qu'on entend,
parce que ce n'est pas vrai avec linphonec.

Ça y est ! J'ai totocompilé la version git de linphone et fort
heureusement le flux sonore est bien meilleur. Mais
la compatibilité Ekiga/Linphone est cassée; Linphone plante
pendant l'appel et l'activation de Bumblebee ne lui plaît
pas alors que Ekiga 4 surfe sur optirun comme un beau
diable.

Pour le moment je suis dans l'impossibilité d'établir une
communication Linphone/Linphone version git aux deux
bouts, c'est dommage, la version git sur le netbook plante.
On devrait m'apporter un portable ACER 64 bits la semaine
prochaine, je vais préparer l'installation d'une Debian Wheezy
ou une Mint 13 si possible pour y compiler la version git qui
fonctionne sur mon ASUS 64bits.

Les versions Linphone 3.2.1 et 3.3.2 fonctionnent beaucoup mieux
quand ils communiquent avec la version git à l'autre bout. Ce n'est
pas aussi bien qu'avec Ekiga mais Linphone va incontestablement dans
la bonne direction.

Pour ce qui est des enregistrements, disons que le niveau sonore
du flux entrant est bien plus important que le niveau sonore du flux
sortant pendant la communication et après enregistrement on entend
les deux flux avec la même intensité, je ne sais pas comment ça
débrouille pour obtenir ce résultat mais c'est bien ce que je constate.
Je n'ai pas essayé linphonec mais j'imagine que le résultat devrait
être le même.

dyrmak

Le 22/04/2013 17:09, *dyrmak* a écrit fort à propos :

Ça y est ! J'ai totocompilé la version git de linphone et fort
heureusement le flux sonore est bien meilleur. Mais
la compatibilité Ekiga/Linphone est cassée

As tu activé au moins un codec audio commun sur les deux applis ? Pour de
premiers essais, il est prudent de ne pas activer la vidéo...

Pour ce qui est des enregistrements, disons que le niveau sonore
du flux entrant est bien plus important que le niveau sonore du flux
sortant pendant la communication

À quoi le vois tu ? Aux vu-mètres ?

En 15 lignes Geo Cherchetout a écrit
dans news:kl3qm8$17pq$1@obelix.gegeweb.org
le lundi, 22 avril 2013 à 19:06:15 :

As tu activé au moins un codec audio commun sur les deux applis ? Pour de
premiers essais, il est prudent de ne pas activer la vidéo...

Du fil a retordre.... En faisant un test ekiga.net ça me donne bien un
retour videophonique , j'avais un problème de configuration, mais ça
soulève justement le problème que je doive choisir "connexion internet"
pour faire une communication locale, bizarre non ?

Si je dis que je suis derrière pare-feu et que je signale un serveur
stun pour me situer derrière le pare-feu, je peux communiquer avec
l'extérieur, être joignable depuis l'extérieur, mais une communication
locale initiée ou reçue fait planter linphone ( c'est bien cette
configuration qui me faisait planter ) et il me semble que
toutes les versions ont le même problème, pas que la version git.

Si en ayant choisi "connexion internet" je coupe l'internet, une
communication locale peut être reçue ou initiée mais elle met un temps
certain à s'établir.... Ça ne devrait pas....

Il a d'autres bizarreries, à ce qu'il me semble, mais je ne suis pas
affirmatif compte tenu que je ne connaissais pas du tout linphone
que je découvre peu à peu....

Pour ce qui est des enregistrements, disons que le niveau sonore
du flux entrant est bien plus important que le niveau sonore du flux
sortant pendant la communication

À quoi le vois tu ? Aux vu-mètres ?

Pendant la communication on voit les deux vu-mètres qui l'indiquent,
si les flux sonores ont été bien calibrés à l'entrée de chaque
microphone ET que le système sonore n'est pas en mode karaoké, on peut
écouter le flux sonore du correspondant et pratiquement "rien d'autre",
si en ce moment là on enregistre la communication le fichier résultant
est bien la somme des deux flux et le niveau sonore des deux flux semblent
équivalents, appréciation pifométrique bien sûr !

dyrmak

Le 23/04/2013 15:48, *dyrmak* a écrit fort à propos :

Du fil a retordre.... En faisant un test ekiga.net ça me donne bien un
retour videophonique , j'avais un problème de configuration, mais ça
soulève justement le problème que je doive choisir "connexion internet"
pour faire une communication locale, bizarre non ?

Le libellé exact est « connexion directe à l'internet » et je crois que le
mot important est DIRECT, le mot internet pouvant avantageusement être
remplacé par réseau. J'ai trouvé ça bizarre aussi mais on s'habitue.

Si je dis que je suis derrière pare-feu et que je signale un serveur
stun pour me situer derrière le pare-feu, je peux communiquer avec
l'extérieur, être joignable depuis l'extérieur, mais une communication
locale initiée ou reçue fait planter linphone ( c'est bien cette
configuration qui me faisait planter ) et il me semble que
toutes les versions ont le même problème, pas que la version git.

Plantage ou pas, je constate comme toi qu'on ne peut établir de
communication locale avec cette configuration, et ceci était déjà vrai avec
la version 3.5.2 que j'utilisais encore récemment. Il faut choisir entre com
locale et com distante...

Si en ayant choisi "connexion internet" je coupe l'internet, une
communication locale peut être reçue ou initiée mais elle met un temps
certain à s'établir.... Ça ne devrait pas....

Si tu ouvres une fenêtre de débogage par le menu aide, tu constateras que
beaucoup de données s'échangent pendant la négociation. Pour gagner du
temps, tu as intérêt à activer le moins de codecs possible, à avoir peu de
contacts et peu de comptes SIP déclarés, etc.
Mais pourquoi couper l'internet ? As tu préalablement désactivé ton compte
chez ekiga.net, sip.linphone.org ou autre ? Et si tu relances Linphone ?

En 34 lignes Geo Cherchetout a écrit
dans news:kl69j9$ec8$1@obelix.gegeweb.org
le mardi, 23 avril 2013 à 17:32:57 :

Le libellé exact est « connexion directe à l'internet » et je crois que le
mot important est DIRECT, le mot internet pouvant avantageusement être
remplacé par réseau. J'ai trouvé ça bizarre aussi mais on s'habitue.

Finalement oui c'est logique s'il s'agît d'un ordinateur qui est
connecté directement à internet, il serait tout seul et il pourrait
certainement recevoir les appels sip:*@IP.
Les appels locaux sont considerés après tout comme des appels internet
puisque l'appel se fait sous la même forme, mais en indiquant une
adresse locale....

Avant j'avais une passerelle connectée directement à internet,
j'y aurais configuré Linphone en "connexion directe à l'internet"
et les autres ordinateurs sur le réseau local seraient configurés
en "connexion directe" ainsi que d'autres sous stun.... Et je aurais
eu la curiosité de vérifier que :

- La passerelle est accessible depuis l'extérieur par simple appel
à sip:*@IPinternetdelapasserelle
- La passerelle est accessible depuis le réseau local par les Linphones
configurés en "connexion directe à l'internet" par simple appel à
sip:*@IPlocaledelapasserelle
- Les appels entre les Linphones configurés sous stun sont possibles
au même titre que les appels entre les Linphones configurés sous
connexion directe à internet.

Si ces vérifications étaient inexactes ou incohérentes au régard
des configurations ce serait que j'aurais toujours pas compris
la logique exacte de ces configurations.

Mais pourquoi couper l'internet ? As tu préalablement désactivé ton compte
chez ekiga.net, sip.linphone.org ou autre ? Et si tu relances Linphone ?

Disons que sous Ekiga la configuration me demande si je suis en réseau local
et si je veux stun, ça lui suffit pour que tous les Ekiga sous stun soient
accessibles d'où que vienne l'appel. Alors si je coupe l'internet les appels
locaux Ekiga/Ekiga sont toujours possibles en faisant un appel de voisinage
ou en faisant comme sous Linphone sip:*@IPlocal....

Pourquoi couper internet ? Normalement on ne coupe pas l'internet, mais
supposons que la ligne ADSL ne fonctionne plus....J'espère au moins
que les outils Intranet continueraient de fonctionner, le courrier
électronique des machines locales devrait circuler et les appels
visio-phoniques Ekiga/Ekiga Linphone/Linphone ou encore
Ekiga/Linphone/Ekiga devrait faire de même,.... Depuis l'extérieur on
ne serait plus accessible, quelque soit le fournisseur sip.

En ce moment je ne peux pas couper l'internet pour vérifier si Linphone
reçoit des appels locaux, mais si ça ne marchait pas ce serait (amha)
un bug.

dyrmak