Beiträge von Joker

    Hallo Dennis,


    nein, leider habe ich immer noch keine Zeit gefunden mich weiter mit der Thematik zu beschäftigen. Soweit ich weiß gibt es noch keine generelle Lösung zu dem Problem.

    Hi @pahenning,


    ich schaue nach einiger Inaktivität hier mal wieder rein. Tolles Projekt hast du da mittlerweile realisiert, meinen Respekt.
    Da ich nach wie vor mit der Echo-Problematik kämpfe (siehe auch die anderen Threads- bei mir ist das Echo so laut dass es enorm bei der Kommunikation stört), habe ich noch folgende Frage, bin nicht sicher ob ich dich das schon mal gefragt habe:


    Was genau bringen zwei Mikrofone? Sind die einfach parallel geschaltet? Könnte das irgendwelche Verbesserungen bei der Echo-Problematik geben?

    Das Thema ist zwar schon was älter, aber da ich länger keine Zeit hatte mich mit meinem DoorPi zu beschäftigen und aktuell immer noch das Echo das Hauptproblem ist, melde ich mich hier noch mal zu Wort- auch vor allem weil ich dieses Thema gestartet habe.


    Leute, noch einmal zusammenfassend:


    Es ist doch wohl selbstverständlich, dass beim Vollduplexbetrieb ein Mikrofon auch die Schallwellen aus dem Lautsprecher aufnimmt

    Da stimmte ich voll und ganz zu.


    - das beeinträchtigt die Verständigungsqualität nicht (vorausgesetzt, man weiß, was man sagt...)

    Da wiederum stimme ich ganz und gar nicht zu. Es kommt vermutlich auf die Art und Stärke des Echos an- in meinem Fall ist die Verzögerung (geschätzt) einige 100ms, und die Lautstärke fast genauso laut wie das was ich an der Innenstation vom Außenstehenden höre. Ich höre also meine eigene Sprache mit leichter Verzögerung mit großer Lautstärke- es ist absolut unmöglich, so einen längeren Satz zu sagen, ohne ins "Stottern" zu kommen. Klar, wenn man nur "Hallo" sagt, und das dann kurze Zeit später noch mal hört, ist das nicht ganz so schlimm, aber Sätze die länger als die Verzögerung sind, sind in meinem Fall nicht möglich.


    Weder hört der an der Türstation Stehende dieses "Echo", noch hört man an der Innenstation ein solches "Echo" bei den Worten des an der Tür Stehenden.

    Das ist ebenso klar, ist aber in meinem Fall auch nicht das Problem, siehe oben.


    Will man das trotzdem vermeiden, kann man entweder Lautsprecher und Mikrofon akustisch entkoppeln - dabei spielt die Frontplatte und die Montage dahinter eine wesentliche Rolle.

    Ich denke auch, dass dies möglich ist, habe aber in meinem Fall jetzt schon diverse Möglichkeiten durch und bisher keine gefunden, die Problematik auf ein erträgliches Level abzumildern.


    Oder man modifiziert den Vollduplexbetrieb - zieht also vom Mikrofonsignal ein (leicht zeitverzögertes) Lautsprechersignal phasenrichtig ab. DAS haben wir mit linphone noch nicht hinbekommen.

    Ich hoffe wirklich sehr, dass in dieser Richtung noch Erfolge erzielt werden.


    Ich werde jetzt jedenfalls erstmal meinen aktuellen Projektstand wieder aufnehmen, und noch einige Versuche in Richtung Entkoppelung machen.

    Hi,
    ich bin nach wie vor auch sehr interessiert an einer Verbesserung der Audioqualität via Echo cancellation.
    Die obigen Infos sind schon mal sehr hilfreich. Beschäftigt sich aktuell jemand mit dem Thema, oder sind das erstmal nur mögliche Ansätze? Ich würde zwar gerne was zu dem Thema beitragen, weiß allerdings nicht recht wo ich da starten kann. Wenn ich das richtig sehe, gibt es die obigen Aufrufe nicht in der Python API, sondern nur in der Java API. Wie könnte man jetzt hier loslegen, so dass es am Ende auch im DoorPi funktioniert?

    So, nach langer Zeit melde ich mich mal wieder zurück.


    Ich habe im Ausgangspost die Infos und Bilder zu meiner Frontplatte ergänzt. Was die Hardware angeht, ist der DoorPi bis auf ein paar Kleinigkeiten komplett.


    Im Produktivbetrieb ist er leider immer noch nicht, da ich nach wie vor ein sehr starkes Echo habe, was das System mehr oder weniger unbenutzbar macht. In den letzten Monaten konnte ich mich leider nicht weiter mit dem Projekt beschäftige. Ich hoffe dass ich jetzt wieder etwas Zeit finde. Ich schreibe dann dazu was in den entsprechenden Threads zu dieser Problematik.

    Joker : Hast du das direkt auf dem Raspberry oder über einen Arduino?Will das im Step1 direkt über den Raspberry machen. Hast du vielleicht Links zu Dokus? Oder eine Anleitung bzw. Tipps?

    Ich habe das direkt am Raspberry. Musst mal schauen hier im Forum, ich glaube ich hatte den Schaltplan von hier im Thread. Im Endeffekt nur das TX des RDM6300 an den RX des Raspi angeschlossen über Spannungsteiler. Im Raspi-Config musste man noch irgendeine Einstellung deaktivieren dass der Raspi die serielle Schnittstelle nicht für Logausgaben verwendet.


    Mehr kann ich aktuell nicht sagen, ich hoffe es hilft dir trotzdem. Ich habe im Moment keine Zeit für das Projekt. Ich hatte ja das Problem mit dem Echo beim Gegensprechen, und dann keine Zeit mehr mich darum zu kümmern. Evtl. lässt sich in den nächsten Wochen wieder ein wenig Zeit abknabbern.

    Ok, danke. Ich werde das bei mir mal genauso übernommen und schauen wie das Ergebnis ist.


    Noch zu den Codecs: Ich weiß nicht ob das rüber gekommen ist, aber ich meinte es so, dass es nicht nur eine Auswirkung auf die Sprachqualität hatte, sondern auch auf das Ergebnis der Echo Cancellation. Warum ist mir unklar, aber ich hatte mit G722 weniger Rest-Echo als mit PCMU.

    Wie hast du die zwei Kapseln denn dann angeschlossen, einfach parallel geschaltet?


    Bei meinem letzten Test (leider auch schon wieder ein paar Tage her) hatte ich das Gefühl, dass der verwendete Codec auch einen großen Einfluss auf das Ergebnis hat. Default steht in der doorpi.ini glaube ich "PCMU, PCMA". In irgendeinem Post von dir habe ich gesehen, dass bei dir G722 vorne steht. Das habe ich dann auch mal so gemacht und das Ergebnis war definitiv anders. Vielleicht sollte man mal die inis abgleichen, nicht dass es noch irgendwas gibt was zu unterschiedlichen Ergebnissen führt.
    Ich werde wohl mal eine kleine Testreihe fahren. @AndyGR42, kannst du mal deine doorpi.ini posten, mit der EL bei dir gut funktioniert? Dann würde ich das mal als Startpunkt nehmen.


    Bei mir war es bisher jedenfalls so, wenn ich eine Einstellung gefunden hatte, die das Echo gut unterdrückt, dann war an der Sprechstelle das Mikrofon so leise, dass es auch wieder unbenutzbar war (normal lautes sprechen konnte man dann am Telefon gar nicht mehr hören).

    Jetzt verwirrst du mich. Du schriebst doch mal dass du sowohl EC als auch EL erfolgreich am laufen hattest, oder habe ich da was falsch verstanden?


    Sorry übrigens, dass ich mich hier etwas rar gemacht habe. Ich bin einfach noch nicht dazu gekommen soweit zu testen, dass ich was sinnvolles beitragen könnte... Ich hoffe es klappt spätestens bis zum Wochenende dass ich weiter komme...

    @Joker. Wie löst du das? In deinem Projekt sieht man ja die seitlich ausgerichtete Kamera. Vermutlich setzt du einen Dome drüber, oder?

    Seitlich ausgerichtet, wie meinst du das? Die Kamera zeigt bei mir genau nach vorn. Ich habe noch keine Versuche diesbezüglich gemacht, da ich weit davon entfernt bin mit dem DoorPi Produktiv zu werden. Mein Hauptproblem ist die Echo Problematik, bei der ich aus Zeitgründen noch keine weiteren Untersuchungen machen konnte, die aber dazu führen dass es aktuell sowieso nicht einsetzbar ist.

    Also ich weiß nicht was mit meinem System los ist, aber so richtig tut das bei mir nicht.


    Ich habe ich in der doorpi.ini dieselben Parameter eingetragen wie in in .linphonerc:



    Nun habe ich folgendes getestet:


    1. Anruf innerhalb DoorPi, vom DoorPi an das FritzFon
    --> keine Änderung feststellbar im Vergleich zu vorher (ohne Echo Cancellation). Echo nach wie vor vorhanden.


    2. Anruf vom FritzFon an den DoorPi durch wählen der Nummer des DoorPi:
    --> keine Hintergrundgeräusche, kein Echo. Allerdings scheint am DoorPi das Mikro soweit abgedreht zu sein, dass am FritzFon gar nichts ankommt, wenn man am DoorPi ins Mikro spricht. Das ist bei 1. nicht so.


    3. Anruf über linphone Kommandozeile, selbe Nummer wie in 1., also Anruf ans FritzFon
    --> das Echo ist vorhanden, aber zumindest ein klein wenig leiser und gefühlt mit mehr Delay. Es ist jedenfalls ein Unterschied zu 1.


    Nun stellen sich mir die Fragen:
    - Wieso ist 1. und 3. nicht gleich? Das müsste doch eigentlich so sein wenn die gleichen Parameter verwendet werden?
    - Wieso ist 1. und 2. so unterschiedlich, das ist ja prinzipiell das gleiche, nur der Initiator ist anders?


    Das ist irgendwie alles sehr kurios, zumindest aktuell noch...

    Sehr schön! Oh Mann, ich erinnere mich sogar dass ich mich gestern ganz kurz über die Codestelle gewundert habe, dass da überall rtp steht.
    Hab ich aber gestern auch nicht mehr auf die Reihe gekriegt das zu sehen. :D

    Ok, also wie gesagt, ich melde mich wenn ich weiter getestet habe.


    Eine Rückmeldung kann ich noch geben (habe gestern nacht doch noch ein wenig getestet, brennt mir durchaus unter den Nägeln das Thema):


    Und zwar habe ich mal mit der von @AndyGR42 erläuterten Methode außerhalb DoorPi (LinPhone Kommandozeile herumprobiert). Dort konnte ich interessanterweise sofort Unterschiede feststellen, wenn auch noch keine befriedigenden:
    1. wenn nur noise_gate an ist, und sonst nichts, merke ich keinen Unterschied
    2. wenn noise_gate + echo_cancel an ist, dann ist das statische Hintergrundrauschen weg, und ich kann eine leichte Verbesserung bei sehr ruhigem Sprechen feststellen (dann ist das Echo weg, aber bei meiner normalen Lautstärke kommt es wieder)
    3. wenn noise_gate + echo_limiter an ist, dann merke ich wieder keinen Unterschied zu 1.


    Also alles noch sehr komisch. Ich muss mir mal die Parameter noch genauer ansehen und damit experimentieren. Interessant ist jedenfalls, wenn ich mit dieser Config:

    Code
    1. [linphone]
    2. sound_noisegate=1
    3. sound_echolimiter=0
    4. sound_echocancellation=1
    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

    ... den DoorPi starte, merke ich keine Verbesserung, mit dem Equivalent in .linphonerc aber schon (siehe Punkt 2.). Ich werde es daher wohl zunächst mal mit factory_config_path probieren, das MUSS ja dann eigentlich genauso sein wie auf der Kommandozeile???


    We will see...

    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

    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.

    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.

    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.

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