Echo Problematik

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

  • 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?

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

    • Offizieller Beitrag

    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:
    https://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...

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

  • Leute, ich hänge in der Regel nicht die fachliche Expertise als Physiker heraus. Aber an der Stelle scheint es mir sinnvoll - denn ich glaube weder an ein Softwareproblem, noch ein elektrisches Problem. Sondern an ein akustisches Problem, das man vielleicht per Software kompensieren kann.


    Lg


    Pah

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

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

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


    http://www.linphone.org/techni…er/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



  • Das ist erstmal außerhalb. Ich weis nicht ob liblinphone (was Du ja nutzt) auch die config Datei einließt. Das käme mal auf einen Versuch an, nur ist auf diesem Pi hier vor mir gerade KEIN DoorPi. In der Doku habe ich dazu auch nichts gefunden.

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

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


    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.


    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_new), 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
    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:

    Code
    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:

    Code
    cannot set echo limiter to mode [1] because no volume send
    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.

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

  • 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


    http://www.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


    https://pythonhosted.org/linph…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 :)

    4 Mal editiert, zuletzt von AndyGR42 ()

  • Hm, interessant. Also ich halte es am zielführendsten, wenn ich an dieser Stelle weiter suche.


    Kannst du mal kurz beschreiben, wie du deinen Test "außerhalb DoorPi" durchgeführt hast? Ich würde gern mal sehen, ob ich dann auch eine Verbesserung sehe. Wenn ja, liegt es irgendwo im DoorPi/Python API.

  • 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)