Echo Problematik

  • Pperfekt, ich schaue dass ich das so bald wie möglich ausprobieren kann!


    Ich habe jetzt auch noch mal nen 10er investiert und mir noch zwei andere Mikrofone bestellt (die, die @han-solo und @MarcusS verwenden). Nicht dass ich da groß was von erwarte, aber ich möchte sehen ob ich da Unterschiede feststellen kann- nicht dass es am Ende nur an einem "schlechten" Mikrofon liegt...

  • Das Paket linphone4raspberry kann definitiv die .linphonerc lesen und schreiben. Das konnte ich mit


    core = linphone.Core.new(callbacks, ConfigFile, None) in einem einfachen Python script nachweisen. Leider endet hier mein Python Know How, so dass alle weiteren Schritte extrem zeitaufwändig werden. Da müsste jetzt mal jemand ran, der die Module in doorpi besser kennt :)

  • Das könnte ein Thema sein, ich habe in der Datei from_linphone.py die vermutlich equivalente Stelle gefunden:


    Python
    1. config_path = None
    2. factory_config_path = None
    3. self.__Lib = lin.Core.new(
    4. self.callback.used_callbacks,
    5. config_path,
    6. factory_config_path
    7. )

    Das config_path auf none steht, wird vermutlich das Config-File nicht eingelesen..?


    //edit: Die API-Doku sagt:


    Zitat
    • vtable (dictionary) – The callbacks.
    • configPath (string) – A path to a config file. If it does not exists it will be created. The config file is used to store all settings, call logs, friends, proxies... so that all these settings become persistent over the life of the LinphoneCore object. It is allowed to set to None. In that case LinphoneCore will not store any settings.
    • factoryConfigPath (string) – A path to a read-only config file that can be used to store hard-coded preference such as proxy settings or internal preferences. The settings in this factory file always override the one in the normal config file. It is OPTIONAL, use None if unneeded.
  • Vermutlich. Ich habe nur keinen blassen Schimmer wie man die Daten aus der .linphonerc in Python weiter verwursten kann. Vielleicht reicht ja die Sektion [sound] und der Rest kommt aus der Laufzeit. Rein Theoretisch müsste man ja quasi alle Infos hier ablegen und aus der DoorPi.ini rauswerfen können. Das wäre sicher kein schlechter Ansatz die Übersichtlichkeit zu verbessern. Und bei künftigen Erweiterungen von linphone muss nicht auch noch DoorPi angepasst werden.


    P.S.: über die Callbacks und Set_Log_Handler kann man auch steuern wie gesprächig das ist und wohin die Daten geschrieben werden.

  • Da müsste jetzt mal jemand ran, der die Module in doorpi besser kennt

    Jop - geht los - was gibts zu tun...

    vermutlich equivalente Stelle

    Richtig - das ist die Stelle.

    aus der DoorPi.ini rauswerfen können

    Ungern...

    Callbacks und Set_Log_Handler

    Ist in DoorPi bereits so umgesetzt - DoorPi Log umfasst auf Trace-Level _alle_ Meldungen von Linphone. In der Linphone eigenen Log sollten keine zusätzlichen Einträge vorhanden sein.


    Ich würde gern daraufhin arbeiten, dass Linphone in DoorPi integriert ist und nicht, dass DoorPi läuft und Linphone auch. Zwei Config und Zwei LogDateien machen den Support bei Problemen schwer bzw. unmöglich. Eigentlich versuche ich mit DoorPi schon alle Parameter von Linphone zu setzen, die gesetzt werden können und sinnvoll sind. Diese tauchen dann auch in der SIP-Phone Sektion der DoorPi Config auf. Sollten noch Parameter fehlen, dann ergänze ich die gerne. Dazu muss ich nur wissen welche das sind und wie die angesprochen werden können.


    Es gibt auch Parameter, die in der Python-API nicht angesprochen werden können. Das würde dann ein Änderungswunsch in der maillinglist von linphone bedeuten und warten bis diese Anpassung umgesetzt ist. Jetzt brauche ich die Info, welche Parameter gesetzt werden müssen - ich programmiere das dann gern innerhalb von DoorPi, dass diese auch gesetzt werden können.

  • Könnten nicht zumindest die Logs bestimmter Module bei Bedarf in separate Dateien laufen? Es ist echt mühsam die wichtigen Dinge wie SIP Messages oder Infos über Codecs aus dem Wust an Zeilen zu fischen. Es könnte sehr hilfreich sein das bei Bedarf separat zu haben.


    Ich habe gerade folgendes ausprobiert:


    Doorpi.ini: (EVENT_OnTimeHour0 löse ich über Doorpi web aus)





    .linphonerc_doorpi: (+ codec, aber das wäre hier zu lang)






    from_linphone.py:


    Python
    1. config_path = None
    2. factory_config_path = "/home/pi/.linphonerc_doorpi"
    3. self.__Lib = lin.Core.new(
    4. self.callback.used_callbacks,
    5. config_path,
    6. factory_config_path
    7. )





    Das funktioniert so ohne Echo. Ich hatte zuerst den config_path verwendet. Das hat aber den Nachteil, dass linphone bei jedem Aufruf einen neuen Proxy anlegt und auch das Call Log in die Datei schreibt. factory_config_path ist read only.


    Wenn ich das richtig sehe sind nicht alle Parameter über die Python API (oder Java etc.) direkt Ansprechbar.


    ABER: Es gibt ja die Möglichkeit mit set_xxx Parameter quasi in Freitext in der lpconfig zu setzen. Im Prinzip wäre es notwendig, alle Parameter aus der Sektion [sound] setzen zu können. Bei mir funzt das mit default Werten. Bei Anderen vielleicht nicht.

    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)

    4 Mal editiert, zuletzt von AndyGR42 ()

  • Thomas :


    Wenn Du Dir das Leben einfach machen willst, was wäre mit diesem Vorschlag:


    In der "class linphone.LpConfig"


    gibt es einige Funktionen wie z.B.


    set_int()


    Sets an integer config item


    Parameters:
    section (string)
    key (string)
    value (int)



    Wenn das möglichst flexibel werden soll, würde ich einfach passende Sektionen in die doorpi ini schreiben und dann stumpf alle darin enthaltenen Werte in linphone reinschießen:


    [lpconfig_sound_int]
    echocancellation=0
    ec_delay=0
    ec_tail_len=60
    ec_frame_size=128
    echolimiter=0
    el_sustain=100
    el_force=10
    noisegate=1


    [lpconfig_sound_float]
    el_speed=0.03
    el_thres=0.1
    ng_thres=0.05
    ng_floorgain=0.0005



    Das erhält die Flexibilität und Du musst nicht bei jeder Änderung den Code ändern. Die Basis Werte, welche immer nötig sind damit das SIP Phone überhaupt eine Verbindung aufbaut, können ja unter SIP-Phone bleiben. Alle "Spezialeinstellungen" wie Echo Cancellation oder Codec Auswahl würde ich in den lpconfig spezifischen Teil schieben. Das macht es auch einfacher, alternative Soft Phones einzubinden.

  • Klingt ja schon sehr gut, ich kanns kaum erwarten es auszuprobieren bei mir.


    Noch ein Vorschlag von mir:

    Könnten nicht zumindest die Logs bestimmter Module bei Bedarf in separate Dateien laufen? Es ist echt mühsam die wichtigen Dinge wie SIP Messages oder Infos über Codecs aus dem Wust an Zeilen zu fischen. Es könnte sehr hilfreich sein das bei Bedarf separat zu haben.

    Wie wäre es denn, wenn man die Logger-Konfiguration flexibler gestaltet? Soweit ich weiß, kann bisher nur ein globales --trace gesetzt werden. Man könnte ja zusätzlich eine Domain angeben z.B. --trace --domain=sipphone.
    Oder so ähnlich. So dass man nur bestimmte Logs auf Trace schaltet. Das würde es für solche Fälle enorm vereinfachen.

  • Könnten nicht zumindest die Logs bestimmter Module bei Bedarf in separate Dateien laufen?

    Bisher nicht vorgesehen - ist theoretisch möglich aber ist das auch sinnvoll (nachdem dieses Problem hier gelöst ist)?

    Das funktioniert so ohne Echo.

    Hattest Du vorher ein Echo?

    nicht alle Parameter über die Python API (oder Java etc.) direkt Ansprechbar.

    das hab ich mir gedacht...

    Bei mir funzt das mit default Werten.

    Welche Werte sind dadurch anders gesetzt als wenn man die linphone-config nicht nutzt. Wenn eh alles default Werte sind, sollte das doch keinen Einfluss haben.

    In der "class linphone.LpConfig"


    gibt es einige Funktionen wie z.B.

    Hat DoorPi auch:
    https://github.com/motom001/Do…onf/config_object.py#L194

    [lpconfig_sound_int]

    Da es ein ini-File ist, sollte es nicht zwingend eine Typisierung benötigen. Eventuell kann an Linphone an der Stelle auch ein string übergeben werden und der wird von liblinphone entspreche konvertiert.
    Sonst würde ich eine Abfolge nutzen:
    1. Konvertiere in float
    2. wenn fehlgeschlagen, konvertiere in int
    3. wenn fehlgeschlagen, konvertiere in str
    denn in der linphone config weiß ich ja aktuell auch nicht, was ein float und was ein int ist...

    Das würde es für solche Fälle enorm vereinfachen.

    Aber nur für den Fall hier und jetzt - oder würde das Log später auch helfen?
    Dann müsste man in der einen Log suchen, wann wurde die Taste gedrückt, im nächsten Log suchen welches Event verarbeitet wurde und in der dritten Log welche Nummer wie angerufen wurde. Das macht den Support sehr sehr umständlich. Ist es jetzt wirklich so stark überladen? Welche Module schreiben während eines Anrufen durch linphone denn noch in die doorpi-Log? Bei mir schreibt während eines Anrufes nur linphone.

  • Hattest Du vorher ein Echo?

    Ja, und das kann ich reproduzieren wenn ich die linphonerc nicht mehr über das geänderte from_linphone.py lade


    Welche Werte sind dadurch anders gesetzt als wenn man die linphone-config nicht nutzt. Wenn eh alles default Werte sind, sollte das doch keinen Einfluss haben.

    Anscheinend ja nicht. Lader ich die linphonerc nicht, funktionieren echo canceller und echo limiter ja nicht. Außerdem muss es ja bei anderen nicht sofort mit den default Werten funktionieren (ec / el an oder aus). Ich kann mich z.B. auch noch hören, wenn ich sehr laut spreche. Vermutlich muss ich draußen auch noch die Lautstärke des Lautsprechers erhöhen. Beides kann dazu führen, dass ich entweder auf el umstellen oder an den Parametern drehen muss.


    Dazu kommt der Zugriff auf Parameter, die wir noch gar nicht hatten. Z.B. der Jitter buffer. Der steht auf 60ms, was bei einem ordentlichen LAN ok sein sollte. Bei einem WLAN unter Last könnte das schon mal knapp werden. Weder G711 noch G722 haben sowas wie eine Fehlerkorrektur. Da hört man Jitter oder Packet Loss sehr schnell. Oder die Ports, oder...


    Bisher nicht vorgesehen - ist theoretisch möglich aber ist das auch sinnvoll (nachdem dieses Problem hier gelöst ist)?


    Aber nur für den Fall hier und jetzt - oder würde das Log später auch helfen?Dann müsste man in der einen Log suchen, wann wurde die Taste gedrückt, im nächsten Log suchen welches Event verarbeitet wurde und in der dritten Log welche Nummer wie angerufen wurde. Das macht den Support sehr sehr umständlich. Ist es jetzt wirklich so stark überladen? Welche Module schreiben während eines Anrufen durch linphone denn noch in die doorpi-Log? Bei mir schreibt während eines Anrufes nur linphone.

    Sagen wir es mal so. Manchmal ist zu viel Log schlechter als zu wenig. Wenn alle 5ms eine Statusänderung gepollt wird, ist das wahrscheinlich für den Software Entwickler wichtig:


    [DEBUG][doorpi.sipphone.from_linphone] [PYLINPHONE] >>> pylinphone_Core_get_in_call_timeout(0x74ec9cc8 [0x6e5e48])


    Wenn ich nach Fehlern im SIP/RTC Protokoll suche ist das völlig uninteressant. Da interessiert mich SIP und die Klartextausgabe von linphonec in der Kommandozeile. Darin sind alle Informationen wie Codecs, Filter und später die Statistiken enthalten. Hier könnte schon der Level INFO helfen. Da stehen die für mich wichtigen linphone Daten drin. Wenn ich das richtig sehe gibt es aber nur debug und trace.

  • Wenn Du das Problem reproduzieren kannst, kannst Du dann bitte eine Option nach der anderen aus der linphone-config rauslöschen und feststellen, wann das Problem wieder auftritt?
    Ich kann das Problem hier nicht nachstellen, sonst würde ich diese Fleißaufgabe übernehmen...


    Eventuell kannst Du das auch zuerst mit einer leeren linphone-config testen - eventuell werden andere Default-Parameter geladen, wenn die config angegeben wird.

  • Ok, kann ich machen. Könnte aber etwas dauern. Zwischendurch muss ich auch mal arbeiten ;) Spätestens nächstes WE sollte das aber durch sein.


    Wobei mir gerade einfällt, wie man das abkürzen könnte. Wenn man OHNE Datei, aber mit Pfadangabe startet, müsste die Config eigentlich angelegt und geschrieben werden...


    Das war einfach. :) Wie ich schon befürchtet habe, fehlen in der Default Config viele Parameter. Man kann sagen, was nicht von DoorPi kommt ist auch nicht da. Das ist auch einer der Gründe warum ich mich ungern auf so etwas wie "Default" verlasse. Nicht gesetzt ist für mich gleich undefiniert, so lange nicht sehen kann was im Hintergrund passiert.


    Die anderen Tests mache ich später.


    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)

    Einmal editiert, zuletzt von AndyGR42 ()

  • Da ich gerade noch eine Ungereimtheit entdeckt hatte, habe ich mich mal auf die drei Parameter konzentriert (in meiner vollständigen config):


    echocancellation
    echolimiter
    noisegate


    Ohne noisegate, keine Echo Unterdrückung. Ich würde sagen, das ist überwiegend oder sogar zu 100% dafür verantwortlich. Selbst mit echocancellation und echolimiter deaktiviert funktioniert die Echo Unterdrückung. Ob sie durch die beiden anderen Optionen noch mal besser wird und welche Wirkung die anderen Parameter haben, dass kann ich in meinem Versuchsaufbau nicht herausfinden. Dazu müsste man mit festen Größen messen. Mit den Default Werten jedenfalls kann ich keinen auffallenden Unterschied feststellen.


    Für einen Quick-Win könnten wir erst mal mit den Parametern


    noisegate=1
    ng_thres=0.05
    ng_floorgain=0.0005


    starten. Ich würde aber doch empfehlen, die Parameter "Freitext" übergeben zu können damit wir alle aktuell und zukünftig verfügbaren Einstellungen übernehmen können. SIP/RTC ist im DoorPi Projekt ein ganz dickes Modul für sich. Da wir uns aktuell noch in LAN Umgebungen ohne Router, NAT, etc. bewegen ist das halbwegs trivial. Spätestens wenn mal jemand auf die Idee kommt sein DoorPi mit einer CloudPBX zu koppeln brauchen wir auch die [net] und [sip] Parameter. Video kann auch schnell ein Thema werden.

  • Da wäre mir noch zu viel drin. Was ganz gut passen würde wäre ein Filter auf alle [INFO] Messages. Ich weis, auch das geht mit grep, aber für ein Logfile kann ich DoorPi ja nicht interaktiv starten ;)

  • https://github.com/motom001/DoorPi/tree/linphone_config


    Installation laut dieser Anleitung: Anleitung Pi2 + Jessie (Release 2016-02-26) mittels manueller Installation
    Branch ist "linphone_config"


    Geändert ist vor allem dieser Bereich:
    https://github.com/motom001/Do…one/from_linphone.py#L179 bis Zeile 198


    Konfiguration in der doorpi-ini mittels:


    Code
    1. [linphone]
    2. sound_noisegate=1
    3. net_download_bw=0

    Die Sektion der linphone config ist dem Key vorangestellt und die Gesamtsektion hat den Namen 'linphone'. Vorerst werden alle Parameter als string geladen, sollte das nicht klappen, denke ich mir was aus.


    Alternativ kann auch die linphone-Config komplett geladen werden:


    Code
    1. [SIP-Phone]
    2. factory_config_path=/home/pi/.linphonerc
  • Wow, hier passiert was- gefällt mir außerordentlich :thumbup:
    Ich komme heute und vermutlich auch morgen leider nicht dazu es zu testen- viel anderes um die Ohren zur Zeit. Aber ich mache es natürlich definitiv!

    Aber nur für den Fall hier und jetzt - oder würde das Log später auch helfen?Dann müsste man in der einen Log suchen, wann wurde die Taste gedrückt, im nächsten Log suchen welches Event verarbeitet wurde und in der dritten Log welche Nummer wie angerufen wurde. Das macht den Support sehr sehr umständlich. Ist es jetzt wirklich so stark überladen? Welche Module schreiben während eines Anrufen durch linphone denn noch in die doorpi-Log? Bei mir schreibt während eines Anrufes nur linphone.

    Das würde schon später auch helfen. Vielleicht ist nicht ganz klar geworden was ich meinte, ich versuche es noch mal zu umreißen (ich kenne das auch von vielen anderen Projekten so, also das ist nichts was ich mir mal eben ausgedacht habe).
    - aktuell kann man- zumindest soweit mir bekannt- DoorPi nur mit "normalen" Log-Output (= nur nötigste Informationen) starten, oder mit "vollen" Informationen ("--trace")
    - dadurch werden sehr viele Informationen geloggt, eigentlich zu viele wenn man wie hier ein Problem in einem bestimmten Bereich sucht
    - der Gedanke war, dass man anstatt Trace-Level für alle Module einzuschalten, nur für ein oder mehrere bestimmte Module einschaltet, z.B. den SIP Bereich
    - es gibt immer nur ein LogFile, nur eben entsprechend gefiltert
    - als Beispiel würde man jetzt eben den Trace-Level für den SIP-Bereich einschalten, die anderen können auf default bleiben. Für einen anderen Use-Case (z.B. "Warum wird meine Aktion nicht richtig ausgeführt?") kann man z.B. nur den EventHandler auf Trace-Level stellen

    Da wäre mir noch zu viel drin. Was ganz gut passen würde wäre ein Filter auf alle [INFO] Messages. Ich weis, auch das geht mit grep, aber für ein Logfile kann ich DoorPi ja nicht interaktiv starten ;)

    Das wäre auch zusätzlich hilfreich. Ich kenne es von anderen Projekten mit verschiedenen Log-Levels (z.B. TRACE, DEBUG, INFO, WARN, ERROR, wobei bei Trace am meisten geloggt wird und bei ERROR eben nur echte Fehler), und zusätzlich Logging-Domains (hier z.B. Sip, EventHandler...). So kann man genau die Informationen im benötigten Bereich loggen lassen, die man für den gerade zu suchenden Fehler eben braucht. Das wird spätestens dann hilfreich, wenn das Projekt komplexer wird.

  • So, ich konnte es doch nicht erwarten und bin noch mal ran. Habe den Branch installiert und mit den Settings mal initial herumgespielt- Erfolge kann ich noch nicht vermelden.
    Ich habe als erstes versucht Noisegate und Echocanceller einzuschalten, was bei mir (scheinbar) bisher keine Veränderung bringt.
    Dann habe ich es mit dem Limiter probiert, da dies zwar die schlechtere aber einfachere Lösung ist und daher schneller zum Laufen bringen sein sollte.


    Settings sehen so aus:


    Code
    1. [linphone]
    2. sound_noisegate=1
    3. sound_echolimiter=1
    4. sound_echocancellation=0
    5. sound_ng_thres=0.05
    6. sound_ng_floorgain=0.0005
    7. sound_el_speed=0.03
    8. sound_el_thres=0.1
    9. sound_el_force=10
    10. sound_el_sustain=100

    Im Prinzip erstmal default Werte. Aber auch hier keine Verbesserung. Ich werde in den nächsten Tagen weiter experimentieren, evtl. auch mal mit der Lösung außerhalb DoorPi um einen Vergleich zu haben.


    Was mir noch eingefallen ist: Wie verhält sich das mit den Settings die es vorher schon gab? Dort gibt es ja in SIP-Phone den Eintrag echo_cancellation enabled. Den könnte man jetzt dort auf True setzen und in der neuen Section auf 0, wer gewinnt? :D

  • Danke! Das nenne ich mal schnelle Arbeit!



    Da Thomas derzeit noch alle Werte als String an linphone übergibt, die benötigten aber vermutlich alle integer oder float sind, würde ich mich darauf aktuell nicht verlassen und auch mal den factory_config_path ausprobieren.


    Zum Thema doppelt. Der factory_config_path / config_path wird beim start des core gelesen. Zur Laufzeit werden alle anderen Parameter geschrieben. In welcher Reihenfolge, das müsste Thomas uns sagen können.


    BTW, welche am Ende gewonnen haben (oder überhaupt gesetzt werden konnten) kannst Du leicht rausfinden, in dem Du den config_path auf eine nicht vorhandene Datei zeigen lässt. Beim Beenden schreibt linphone alle gesetzten Paramater da rein.

  • wer gewinnt?

    Die neue Config von linphone wird beim initalisieren geladen, die anderen zur Laufzeit beim DoorPi-Start. Somit gewinnen die alten Werte...


    Da aber @AndyGR42 das mit dem factory_config_path getestet hat, diese Einstellungen auch beim Initialisieren geladen werden und trotzdem geholfen haben, sollten es also Einstellungen sein, die ergänzend benötigt werden. Somit vermute ich auch, dass noise_gate ist die entsprechende Stelle.