Echo Problematik

  • Hilfe / Ratschläge

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Da in jedem Forum ein paar Regeln eingehalten werden müssen, möchte ich diese auch vorher hier festlegen und niederschreiben. Die grundsätzliche Netiquette setze ich bei Jedem voraus. Darüber hinaus möchte ich nur spezielle Regeln ansprechen:
- Unterlasse FullQuote sondern nutze Alternativen wie Inline-Quoting
-> siehe auch https://de.wikipedia.org/wiki/Fullquote vs. https://de.wikipedia.org/wiki/TOFU#Alternativen_zu_TOFU
- Unterlasse nichtssagende Antworten wie "Danke" oder "werde ich mal testen" oder ähnliches, sofern Du nicht der Threadersteller bist und einen Lösungsvorschlag angeboten bekommen hast.
- Vermeide Doppel-Posts (zwei Beiträge von Dir hintereinander) sondern editiere wenn möglich Deine Posts.

Danke...

  • Im Prinzip arbeiten die alten, analogen Sprechstellen nach dem gleichen Prinzip und sollte kein Problem bei Wechselsprechen darstellen.

    Bei einem Telefonanruf kann das fehlende Rauschen zu Irritationen führen. Das würde aber auch ohne echo limiter passieren, sendet man bei Stille in der Regel keine Audio Pakete mehr, um Bandbreite zu sparen. Für diesen Fall gibt es comfort noise :) Der Sender verschickt dann bei Stille im RTC Paket an stelle von Daten nur die Information "CN" und wie lange diese Pause dauert. Auf der Empfängerseite wird dann Rauschen "erzeugt". Es ist auch wichtig, dass regelmäßig CN Pakete kommen, damit der Empfänger nicht denkt der RTC Strom ist abgebrochen und die Verbindung beendet.
    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)
  • Ich denke auch das man hier forciert dem Echo Problem entgegentreten sollte und das eigentlich schnellst möglich. Die Lösung was Joker gepostet hat ist sicher nicht schlecht und würde dies als sekundär Lösung in betracht ziehen. Im allgemeinen würde ich doch lieber dem Problem auf die Schliche kommen.

    Hat von Euch einer mal PJSUA versucht?
    Mit freundlichen Grüßen

    Andreas
  • Die erste Antwort sollte aber nicht der Echo Limiter sein - sondern die Echo Cancellation.
    Der Limiter ist nur der zweitbeste Ausweg.

    Wenn das klappt, ist die Doorpi-Lösung in eine andere Liga aufgerückt.

    Lg

    Pah

    P.S.:Ich sehe mich bestätigt in der Vermutung, dass die spezielle Ursache hier die akustische Kopplung über die Frontplatte ist. Damit ergibt sich noch eine Einflussmöglichkeit, nämlich der Abstand zwischen Mikrofon und Lautsprecher in der Türstation.

    Diesen so groß wie möglich zu machen, ist nicht unbedingt die Lösung - die Laufzeit des Signals wird damit größer, das Echo gewinnt an Tiefe.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von pahenning ()

  • Versuchen wir es gemeinsam - dieser Thread wurde von @Joker eröffnet, also kümmern wir uns hier auch bitte nur um sein System. Sollte jemand auch Probleme haben, dann bitte in einem anderen Theard.

    Ich kann deine Probleme hier nicht nachstellen und remote schlecht testen. Also gehen wir Stück für Stück durch und testen uns ran.

    Testfahrplan:
    1. Sip Verbindung außerhalb von DoorPi herstellen
    2. Sip Verbindung mit einem PC anstelle dem Raspberry herstellen
    3. Sip Verbindung ohne Sip Server herstellen
    4. Audio Streaming ohne Sip herstellen

    Die Hardware der TFE sollte dabei nicht geändert werden um die Werte vergleichbar zu halten.
    Nun kommen wir dazu, wie man die Qualität messen kann. Ich würde auf die subjektive Meinung von Joker vertrauen oder kennt jemand eine bessere (objektive) Messung?

    Am einfachsten lässt sich Punkt 1 testen:
    wiki.linphone.org/wiki/index.php/Raspberrypi:start

    Punkt 2 könnte mit einem PC und mit dem Linphone Client getestet werden.

    Kannst du die beiden Punkte bitte testen und die Ergebnisse in Vergleich zu Echo mit doorpi hier posten?

    Danke...
    --
    MfG Thomas
  • Auch wenn das jetzt "altklug" klingt, es wird aber künftig sicher bei der Fehlersuche / Optimierung helfen:

    • SIP (Session initiation protocol): Das ist ausschließlich die Signalisierung! Über dieses Protokoll werden, vereinfacht gesagt, nur die Steuerbefehle Übertragen. Bei allen Systemen erfolgt die Kommunikation hier über den Server / Registrar und in aller Regel nicht von Client zu Client (was aber möglich ist). Für die Übertragung kommt TCP und UDP in Frage. In einem solchen Projekt wie DoorPi würde ich TCP bevorzugen
    • (S)RTP (Real-Time Transport Protocol): Über dieses Protokoll werden die audio/video Daten übertragen. Bei einer Verbindung zwischen nur zwei Endpunkten erfolgt dies in der Regel von Client zu Client (P2P). Bei Konferenzen sternförmig vom Server (MCU) aus. Für die Übertragung wird fast ausschließlich UDP verwendet.


    Test 2+3 sollten mit PhoneLite auf der PC Seite funktionieren. Allerdings glaube ich nicht, dass dies etwas ändern wird. Ich nutze PhoneLite an der FB und teste die ganze Zeit die Verbindung von DoorPi damit. Die Anrufqualität ist exakt die gleiche wie am DECT Handgerät. Was auch nicht weiter verwundert bei eine P2P Verbindung. Für das Debugging ist es aber sicher sehr hilfreich linphone mal isoliert zu betrachten.

    Test 4 würde nur dann Sinn machen, wenn es komplett ohne linphone auskommen würde. Ich nehme an, Du meinst das auch so. Ansonsten wäre es das Gleiche wie Test 3.

    @nea: an PJUSA bin ich gescheitert. Zumindest aus DoorPi heraus.
    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)
  • Wir hatten durchaus schon Echo Probleme durch Softwarefehler auf ISDN/analog zu VOIP Gateways. Das ist nicht so ganz abwägig. In diesem Fall stimme ich aber pah zu, dass es sehr unwahrscheinlich ist und eine aktustische Rückkopplung des Signals die wahrscheinlichste Ursache ist. Das lässt sich durchaus per Software beheben, die Frage ist nur, schafft der Pi das? In professionellen Raumsystemen werden dafür in der Regel DSP's verbaut. Die Echo-Limiter Funktion dürfte weit das weniger Rechenleistung benötigen wie eine Echo-Cancellation. Dazu wird sich auch die Latenz erhöhen. Die Software muss ja beide Signale haben um das rauszurechnen. Sprich, der notwendige Puffer muss größer werden. Auch das dürfte beim Limiter nicht der Fall sein, da der beim Empfang des ausgehende Singnals einfach das Mikro abdreht. Bei Wechselsprechen ist die Latenz allerdings nicht so gar dramatisch.

    @Nea: Ich hatte das Paket installiert und ind DoorPi aktiviert. Da sich nix tat und Thomas das ganze als "experimentel" gekennzeichnet hatte, habe ich mich dann wieder linphone zugewendet.
    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)
  • Vielleicht mal ein kleiner Hinweis von mir. Ich habe ja den DoorPi parallel zu einer Siedle-Anlage im Betrieb, deren Mikrofon und Lautsprecher ich für beides nutze. Während es über den Siedle TLE 061-0 keinerlei Echos gibt, sind diese beim DoorPi durchaus wahrnehmbar, wenn auch nicht unbedingt extrem störend. Für mich spricht das aber eher für ein Softwareproblem denn für ein rein physikalisches Feedback als Ursache. Nichtsdestotrotz muss man aber Letzteres natürlich immer in Betracht ziehen.

    Gruß,

    Thorsten
  • Die Sidle Anlage hat mit an Sicherheit grenzender Wahrscheinlichkeit eine Echo Kompensation, wie auch immer die aussieht. In meiner von analog auf DoorPi umgebauten Ritto ist das Echo auch eher gering, was vermutlich an der Bauform liegt. Den Rest erledigt in der Analogen Anlage die entsprechende Beschaltung. Das man sich geringfügig selbst hört ist bei analog durchaus gewünscht, da man sonst der Meinung sein kann, die Verbundung ist unterbrochen (Stichwort comfort noise bei digital)

    Die Bauform wird entscheident zur Sprachqualität beitragen. Baut man nun Mikro und Lautspreche in ein Gehäuse, ohne die Akustik zu berücksichtigen, muss der Teil komplett von der Elektronik oder der Software übernommen werden.
    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)
  • Soo, das hat mir keine Ruhe gelassen. Und eigentlich ist es ganz einfach. Sowohl der Echo Canceller als auch der Limiter funktionieren NUR, wenn noise_gate aktiviert wurde! Bei dem Limiter steht es auch indirekt in der Doku:

    "The echo limiter is an algorithm that consists in lowering the gain of the mic input when the speaker is talking. Combined with the noise gate (see next section) it gives good results when the echo canceller no more works, because of non linear distorsion (saturation) of the echo path."

    linphone.org/technical-corner/linphone/documentation

    Ich habe im Test das Micro und den Lautsprecher auf passende Lautsterke eingestellt. Danach habe ich das Micro quasi direkt auf den Lautsprecher gerichtet, so dass ich mich im DECT Handset deutlich selbst gehört habe. Egal ob ich den Echo Canceller oder den Limiter nutze, beide funktionieren einwandfrei! beim Canceller muss ich schon ziemlich laut reinbrüllen um mich selbst zu hören. Beide Systeme habe ich mit den Default Werten getestet. Als angenehmer Nebeneffekt von noise_gate ist das Rauschen im Hörer auch weg :)

    Anbei meine Konfig /home/pi/.linphonerc (ein bisschen durcheinander...)

    Die wichtigsten Abschnitte sind:

    agc=1 (funktioniert für das Mikro 1a, besser als die Hardware)

    noisegate=1
    ng_thres=0.05
    ng_floorgain=0.0005


    echocancellation=1
    ec_delay=0
    ec_tail_len=60
    ec_frame_size=128

    - ODER -

    echolimiter=1
    el_speed=0.03
    el_thres=0.1
    el_force=10
    el_sustain=100


    Shell-Script

    1. [proxy_0]
    2. reg_proxy=192.168.67.250
    3. reg_identity=sip:621@192.168.67.250
    4. reg_expires=3600
    5. reg_sendregister=1
    6. [auth_info_0]
    7. username=621
    8. passwd=XXX
    9. #realm=192.168.67.250
    10. [rtp]
    11. download_ptime=0
    12. audio_rtp_port=7078
    13. video_rtp_port=9078
    14. audio_jitt_comp=60
    15. video_jitt_comp=60
    16. nortp_timeout=30
    17. audio_adaptive_jitt_comp_enabled=1
    18. video_adaptive_jitt_comp_enabled=1
    19. [sip]
    20. sip_port=5060
    21. media_encryption=none
    22. guess_hostname=1
    23. #contact=sip:pi@unknown-host
    24. inc_timeout=30
    25. in_call_timeout=0
    26. delayed_timeout=4
    27. use_ipv6=0
    28. register_only_when_network_is_up=1
    29. register_only_when_upnp_is_ok=1
    30. #keepalive_period=10000
    31. #Use SIP INFO to send DTMFs (digits)
    32. use_info=0
    33. #Use RFC2833 (out of band DTMFs) to send digits
    34. use_rfc2833=0
    35. #When answering to SDP offers, select only one codec,
    36. #instead of replying with all matching codecs.
    37. only_one_codec=0
    38. #Send an OPTIONS message before doing outgoing calls
    39. #This is used by Linphone to workaround some NAT problems inherent to SIP.
    40. #This is highly recommended.
    41. ping_with_options=1
    42. #Network state automatic monitoring
    43. # When set to 1, linphone will periodically monitor the network state (by checking whether it is possible
    44. # to reach the internet).
    45. # When the operating system has callbacks to notify such information, you can use
    46. # linphone_core_set_network_reachable() to notify the core, in which case no network monitoring will be done internally.
    47. #auto_net_state_mon=1
    48. [video]
    49. display=0
    50. capture=0
    51. show_local=0
    52. #########
    53. #Size of sent video among these names: QCIF, QVGA, CIF, VGA, SVGA
    54. size=cif
    55. #Whether video is enabled:
    56. enabled=0
    57. #You can refine whether it is enabled for display or capture or both
    58. display=1
    59. capture=1
    60. #Show local preview between calls.
    61. show_local=1
    62. #Show local view during calls, in a corner of the video window
    63. self_view=1
    64. #Webcam name for capture
    65. #device=V4L2: /dev/video0
    66. [net]
    67. download_bw=0
    68. upload_bw=0
    69. mtu=0
    70. #Firewall policy:
    71. # 0: assume there is no nat
    72. # 1: use firewall address supplied in "nat_address" item (discouraged)
    73. # 2: use STUN to discover its own public IP address and ports
    74. # 3: use ICE.
    75. firewall_policy=0
    76. #stun_server=stun.ekiga.net
    77. #nat_address=80.112.33.11
    78. [sound]
    79. remote_ring=/usr/share/sounds/linphone/ringback.wav
    80. playback_gain_db=0.000000
    81. mic_gain_db=0.000000
    82. playback_dev_id=ALSA:USB PnP Sound Device
    83. ringer_dev_id=ALSA:USB PnP Sound Device
    84. capture_dev_id=ALSA:USB PnP Sound Device
    85. agc=1
    86. #mic_gain=1.0
    87. #playback_gain_db=0.0
    88. #dc_removal=0
    89. ##########
    90. #turn on/off echo cancellation
    91. echocancellation=1
    92. #Expected delay of echo in milliseconds
    93. #Use this when you have a fixed latency in the sound hardware.
    94. #This allows to reduce the tail length of the echo canceller, which speeds up convergence
    95. #and reduces complexity of computations.
    96. ec_delay=0
    97. #Tail length of echo canceller in milliseconds.
    98. #Ideally it should be no more than the expected duration of the echo.
    99. ec_tail_len=60
    100. #Frame size for AU-MDF echo canceller algorithm
    101. #This is a parameter internal to the echo canceller, recommended is too keep to its default value.
    102. ec_frame_size=128
    103. #########
    104. #Enables echo limiter
    105. #this basically consists in lowering the mic input (in software)
    106. #when the speaker level is above a certain threshold
    107. #the attenuation is made proportionnal to the speaker detected level
    108. echolimiter=0
    109. #el_speed parameter: gain changes are smoothed with a coefficent
    110. #el_speed is this coefficient. It's a value between 0 and 1
    111. #0.1 is already very fast, 0.001 is very low
    112. #default value is 0.03
    113. #recommendation is to keep it unchanged
    114. el_speed=0.03
    115. #el_thres parameter
    116. #Threshold above which the system becomes active.
    117. #It is a normalized power, between 0 and 1.
    118. #Default value is 0.1
    119. # A smaller value can be better.
    120. el_thres=0.1
    121. #el_force parameter
    122. #The proportional coefficient controlling the mic attenuation.
    123. #Default value is 10
    124. el_force=10
    125. #el_sustain parameter
    126. #Time in milliseconds for which the attenuation is kept unchanged after
    127. #resuming from speech to silence on the network->speaker channel.
    128. #This is a very important parameter that needs to be adjusted
    129. #to take in account the latency of the sound card/driver.
    130. #Indeed when the echo limiter sees there is no more energy going to the
    131. #speaker, there can be still some audio buffers pending to be played
    132. #in the audio driver. These buffers are out of control of the application
    133. #and will generate echo as they are non-silence.
    134. #The purpose of the parameter is to keep the mic attenuated
    135. #for some time until the echo of these buffer is finished.
    136. #100 ms is a reasonable value to start, can be higher depending
    137. #on the hardware.
    138. el_sustain=100
    139. ###############
    140. #The noise gate is located just after mic input
    141. #Tells whether noise gate is active:
    142. noisegate=1
    143. #Noise gate threshold in linear power between 0 and 1:
    144. #Above this threshold the noise gate becomes bypass.
    145. ng_thres=0.05
    146. #Noise gate's floorgain: gain applied to the signal when its energy is below the threshold.
    147. #It is expect to be low so that noise is attenuated.
    148. ng_floorgain=0.0005
    149. [audio_codec_0]
    150. mime=G726-40
    151. rate=8000
    152. channels=1
    153. enabled=1
    154. [audio_codec_1]
    155. mime=G726-32
    156. rate=8000
    157. channels=1
    158. enabled=1
    159. [audio_codec_2]
    160. mime=G726-24
    161. rate=8000
    162. channels=1
    163. enabled=1
    164. [audio_codec_3]
    165. mime=G722
    166. rate=8000
    167. channels=1
    168. enabled=1
    169. [audio_codec_4]
    170. mime=PCMA
    171. rate=8000
    172. channels=1
    173. enabled=1
    174. [audio_codec_5]
    175. mime=PCMU
    176. rate=8000
    177. channels=1
    178. enabled=0
    179. [audio_codec_20]
    180. mime=opus
    181. rate=48000
    182. channels=1
    183. enabled=0
    184. [audio_codec_21]
    185. mime=speex
    186. rate=16000
    187. channels=1
    188. enabled=0
    189. [audio_codec_22]
    190. mime=speex
    191. rate=8000
    192. channels=1
    193. enabled=0
    194. [audio_codec_8]
    195. mime=AAL2-G726-16
    196. rate=8000
    197. channels=1
    198. enabled=0
    199. [audio_codec_9]
    200. mime=AAL2-G726-40
    201. rate=8000
    202. channels=1
    203. enabled=0
    204. [audio_codec_10]
    205. mime=speex
    206. rate=32000
    207. channels=1
    208. enabled=0
    209. [audio_codec_11]
    210. mime=AAL2-G726-32
    211. rate=8000
    212. channels=1
    213. enabled=0
    214. [audio_codec_12]
    215. mime=AAL2-G726-24
    216. rate=8000
    217. channels=1
    218. enabled=0
    219. [audio_codec_13]
    220. mime=G726-16
    221. rate=8000
    222. channels=1
    223. enabled=0
    224. [audio_codec_14]
    225. mime=L16
    226. rate=44100
    227. channels=1
    228. enabled=0
    229. [audio_codec_15]
    230. mime=L16
    231. rate=44100
    232. channels=2
    233. enabled=0
    234. [video_codec_0]
    235. mime=VP8
    236. rate=90000
    237. enabled=1
    238. [video_codec_1]
    239. mime=MP4V-ES
    240. rate=90000
    241. enabled=1
    242. recv_fmtp=profile-level-id=3
    243. [video_codec_2]
    244. mime=H263-1998
    245. rate=90000
    246. enabled=0
    247. recv_fmtp=CIF=1;QCIF=1
    248. [video_codec_3]
    249. mime=theora
    250. rate=90000
    251. enabled=0
    252. [video_codec_4]
    253. mime=H263
    254. rate=90000
    255. enabled=0
    Alles anzeigen
    Bilder
    • WP_20160522_19_37_57_Pro.jpg

      189,47 kB, 1.280×722, 199 mal angesehen
    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)
  • AndyGR42 schrieb:



    Ich habe im Test das Micro und den Lautsprecher auf passende Lautsterke eingestellt. Danach habe ich das Micro quasi direkt auf den Lautsprecher gerichtet, so dass ich mich im DECT Handset deutlich selbst gehört habe. Egal ob ich den Echo Canceller oder den Limiter nutze, beide funktionieren einwandfrei! beim Canceller muss ich schon ziemlich laut reinbrüllen um mich selbst zu hören. Beide Systeme habe ich mit den Default Werten getestet. Als angenehmer Nebeneffekt von noise_gate ist das Rauschen im Hörer auch weg :)

    Es wäre schön wenn hier weitere Versuche stattfinden würden, vieleicht kommt man hiermit eher zum Erfolg.
    Mit freundlichen Grüßen

    Andreas
  • pahenning schrieb:

    Wenn das klappt, ist die Doorpi-Lösung in eine andere Liga aufgerückt.
    DAS sehe ich absolut genau so. Von daher würde ich sagen, natürlich können wir die Problemfindung an meinem konkreten Fall ansehen, aber man sollte es durchaus höher aufhängen- wie gesagt hat jeder mehr oder weniger große Probleme mit Echo, und das haben kaufbare Lösungen von der Stange nicht. Von daher, wenn wir eine allgemein funktionierende Lösung finden, steht DoorPi ganz anders da.

    pahenning schrieb:

    P.S.:Ich sehe mich bestätigt in der Vermutung, dass die spezielle Ursache hier die akustische Kopplung über die Frontplatte ist.
    Ja schon, wobei es aber in meinem Fall so ist, dass weder das Mikro noch der Lautsprecher mit der Frontplatte verbunden sind- es scheint wohl eher mit dem geschlossenen Gehäuse zu tun zu haben.

    AndyGR42 schrieb:

    Soo, das hat mir keine Ruhe gelassen. Und eigentlich ist es ganz einfach. Sowohl der Echo Canceller als auch der Limiter funktionieren NUR, wenn noise_gate aktiviert wurde! Bei dem Limiter steht es auch indirekt in der Doku:

    "The echo limiter is an algorithm that consists in lowering the gain of the mic input when the speaker is talking. Combined with the noise gate (see next section) it gives good results when the echo canceller no more works, because of non linear distorsion (saturation) of the echo path."

    linphone.org/technical-corner/linphone/documentation

    Ich habe im Test das Micro und den Lautsprecher auf passende Lautsterke eingestellt. Danach habe ich das Micro quasi direkt auf den Lautsprecher gerichtet, so dass ich mich im DECT Handset deutlich selbst gehört habe. Egal ob ich den Echo Canceller oder den Limiter nutze, beide funktionieren einwandfrei! beim Canceller muss ich schon ziemlich laut reinbrüllen um mich selbst zu hören. Beide Systeme habe ich mit den Default Werten getestet. Als angenehmer Nebeneffekt von noise_gate ist das Rauschen im Hörer auch weg :)
    Das finde ich schon mal sehr sehr geil! Ich werde versuchen die Tage mich auch mal weiter mit dem Thema zu beschäftigen und auch die genannten Tests durchzuführen. Kann aber etwas dauern, meine Familie will mich auch ab und zu mal außerhalb des Bastelkellers sehen :D :P

    Was ich am Wochenende mal noch gemacht habe (@'motom001'), ich habe mir mal angeschaut wo DoorPi eigentlich die Einstellungen vornimmt. Dies scheint ja in der Datei from_linphone.py zu passieren. Dort gibt es folgende Zeile:

    Python-Quellcode

    1. self.core.echo_cancellation_enabled = conf.get_bool(SIPPHONE_SECTION, 'echo_cancellation_enabled', False)


    Ich habe jetzt einfach mal darunter folgendes eingefügt entsprechender der LinPhone API:

    Quellcode

    1. self.core.echo_limiter_enabled = True
    Das scheint auch irgendwas zu tun, leider nicht funktional. Also sprich, am Problem ändert sich nichts. Ich sehe im DoorPi Log folgende Fehlermeldung:

    Quellcode

    1. cannot set echo limiter to mode [1] because no volume send
    2. cannot set noise gate mode to [1] because no volume send
    Das bringt mich zu zwei Schlußfolgerungen:
    1. Das Noise Gate scheint irgendwie standardmäßig aktiv zu sein
    2. Irgendwie schafft er es nicht, den Limiter einzuschalten. Google macht mich hier irgendwie auch nicht schlauer

    Daher: Wie könnte man heraus finden, ob die LinPhone-Lib, wenn über die Python API angesprochen, auch das Config-File mit den Settings einliest? Laut @AndyGR42 scheint der Limiter ja funktional zu sein, also irgendein Problem gibt es da noch.
    Und: Wie kann man LinPhone dazu bringen, mehr Logs zu generieren? Ich denke LinPhone hat alles an Bord was benötigt ist, man muss jetzt "nur" noch rausfinden, warum es innerhalb DoorPi nicht funktioniert...
  • Theoretisch kannst Du das ganz schnell prüfen. Kopiere einfach die .linphonerc (ohne .txt) in das home Verzeichnis des Users, der DoorPi ausführt (z.B. /home/pi). Du solltest schnell merken, ob liblinphone die Datei nutzt oder nicht. Ich habe gerade keine lauffähige DoorPi Installation, da ich noch alle Komponenten einzeln teste.

    In den Python Wrapper Classes habe ich noise_gate nicht gefunden. Wenn sich das über Python nicht aufrufen lässt, liegt vielleicht genau hier das Problem. Dann könnte man mal die Entwickler kontaktieren.
    Dateien
    • .linphonerc.txt

      (3,89 kB, 189 mal heruntergeladen, zuletzt: )
    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)
  • Ich teste es mal an meiner Anlage am WE, denn das Echo habe ich auch. Ob aus- oder eingebaut, das macht kaum einen Unterschied. Meines Erachtens nach durch das das Übersprechen des Lautsprecher-Signals auf das Mikrofon an der Anlage (DoorPI, außen). Aber die Erkenntnis ist ja nicht neu. Nur halte ich bei mir ein mechanisches Phänomen (Schwingungen) für das Thema mit dem geringeren Einfluss.
    Cheers,
    Marcus
    -------------------------------------------------------
    Mein DoorPi (Eingebaut und in Betrieb)
  • Joker schrieb:

    Das bringt mich zu zwei Schlußfolgerungen:
    1. Das Noise Gate scheint irgendwie standardmäßig aktiv zu sein
    2. Irgendwie schafft er es nicht, den Limiter einzuschalten. Google macht mich hier irgendwie auch nicht schlauer

    Daher: Wie könnte man heraus finden, ob die LinPhone-Lib, wenn über die Python API angesprochen, auch das Config-File mit den Settings einliest? Laut @AndyGR42 scheint der Limiter ja funktional zu sein, also irgendein Problem gibt es da noch.
    Und: Wie kann man LinPhone dazu bringen, mehr Logs zu generieren? Ich denke LinPhone hat alles an Bord was benötigt ist, man muss jetzt "nur" noch rausfinden, warum es innerhalb DoorPi nicht funktioniert...
    Die beiden Meldungen "cannot set echo limiter to mode [1] because no volume send" habe ich auch bei den erfolgreichen Tests in den Logs. Sie kommen immer mal wieder. Ich vermute fast, immer dann wenn kein Audio von der Gegenstelle empfangen wird. Sie tauchen z.B. bei "RINGING" auf, wo eigentlich noch gar keine RTP Verbindung da ist. Da aber Early Media aktiv ist, könnte der Filter starten, empfängt kein Audio von innen und spuckt die Fehlermeldung aus. Ich findes es interessant, dass er automatisch noise_gate starten will.

    Log files kann man mit linphonc tonnenweise erzeugen. Für die lib gibt es eine Class, nur keine Ahnung wie man da an die Daten kommt.

    P.S.: In der Beschreibung der lib tauchen die Klassen für die Verwaltung der config und zum schreiben der Logfiles auf:

    linphone_core_set_log_file

    linphone_core_set_log_level_mask

    linphone.org/docs/liblinphone/group__misc.html

    Im Python Wrapper sind die aber nicht zu finden.

    P.P.S.:

    Doch:
    read_file()

    Reads a user config file and fill the LpConfig with the read config values.
    Parameters:Returns:Return type:
    filename (string) – The filename of the config file to read to fill the LpConfig
    int


    pythonhosted.org/linphone/api_…nphone.LpConfig.read_file

    Es gibt auch div. set_ Befehle, mit denen wohl auch config items geschrieben werden können.
    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von AndyGR42 ()

  • sudo apt-get update
    sudo apt-get upgrade (optional)
    sudo apt-get linphone

    linphonec einmal starten (legt die .linphonerc Datei an, alternativ meine kopieren)

    config anpassen (in meiner sind proxy_0 und auth_info_0 auskommentiert. Das kannst Du nutzen damit sich linphone direkt an der FB anmeldet. realm wird nicht benötigt!)

    linphonec -d 3 -l /home/pi/linphone.txt (wird bei jedem start neu geschrieben!)

    call sip:11@192.168.1.1

    (Beispiele für Türsprechstelle an FB)
    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)