Toto et Titi ont leurs ordinateurs connectés sur le même réseau local et
initient une conversation en mode audio seul par l'intermédiaire de
Linphone. (Version 3.5.2 fournie par Mageia 2, pour excuser le léger HS
éventuel). Au bout d'un temps de l'ordre de 8 à 10 minutes environ, la voix
de Toto devient intermittente dans le casque de Titi, alors que celle de
Titi est toujours bien reçue par Toto.
Nous avons vérifié de deux façons que le flux audio reçu par l'ordinateur de
Titi ne comporte pas de trous : D'une part en en faisant une capture avec
wireshark et d'autre part en utilisant l'option enregistrement en .wav que
permet linphonec. (Linphone sans interface graphique.)
Nous avons également vérifié que la carte son et le casque de Titi lisent
sans faillir des chansons pendant des heures ou un morceau de bruit blanc
durant 30 minutes, ou restituent aussi bien les signaux appliqués à son
entrée ligne.
Dans l'autre sens tout va bien, merci.
Que pouvons nous en déduire ? Y a-t-il une partie de la carte son qui a
échappé à ces vérifications et qui pourrait être en cause ? Que pouvons nous
essayer d'autre ?
Le noyau Linux est le même des deux côtés : Linux 3.4.34-desktop-1.mga2
Geo Cherchetout , dans le message <kkgui6$26hd$, a écrit :
En fait c'est plus progressif comme vient de le révéler un nouvel essai prolongé : Au cours de la sixième minute, des petits trous commencent à apparaître dans le son entendu par Titi, à peine perceptibles, puis des trous progressivement de plus en plus longs jusqu'à l'installation d'un silence complet vers la fin de la douzième minute.
Regarde dans le source de linphone si par hasard ils n'auraient pas activé la fonctionnalité d'ALSA qui permet d'éviter les buffer underruns en les remplaçant par du silence. Je ne me rappelle pas par coeur comment elle s'appelle, mais c'est trouvable dans la doc d'ALSA.
Geo Cherchetout , dans le message <kkgui6$26hd$1@obelix.gegeweb.org>, a
écrit :
En fait c'est plus progressif comme vient de le révéler un nouvel essai
prolongé : Au cours de la sixième minute, des petits trous commencent à
apparaître dans le son entendu par Titi, à peine perceptibles, puis des
trous progressivement de plus en plus longs jusqu'à l'installation d'un
silence complet vers la fin de la douzième minute.
Regarde dans le source de linphone si par hasard ils n'auraient pas activé
la fonctionnalité d'ALSA qui permet d'éviter les buffer underruns en les
remplaçant par du silence. Je ne me rappelle pas par coeur comment elle
s'appelle, mais c'est trouvable dans la doc d'ALSA.
Geo Cherchetout , dans le message <kkgui6$26hd$, a écrit :
En fait c'est plus progressif comme vient de le révéler un nouvel essai prolongé : Au cours de la sixième minute, des petits trous commencent à apparaître dans le son entendu par Titi, à peine perceptibles, puis des trous progressivement de plus en plus longs jusqu'à l'installation d'un silence complet vers la fin de la douzième minute.
Regarde dans le source de linphone si par hasard ils n'auraient pas activé la fonctionnalité d'ALSA qui permet d'éviter les buffer underruns en les remplaçant par du silence. Je ne me rappelle pas par coeur comment elle s'appelle, mais c'est trouvable dans la doc d'ALSA.
Geo Cherchetout
Le 15/04/2013 16:40, *Nicolas George* a écrit fort à propos :
Regarde dans le source de linphone si par hasard ils n'auraient pas activé la fonctionnalité d'ALSA qui permet d'éviter les buffer underruns en les remplaçant par du silence. Je ne me rappelle pas par coeur comment elle s'appelle, mais c'est trouvable dans la doc d'ALSA.
Je crois que nous sommes sur la bonne voie parce que, si Titi (celui qui écoute) choisit le pilote oss et le périphérique /dev/dsp le défaut signalé ne se manifeste plus.
Malheureusement, c'est alors un grésillement permanent qui se superpose au signal utile, d'autant plus audible que l'amplitude de celui-ci est forte. De plus, après une demi-heure environ, la session de linphone se ferme chez Titi sur erreur de segmentation sans que Toto (le parleur) s'en aperçoive, la conversation semblant pour lui se poursuivre normalement.
J'ai téléchargé les sources de Linphone v.3.5.2 et trouvé dans alsa.c des modifications à essayer. (C'est l'auteur du code qui les propose en commentaires aux lignes 43 à 51.) Penses tu que ce soit une bonne piste ? La compilation n'étant pas mon fort, j'aimerais avant de l'entreprendre mettre un maximum de chances de mon côté...
Le 15/04/2013 16:40, *Nicolas George* a écrit fort à propos :
Regarde dans le source de linphone si par hasard ils n'auraient pas activé
la fonctionnalité d'ALSA qui permet d'éviter les buffer underruns en les
remplaçant par du silence. Je ne me rappelle pas par coeur comment elle
s'appelle, mais c'est trouvable dans la doc d'ALSA.
Je crois que nous sommes sur la bonne voie parce que, si Titi (celui qui
écoute) choisit le pilote oss et le périphérique /dev/dsp le défaut signalé
ne se manifeste plus.
Malheureusement, c'est alors un grésillement permanent qui se superpose au
signal utile, d'autant plus audible que l'amplitude de celui-ci est forte.
De plus, après une demi-heure environ, la session de linphone se ferme chez
Titi sur erreur de segmentation sans que Toto (le parleur) s'en aperçoive,
la conversation semblant pour lui se poursuivre normalement.
J'ai téléchargé les sources de Linphone v.3.5.2 et trouvé dans alsa.c des
modifications à essayer. (C'est l'auteur du code qui les propose en
commentaires aux lignes 43 à 51.) Penses tu que ce soit une bonne piste ? La
compilation n'étant pas mon fort, j'aimerais avant de l'entreprendre mettre
un maximum de chances de mon côté...
Le 15/04/2013 16:40, *Nicolas George* a écrit fort à propos :
Regarde dans le source de linphone si par hasard ils n'auraient pas activé la fonctionnalité d'ALSA qui permet d'éviter les buffer underruns en les remplaçant par du silence. Je ne me rappelle pas par coeur comment elle s'appelle, mais c'est trouvable dans la doc d'ALSA.
Je crois que nous sommes sur la bonne voie parce que, si Titi (celui qui écoute) choisit le pilote oss et le périphérique /dev/dsp le défaut signalé ne se manifeste plus.
Malheureusement, c'est alors un grésillement permanent qui se superpose au signal utile, d'autant plus audible que l'amplitude de celui-ci est forte. De plus, après une demi-heure environ, la session de linphone se ferme chez Titi sur erreur de segmentation sans que Toto (le parleur) s'en aperçoive, la conversation semblant pour lui se poursuivre normalement.
J'ai téléchargé les sources de Linphone v.3.5.2 et trouvé dans alsa.c des modifications à essayer. (C'est l'auteur du code qui les propose en commentaires aux lignes 43 à 51.) Penses tu que ce soit une bonne piste ? La compilation n'étant pas mon fort, j'aimerais avant de l'entreprendre mettre un maximum de chances de mon côté...
Geo Cherchetout
Le 13/04/2013 20:55, *Nicolas George* a écrit fort à propos :
Il est probable que la source de ton problème soit qu'une des extrémités fasse un buffer underrun de la sortie sonore et doive la réinitialiser en boucle.
Normalement cela ne devrait pas se produire car le débit à l'émission est censé être asservi à la capacité de la réception, si j'interprète bien le rôle de la dernière des « features » de Mediastreamer2 citées ici : https://www.linphone.org/eng/documentation/dev/mediastreamer2.html Merci de me dire si je suis dans l'erreur.
Le 13/04/2013 20:55, *Nicolas George* a écrit fort à propos :
Il est probable que la source de ton problème soit qu'une des extrémités
fasse un buffer underrun de la sortie sonore et doive la réinitialiser en
boucle.
Normalement cela ne devrait pas se produire car le débit à l'émission est
censé être asservi à la capacité de la réception, si j'interprète bien le
rôle de la dernière des « features » de Mediastreamer2 citées ici :
https://www.linphone.org/eng/documentation/dev/mediastreamer2.html
Merci de me dire si je suis dans l'erreur.
Le 13/04/2013 20:55, *Nicolas George* a écrit fort à propos :
Il est probable que la source de ton problème soit qu'une des extrémités fasse un buffer underrun de la sortie sonore et doive la réinitialiser en boucle.
Normalement cela ne devrait pas se produire car le débit à l'émission est censé être asservi à la capacité de la réception, si j'interprète bien le rôle de la dernière des « features » de Mediastreamer2 citées ici : https://www.linphone.org/eng/documentation/dev/mediastreamer2.html Merci de me dire si je suis dans l'erreur.
Geo Cherchetout
Le 15/04/2013 23:51, j'ai écrit :
J'ai téléchargé les sources de Linphone v.3.5.2 et trouvé dans alsa.c des modifications à essayer. (C'est l'auteur du code qui les propose en commentaires aux lignes 43 à 51.) Penses tu que ce soit une bonne piste ?
J'aurais dû citer un extrait du code, le voici :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /*in case of troubles with a particular driver, try incrementing ALSA_PERIOD_SIZE to 512, 1024, 2048, 4096... then try incrementing the number of periods*/ #define ALSA_PERIODS 8 #define ALSA_PERIOD_SIZE 256
/*uncomment the following line if you have problems with an alsa driver having sound quality trouble:*/ /*#define EPIPE_BUGFIX 1*/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Bon, j'ai essayé quatre combinaisons des modifs en question et compilé autant de fois en partant du src.rpm de Mageia Cauldron et aucune n'a eu le moindre effet sur mon défaut...
Le 15/04/2013 23:51, j'ai écrit :
J'ai téléchargé les sources de Linphone v.3.5.2 et trouvé dans alsa.c des
modifications à essayer. (C'est l'auteur du code qui les propose en
commentaires aux lignes 43 à 51.) Penses tu que ce soit une bonne piste ?
J'aurais dû citer un extrait du code, le voici :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/*in case of troubles with a particular driver, try incrementing
ALSA_PERIOD_SIZE
to 512, 1024, 2048, 4096...
then try incrementing the number of periods*/
#define ALSA_PERIODS 8
#define ALSA_PERIOD_SIZE 256
/*uncomment the following line if you have problems with an alsa driver
having sound quality trouble:*/
/*#define EPIPE_BUGFIX 1*/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Bon, j'ai essayé quatre combinaisons des modifs en question et compilé
autant de fois en partant du src.rpm de Mageia Cauldron et aucune n'a eu le
moindre effet sur mon défaut...
J'ai téléchargé les sources de Linphone v.3.5.2 et trouvé dans alsa.c des modifications à essayer. (C'est l'auteur du code qui les propose en commentaires aux lignes 43 à 51.) Penses tu que ce soit une bonne piste ?
J'aurais dû citer un extrait du code, le voici :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /*in case of troubles with a particular driver, try incrementing ALSA_PERIOD_SIZE to 512, 1024, 2048, 4096... then try incrementing the number of periods*/ #define ALSA_PERIODS 8 #define ALSA_PERIOD_SIZE 256
/*uncomment the following line if you have problems with an alsa driver having sound quality trouble:*/ /*#define EPIPE_BUGFIX 1*/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Bon, j'ai essayé quatre combinaisons des modifs en question et compilé autant de fois en partant du src.rpm de Mageia Cauldron et aucune n'a eu le moindre effet sur mon défaut...
Geo Cherchetout
Le 15/04/2013 14:11, *dyrmak* a écrit fort à propos :
Ce que j'aimerais faire c'est de brancher une source sonore extérieure sur l'entrée microphone d'Ekiga ( Ekiga 4.0.0 totocompilé )
C'est ce que nous faisons ici pour nos essais, avec Ekiga comme avec Linphone. Le softphone permet de choisir le périphérique, c'est-à-dire la carte son, mais avec le mixer d'xfce ou alsamixer on désactive « micro enregistrement », on active « Entrée ligne enregistrement » de la carte considérée et on attaque l'entrée ligne avec la sortie pour écouteur d'un poste à transistors. Si besoin est, on peut basculer de l'entrée ligne à l'entrée micro et inversement en cours de conversation. Ton netbook n'ayant probablement pas d'entrée ligne, sois prudent lors de l'attaque de l'entrée micro avec un signal extérieur, c'est sensible et je crains que ce soit fragile.
Le 15/04/2013 14:11, *dyrmak* a écrit fort à propos :
Ce que j'aimerais faire c'est de brancher une source sonore extérieure sur
l'entrée microphone d'Ekiga ( Ekiga 4.0.0 totocompilé )
C'est ce que nous faisons ici pour nos essais, avec Ekiga comme avec
Linphone. Le softphone permet de choisir le périphérique, c'est-à-dire la
carte son, mais avec le mixer d'xfce ou alsamixer on désactive « micro
enregistrement », on active « Entrée ligne enregistrement » de la carte
considérée et on attaque l'entrée ligne avec la sortie pour écouteur d'un
poste à transistors. Si besoin est, on peut basculer de l'entrée ligne à
l'entrée micro et inversement en cours de conversation.
Ton netbook n'ayant probablement pas d'entrée ligne, sois prudent lors de
l'attaque de l'entrée micro avec un signal extérieur, c'est sensible et je
crains que ce soit fragile.
Le 15/04/2013 14:11, *dyrmak* a écrit fort à propos :
Ce que j'aimerais faire c'est de brancher une source sonore extérieure sur l'entrée microphone d'Ekiga ( Ekiga 4.0.0 totocompilé )
C'est ce que nous faisons ici pour nos essais, avec Ekiga comme avec Linphone. Le softphone permet de choisir le périphérique, c'est-à-dire la carte son, mais avec le mixer d'xfce ou alsamixer on désactive « micro enregistrement », on active « Entrée ligne enregistrement » de la carte considérée et on attaque l'entrée ligne avec la sortie pour écouteur d'un poste à transistors. Si besoin est, on peut basculer de l'entrée ligne à l'entrée micro et inversement en cours de conversation. Ton netbook n'ayant probablement pas d'entrée ligne, sois prudent lors de l'attaque de l'entrée micro avec un signal extérieur, c'est sensible et je crains que ce soit fragile.
dyrmak
En 16 lignes Geo Cherchetout a écrit dans news:kkkibt$g4h$ le mercredi, 17 avril 2013 à 00:12:12 :
Ce que j'aimerais faire c'est de brancher une source sonore extérieure sur l'entrée microphone d'Ekiga ( Ekiga 4.0.0 totocompilé )
C'est ce que nous faisons ici pour nos essais, avec Ekiga comme avec Linphone. Le softphone permet de choisir le périphérique, c'est-à-dire la carte son, mais avec le mixer d'xfce ou alsamixer on désactive « micro enregistrement », on active « Entrée ligne enregistrement » de la carte considérée et on attaque l'entrée ligne avec la sortie pour écouteur d'un poste à transistors. Si besoin est, on peut basculer de l'entrée ligne à l'entrée micro et inversement en cours de conversation. Ton netbook n'ayant probablement pas d'entrée ligne, sois prudent lors de l'attaque de l'entrée micro avec un signal extérieur, c'est sensible et je crains que ce soit fragile.
Tout d'abord merci de m'aviser sur la fragilité d'un netbook et en effet je suis au courant de ce type de problème, j'ai mené à bien plusieurs scéances de plus d'une heure sans qu'aucun incident vienne perturber la fluidité des échanges video-phoniques.
ethernet <---> wifi : aucun problème de fluidité ethernet <---> ethernet : aucun problème de fluidité
Par contre je ne me suis pas servi des ordinateurs pendant cette phase d'essai car se servir de firefox ou consulter un serveur pop ou autre faisait trébucher un peu le son, j'ai décidé de ne valider que les séances où seul les échanges video-phoniques étaient actifs pendant plus d'une heure. Je n'ai pas fait de communication wifi <---> wifi.
Les sources sonores utilisées m'ont assuré un flux continu de son sans distortion sur l'entrée ligne des deux ordinateurs, l'un d'eux a été attaqué à travers un mixeur adaptateur de ligne d'entrée successivement avec une serie de cassettes audio.
Le netbook a été calibré en entrée par tâtonnement à l'aide du niveau de sortie casque d'une autre source sonore. Une deuxième webcam a été utilisée pour apprécier la latence (décalage son-video)
Logiciels de l'échange Ekiga <--> Ekiga totocompilés.
Je pourrais faire des essais avec Linphone mais je ne sais pas le configurer.
dyrmak
En 16 lignes Geo Cherchetout a écrit
dans news:kkkibt$g4h$1@obelix.gegeweb.org
le mercredi, 17 avril 2013 à 00:12:12 :
Ce que j'aimerais faire c'est de brancher une source sonore extérieure sur
l'entrée microphone d'Ekiga ( Ekiga 4.0.0 totocompilé )
C'est ce que nous faisons ici pour nos essais, avec Ekiga comme avec
Linphone. Le softphone permet de choisir le périphérique, c'est-à-dire la
carte son, mais avec le mixer d'xfce ou alsamixer on désactive « micro
enregistrement », on active « Entrée ligne enregistrement » de la carte
considérée et on attaque l'entrée ligne avec la sortie pour écouteur d'un
poste à transistors. Si besoin est, on peut basculer de l'entrée ligne à
l'entrée micro et inversement en cours de conversation.
Ton netbook n'ayant probablement pas d'entrée ligne, sois prudent lors de
l'attaque de l'entrée micro avec un signal extérieur, c'est sensible et je
crains que ce soit fragile.
Tout d'abord merci de m'aviser sur la fragilité d'un netbook et en
effet je suis au courant de ce type de problème, j'ai mené à bien
plusieurs scéances de plus d'une heure sans qu'aucun incident vienne
perturber la fluidité des échanges video-phoniques.
ethernet <---> wifi : aucun problème de fluidité
ethernet <---> ethernet : aucun problème de fluidité
Par contre je ne me suis pas servi des ordinateurs pendant cette phase
d'essai car se servir de firefox ou consulter un serveur pop ou autre
faisait trébucher un peu le son, j'ai décidé de ne valider que les
séances où seul les échanges video-phoniques étaient actifs pendant
plus d'une heure. Je n'ai pas fait de communication wifi <---> wifi.
Les sources sonores utilisées m'ont assuré un flux continu de son
sans distortion sur l'entrée ligne des deux ordinateurs, l'un d'eux
a été attaqué à travers un mixeur adaptateur de ligne d'entrée
successivement avec une serie de cassettes audio.
Le netbook a été calibré en entrée par tâtonnement à l'aide du niveau
de sortie casque d'une autre source sonore. Une deuxième webcam a été
utilisée pour apprécier la latence (décalage son-video)
Logiciels de l'échange Ekiga <--> Ekiga totocompilés.
Je pourrais faire des essais avec Linphone mais je ne sais
pas le configurer.
En 16 lignes Geo Cherchetout a écrit dans news:kkkibt$g4h$ le mercredi, 17 avril 2013 à 00:12:12 :
Ce que j'aimerais faire c'est de brancher une source sonore extérieure sur l'entrée microphone d'Ekiga ( Ekiga 4.0.0 totocompilé )
C'est ce que nous faisons ici pour nos essais, avec Ekiga comme avec Linphone. Le softphone permet de choisir le périphérique, c'est-à-dire la carte son, mais avec le mixer d'xfce ou alsamixer on désactive « micro enregistrement », on active « Entrée ligne enregistrement » de la carte considérée et on attaque l'entrée ligne avec la sortie pour écouteur d'un poste à transistors. Si besoin est, on peut basculer de l'entrée ligne à l'entrée micro et inversement en cours de conversation. Ton netbook n'ayant probablement pas d'entrée ligne, sois prudent lors de l'attaque de l'entrée micro avec un signal extérieur, c'est sensible et je crains que ce soit fragile.
Tout d'abord merci de m'aviser sur la fragilité d'un netbook et en effet je suis au courant de ce type de problème, j'ai mené à bien plusieurs scéances de plus d'une heure sans qu'aucun incident vienne perturber la fluidité des échanges video-phoniques.
ethernet <---> wifi : aucun problème de fluidité ethernet <---> ethernet : aucun problème de fluidité
Par contre je ne me suis pas servi des ordinateurs pendant cette phase d'essai car se servir de firefox ou consulter un serveur pop ou autre faisait trébucher un peu le son, j'ai décidé de ne valider que les séances où seul les échanges video-phoniques étaient actifs pendant plus d'une heure. Je n'ai pas fait de communication wifi <---> wifi.
Les sources sonores utilisées m'ont assuré un flux continu de son sans distortion sur l'entrée ligne des deux ordinateurs, l'un d'eux a été attaqué à travers un mixeur adaptateur de ligne d'entrée successivement avec une serie de cassettes audio.
Le netbook a été calibré en entrée par tâtonnement à l'aide du niveau de sortie casque d'une autre source sonore. Une deuxième webcam a été utilisée pour apprécier la latence (décalage son-video)
Logiciels de l'échange Ekiga <--> Ekiga totocompilés.
Je pourrais faire des essais avec Linphone mais je ne sais pas le configurer.
dyrmak
dyrmak
En 37 lignes Geo Cherchetout a écrit dans news:kkc8bj$1fa5$ le samedi, 13 avril 2013 à 20:32:19 :
Quand Toto utilise Ekiga et Titi Linphone, tout va bien également pendant plus de 90 minutes. Toto, le seul qui « parle » pour l'expérience, entend de temps en temps des tocs, le plus souvent par paquets de trois, mais on n'est pas sûr que ces tocs ne soient pas présents dans la source du son qu'il émet lui-même. (Car Toto n'est pas un homme politique, il se fait remplacer au micro par un poste de radio.)
Désolé d'être un peu long...
Finalement mes essais ne sont pas concluants pour l'ensemble du problème puisque c'est Linphone qui semble être le cas litigieux, si on voulait bien m'aider à le configurer je pourrais l'essayer histoire de voir s'il est possible d'y apporter un rémède.
Est-ce qu'on est sûr que ce poste radio n'introduit pas des distortions ? En enregistrant un petit bout avec audacity et en écoutant le morçeau on pourrait déja s'assurer que le seuil de friture n'est pas atteint. Si déjà le signal reçu par Linphone n'est pas bon il ne fait au fond que le transporter.
La source sonore d'Ekiga devrait aussi être examinée.
dyrmak
-- Se hace camino al andar ++++ --- ++++ Linux operating system ++++ --- ++++
En 37 lignes Geo Cherchetout a écrit
dans news:kkc8bj$1fa5$1@obelix.gegeweb.org
le samedi, 13 avril 2013 à 20:32:19 :
Quand Toto utilise Ekiga et Titi Linphone, tout va bien également pendant
plus de 90 minutes. Toto, le seul qui « parle » pour l'expérience, entend de
temps en temps des tocs, le plus souvent par paquets de trois, mais on n'est
pas sûr que ces tocs ne soient pas présents dans la source du son qu'il émet
lui-même. (Car Toto n'est pas un homme politique, il se fait remplacer au
micro par un poste de radio.)
Désolé d'être un peu long...
Finalement mes essais ne sont pas concluants pour l'ensemble du
problème puisque c'est Linphone qui semble être le cas litigieux, si
on voulait bien m'aider à le configurer je pourrais l'essayer histoire
de voir s'il est possible d'y apporter un rémède.
Est-ce qu'on est sûr que ce poste radio n'introduit pas des
distortions ? En enregistrant un petit bout avec audacity et en
écoutant le morçeau on pourrait déja s'assurer que le seuil de friture
n'est pas atteint. Si déjà le signal reçu par Linphone n'est pas bon
il ne fait au fond que le transporter.
La source sonore d'Ekiga devrait aussi être examinée.
dyrmak
--
Se hace camino al andar
++++ --- ++++
Linux operating system
++++ --- ++++
En 37 lignes Geo Cherchetout a écrit dans news:kkc8bj$1fa5$ le samedi, 13 avril 2013 à 20:32:19 :
Quand Toto utilise Ekiga et Titi Linphone, tout va bien également pendant plus de 90 minutes. Toto, le seul qui « parle » pour l'expérience, entend de temps en temps des tocs, le plus souvent par paquets de trois, mais on n'est pas sûr que ces tocs ne soient pas présents dans la source du son qu'il émet lui-même. (Car Toto n'est pas un homme politique, il se fait remplacer au micro par un poste de radio.)
Désolé d'être un peu long...
Finalement mes essais ne sont pas concluants pour l'ensemble du problème puisque c'est Linphone qui semble être le cas litigieux, si on voulait bien m'aider à le configurer je pourrais l'essayer histoire de voir s'il est possible d'y apporter un rémède.
Est-ce qu'on est sûr que ce poste radio n'introduit pas des distortions ? En enregistrant un petit bout avec audacity et en écoutant le morçeau on pourrait déja s'assurer que le seuil de friture n'est pas atteint. Si déjà le signal reçu par Linphone n'est pas bon il ne fait au fond que le transporter.
La source sonore d'Ekiga devrait aussi être examinée.
dyrmak
-- Se hace camino al andar ++++ --- ++++ Linux operating system ++++ --- ++++
Geo Cherchetout
Le 17/04/2013 09:08, *dyrmak* a écrit fort à propos :
Finalement mes essais ne sont pas concluants pour l'ensemble du problème puisque c'est Linphone qui semble être le cas litigieux, si on voulait bien m'aider à le configurer je pourrais l'essayer histoire de voir s'il est possible d'y apporter un rémède.
Si tu veux bien me donner une adresse de messagerie valide, je t'envoie mon fichier ~/.linphonerc à charge pour toi de modifier les paramètres personnels. Cet unique fichier texte qui contient toute la configuration de linphone (et linphonec) est créé la première fois qu'on ferme l'application. C'est bien plus pratique qu'avec Ekiga qui disperse tout aux quatre coins d'une sorte de base de registre qui nécessite un éditeur spécial...
Est-ce qu'on est sûr que ce poste radio n'introduit pas des distortions ? En enregistrant un petit bout avec audacity et en écoutant le morçeau on pourrait déja s'assurer que le seuil de friture n'est pas atteint. Si déjà le signal reçu par Linphone n'est pas bon il ne fait au fond que le transporter.
Pas de souci de ce côté, c'est un aspect des choses que je maîtrise moins mal que l'aspect logiciel. D'ailleurs il ne s'agit pas de friture mais de son « à trous », rien à voir avec une éventuelle saturation.
Cordialement,
Le 17/04/2013 09:08, *dyrmak* a écrit fort à propos :
Finalement mes essais ne sont pas concluants pour l'ensemble du
problème puisque c'est Linphone qui semble être le cas litigieux, si
on voulait bien m'aider à le configurer je pourrais l'essayer histoire
de voir s'il est possible d'y apporter un rémède.
Si tu veux bien me donner une adresse de messagerie valide, je t'envoie mon
fichier ~/.linphonerc à charge pour toi de modifier les paramètres
personnels. Cet unique fichier texte qui contient toute la configuration de
linphone (et linphonec) est créé la première fois qu'on ferme l'application.
C'est bien plus pratique qu'avec Ekiga qui disperse tout aux quatre coins
d'une sorte de base de registre qui nécessite un éditeur spécial...
Est-ce qu'on est sûr que ce poste radio n'introduit pas des
distortions ? En enregistrant un petit bout avec audacity et en
écoutant le morçeau on pourrait déja s'assurer que le seuil de friture
n'est pas atteint. Si déjà le signal reçu par Linphone n'est pas bon
il ne fait au fond que le transporter.
Pas de souci de ce côté, c'est un aspect des choses que je maîtrise moins
mal que l'aspect logiciel. D'ailleurs il ne s'agit pas de friture mais de
son « à trous », rien à voir avec une éventuelle saturation.
Le 17/04/2013 09:08, *dyrmak* a écrit fort à propos :
Finalement mes essais ne sont pas concluants pour l'ensemble du problème puisque c'est Linphone qui semble être le cas litigieux, si on voulait bien m'aider à le configurer je pourrais l'essayer histoire de voir s'il est possible d'y apporter un rémède.
Si tu veux bien me donner une adresse de messagerie valide, je t'envoie mon fichier ~/.linphonerc à charge pour toi de modifier les paramètres personnels. Cet unique fichier texte qui contient toute la configuration de linphone (et linphonec) est créé la première fois qu'on ferme l'application. C'est bien plus pratique qu'avec Ekiga qui disperse tout aux quatre coins d'une sorte de base de registre qui nécessite un éditeur spécial...
Est-ce qu'on est sûr que ce poste radio n'introduit pas des distortions ? En enregistrant un petit bout avec audacity et en écoutant le morçeau on pourrait déja s'assurer que le seuil de friture n'est pas atteint. Si déjà le signal reçu par Linphone n'est pas bon il ne fait au fond que le transporter.
Pas de souci de ce côté, c'est un aspect des choses que je maîtrise moins mal que l'aspect logiciel. D'ailleurs il ne s'agit pas de friture mais de son « à trous », rien à voir avec une éventuelle saturation.
Cordialement,
Geo Cherchetout
Mieux, le fichier est ici : http://fossies.org/linux/privat/linphone-3.5.2.tar.gz:a/linphone-3.5.2/mediastreamer2/src/alsa.c
Mieux, le fichier est ici :
http://fossies.org/linux/privat/linphone-3.5.2.tar.gz:a/linphone-3.5.2/mediastreamer2/src/alsa.c
Mieux, le fichier est ici : http://fossies.org/linux/privat/linphone-3.5.2.tar.gz:a/linphone-3.5.2/mediastreamer2/src/alsa.c
dyrmak
En 26 lignes Geo Cherchetout a écrit dans news:kklo4o$69m$ le mercredi, 17 avril 2013 à 10:56:56 :
Le 17/04/2013 09:08, *dyrmak* a écrit fort à propos :
Finalement mes essais ne sont pas concluants pour l'ensemble du problème puisque c'est Linphone qui semble être le cas litigieux, si on voulait bien m'aider à le configurer je pourrais l'essayer histoire de voir s'il est possible d'y apporter un rémède.
Si tu veux bien me donner une adresse de messagerie valide, je t'envoie mon fichier ~/.linphonerc à charge pour toi de modifier les paramètres personnels. Cet unique fichier texte qui contient toute la configuration de linphone (et linphonec) est créé la première fois qu'on ferme l'application. C'est bien plus pratique qu'avec Ekiga qui disperse tout aux quatre coins d'une sorte de base de registre qui nécessite un éditeur spécial...
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.
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.
Il faudrait que je compile la version 3.5.2 de linphone. Je vais m'y pencher dès que possible.
Tout ce que je viens de dire ici c'est au conditionnel, je suis, pour ainsi dire, encore en phase de débroussaillage.
Est-ce qu'on est sûr que ce poste radio n'introduit pas des distortions ? En enregistrant un petit bout avec audacity et en écoutant le morçeau on pourrait déja s'assurer que le seuil de friture n'est pas atteint. Si déjà le signal reçu par Linphone n'est pas bon il ne fait au fond que le transporter.
Pas de souci de ce côté, c'est un aspect des choses que je maîtrise moins mal que l'aspect logiciel. D'ailleurs il ne s'agit pas de friture mais de son « à trous », rien à voir avec une éventuelle saturation.
Cordialement,
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.
En 26 lignes Geo Cherchetout a écrit
dans news:kklo4o$69m$1@obelix.gegeweb.org
le mercredi, 17 avril 2013 à 10:56:56 :
Le 17/04/2013 09:08, *dyrmak* a écrit fort à propos :
Finalement mes essais ne sont pas concluants pour l'ensemble du
problème puisque c'est Linphone qui semble être le cas litigieux, si
on voulait bien m'aider à le configurer je pourrais l'essayer histoire
de voir s'il est possible d'y apporter un rémède.
Si tu veux bien me donner une adresse de messagerie valide, je t'envoie mon
fichier ~/.linphonerc à charge pour toi de modifier les paramètres
personnels. Cet unique fichier texte qui contient toute la configuration de
linphone (et linphonec) est créé la première fois qu'on ferme l'application.
C'est bien plus pratique qu'avec Ekiga qui disperse tout aux quatre coins
d'une sorte de base de registre qui nécessite un éditeur spécial...
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.
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.
Il faudrait que je compile la version 3.5.2 de linphone.
Je vais m'y pencher dès que possible.
Tout ce que je viens de dire ici c'est au conditionnel, je suis, pour
ainsi dire, encore en phase de débroussaillage.
Est-ce qu'on est sûr que ce poste radio n'introduit pas des
distortions ? En enregistrant un petit bout avec audacity et en
écoutant le morçeau on pourrait déja s'assurer que le seuil de friture
n'est pas atteint. Si déjà le signal reçu par Linphone n'est pas bon
il ne fait au fond que le transporter.
Pas de souci de ce côté, c'est un aspect des choses que je maîtrise moins
mal que l'aspect logiciel. D'ailleurs il ne s'agit pas de friture mais de
son « à trous », rien à voir avec une éventuelle saturation.
Cordialement,
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.
En 26 lignes Geo Cherchetout a écrit dans news:kklo4o$69m$ le mercredi, 17 avril 2013 à 10:56:56 :
Le 17/04/2013 09:08, *dyrmak* a écrit fort à propos :
Finalement mes essais ne sont pas concluants pour l'ensemble du problème puisque c'est Linphone qui semble être le cas litigieux, si on voulait bien m'aider à le configurer je pourrais l'essayer histoire de voir s'il est possible d'y apporter un rémède.
Si tu veux bien me donner une adresse de messagerie valide, je t'envoie mon fichier ~/.linphonerc à charge pour toi de modifier les paramètres personnels. Cet unique fichier texte qui contient toute la configuration de linphone (et linphonec) est créé la première fois qu'on ferme l'application. C'est bien plus pratique qu'avec Ekiga qui disperse tout aux quatre coins d'une sorte de base de registre qui nécessite un éditeur spécial...
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.
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.
Il faudrait que je compile la version 3.5.2 de linphone. Je vais m'y pencher dès que possible.
Tout ce que je viens de dire ici c'est au conditionnel, je suis, pour ainsi dire, encore en phase de débroussaillage.
Est-ce qu'on est sûr que ce poste radio n'introduit pas des distortions ? En enregistrant un petit bout avec audacity et en écoutant le morçeau on pourrait déja s'assurer que le seuil de friture n'est pas atteint. Si déjà le signal reçu par Linphone n'est pas bon il ne fait au fond que le transporter.
Pas de souci de ce côté, c'est un aspect des choses que je maîtrise moins mal que l'aspect logiciel. D'ailleurs il ne s'agit pas de friture mais de son « à trous », rien à voir avec une éventuelle saturation.
Cordialement,
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.
