Echo Problematik

  • 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
    [linphone]
    sound_noisegate=1
    sound_echolimiter=0
    sound_echocancellation=1
    sound_ng_thres=0.05
    sound_ng_floorgain=0.0005
    sound_el_speed=0.03
    sound_el_thres=0.1
    sound_el_force=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...

  • motom001_new: Die Parameter landen in der falschen Sektion bei linphone.


    Ich habe mal die from_linphone.py angepasst, damit die config auch wieder zurück geschrieben werden kann:


    Python
    factory_config_path = conf.get(SIPPHONE_SECTION, 'factory_config_path', '')
            config_path = conf.get(SIPPHONE_SECTION, 'config_path', '')
            self.__lib_config = lin.LpConfig.new_with_factory(
                None if config_path is '' else config_path,
                None if factory_config_path is '' else factory_config_path
            )



    doorpi.ini:


    Die geschriebene config sieht dann so aus:



    Bei genauerem Hinschauen entdeckt man dann ein typisches Copy&Paste Problem:


    Python
    for config_key in conf.get_keys('linphone', 'rtp_'):
                self.__lib_config.set_string('rtp', config_key[4:], conf.get('linphone', config_key))
            for config_key in conf.get_keys('linphone', 'sip_'):
                self.__lib_config.set_string('rtp', config_key[4:], conf.get('linphone', config_key))
            for config_key in conf.get_keys('linphone', 'video_'):
                self.__lib_config.set_string('rtp', config_key[6:], conf.get('linphone', config_key))
            for config_key in conf.get_keys('linphone', 'net_'):
                self.__lib_config.set_string('rtp', config_key[4:], conf.get('linphone', config_key))
            for config_key in conf.get_keys('linphone', 'sound_'):
                self.__lib_config.set_string('rtp', config_key[6:], conf.get('linphone', config_key))


    Ich habe das auch mal angepasst.


    und schon klappt es (auch mit dem echo, string kann also bleiben):



    Auf diese Weise funktionieren beide Methoden. Wir sollten nun noch überlegen in wie weit wir die Parameter ausmisten. Aktuell können sie in der DoorPi.ini ja doppelt angegeben werden. Mein Vorschlag dazu steht ja weiter oben.


    Joker: Wenn ich das richtig sehe werden die in der [linphone] Sektion angegebenen Parameter durch die in [SIP-Phone] überschrieben. Die Reihenfolge wäre also:


    • factory_config
    • [linphone]
    • [SIP-Phone]
  • 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: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...

    Ich würde alle Tests mit linphonec außerhalb von DoorPi machen. So wie es aussieht funktioniert string, aber wenn nicht und float Werte ignoriert oder gerundet werden, wirst Du bei den Tests nicht weiterkommen. Wenn alles passt sollten die gleichen Werte in DoorPi auch das gleiche Ergebnis liefern.

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

  • Moin.


    Ich kann aus zeitlichen Gründen auch erst wieder intensiver testen, wenn ich den Krempel zusammenbaue. Ich würde dann auch mit definierten Größen (Sinus aus dem Funktionsgenerator) testen, um wirklich mal eine solide Datenbasis zu haben. Meine Stimme ist da einfach zu variabel :)


    Bis dahin reicht mir erst mal der Effekt durch noise_gate um weiter zu machen. Es unterdrückt zumindest ein Echo von einem normal gesprochenen Wort und einen großen Teil des Rauschen.

  • @motom001


    Könnest Du bitte den config_path Parameter mit aufnehmen? Ich finde es extrem praktisch, nicht nur für die Fehlersuche, die Config zurückschreiben zu können.


    Danke


    Python
    factory_config_path = conf.get(SIPPHONE_SECTION, 'factory_config_path', '')
            config_path = conf.get(SIPPHONE_SECTION, 'config_path', '')
            self.__lib_config = lin.LpConfig.new_with_factory(
                None if config_path is '' else config_path,
                None if factory_config_path is '' else factory_config_path
            )
  • Nabend.


    Da ich gerade dabei bin, alle Komponenten zusammen zu fügen, habe ich mich auch noch mal mit dem Echo. Nach einigem Suchen beschleicht mich das Gefühl, dass die EC Funktion von linphone entweder gar nicht funktioniert, nur mit einer bestimmte speex Bibliothek oder sogar nur mit dem speex Codec. Hat schon jemand mit den Entwicklern Kontakt aufgenommen? Ich finde die Doku echt unter aller S... Man findet in verschiedenen Abschnitten irgendwelche Brocken, die hoffentlich zusammenpassen.


    Den EC habe ich nicht ans Laufen bekommen. Mit noisegate kann man so etwas ähnliches simulieren, das hat nur den Haken, dass der Gast ziemlich im die Sprechstelle brüllen muss um über den "Rauschpegel" zu kommen. Das ging natürlich auch nicht. Ich habe hier dann noch Infos zur Android Version gefunden. Damit funktioniert zumindest der EL: http://www.linphone.org/docs/l…core/package-summary.html


    EL würde mir bei eines Sprechstelle reichen, da gerade der Gast an der Sprechstelle nicht gleichzeitig hören und sprechen kann. Zumindest nicht sinnvoll. Mit der folgenden Konfiguration klappt es zumindest soweit, dass ich mich allenfalls in sehr kurzen Bruchstücken am Anfang eines Wortes oder Satzes höre (muss man sicher noch fein tunen wenn alles zusammengebaut ist):




    Ganz wichtig dabei: agc AUS! acg der Soundkarte EIN!


    Dann habe ich aus Jux und Dollerei mal zwei Elektretkapseln an der Soundkarte angeschlossen. Ich hatte zufällig zwei identischen. Und was soll ich sagen. Das hört sich um LÄNGEN besser an als eine Kapsel über beide Kanäle. Vor allem ist es lauter und deutlicher. Ich denke, das werde ich auch in der Sprechstelle so einbauen.

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

    Einmal editiert, zuletzt von AndyGR42 ()

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

  • Moin.


    Ich dachte das auch. Aber ich bin nun davon überzeugt, dass ich noisegate für EC gehalten habe. ng_thres auf 0.05 blockt wohl einen ziemlich hohen Level, so dass Echo gar nicht erst entstehet. Oder nur, wenn man wirklich Laut in Telefon ruft. Allerdings unterdrückt das auch die leise gesprochenen Worte von der Sprechstelle. Dreht man ng_thres soweit runter, dass wirklich nur noch das Grundrauschen geblockt wird, dann ist auch das Echo wieder da.


    EC zu aktivieren brachte keine spürbare Veränderung. Der EL schon. Hier muss man sicher noch mal die Werte anpassen, aber auf dem Tisch funktioniert das zufriedenstellend.


    Die agc Einstellung muss ich noch mal final testen. Ich bin aber der Meinung, es ist ohne besser. Was verblüffend viel gebracht hat war das 2. Mikro.

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

  • Ich habe je eine an L/R angeschlossen. Offensichtlich hat die USB Soundkarte auch beide Eingänge. Zumindest kann ich in beide Mikros sprechen. Ob das wirklich Stereo ist habe ich nicht ausprobiert. Da müsste man mal eine Aufnahme machen. linphone macht daraus eh mono.


    PCMU und PCMA sind G711, also ein Schmalband Codec. G722 ist ein Breitband (HD) Codec. Da ist definitiv ein Unterschied zu hören, auch wenn die Hardware (Mikros) der Sprechstelle definitiv nicht HD sind :) Der Codec kann einfach ein größeres Frequenzspektrum übertragen. Dadurch klingt die Stimme natürlicher und wird besser verständlich. G711 schneidet mehr ab.




    Meine linphonerc (factory_config)


    Ach ja. Die Werte aus der DoorPi.ini überschreiben die linphonerc Einstellungen. Das ist eindeutig getestet durch das Zurückschreiben der linphonerc. Außerdem haben die Änderunge auch Auswirkungen.

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

  • Das kann verschiedene Ursachen haben. Z.B. ist bei mir Jitter mit G722 (15ms) höher als bei G711 (5ms). Bei einem adaptiven Jitter Buffer erhöht sich dadurch die Latenz um 10ms. Das liegt in einem Bereich, der kaum wahrnehmbar ist, könnte aber reich technisch auf einen EC/EL Einfluss haben.


    15ms Jitter sind schon einigermaßen viel für ein Ethernet. Lange nicht kritisch, da bei einer Latenz von 0-2ms die 15ms für den Jitter Buffer keinen wirklich hörbaren Unterschied machen. So ganz erklären kann ich mir das aber noch nicht. G722 belastet die CPU des Pi jetzt nicht messbar mehr.

  • Hallo,


    gibt es eigentlich hier einen Fortschritt ?
    Ich habe seit einigen Wochen bei meinem installierten DoorPi (mit Ansteuerung auf ein Siedle Mic+LS) extremes Echo.
    Komischerweise hatte ich nach Einbau und Test keinerlei Echo.
    Erst nach einigen Tagen bemerkte ich das Echo, obwohl ich keinerlei Werte oder EInstellungen verändert habe, oder auch Updates installiert habe.
    Hatte leider auch keine Zeit mich drum zu kümmern.


    Nun hab ich endlich mal Zeit und hab gleich mal ein Systemupdate gefahren, aber beim DoorPi immer noch die 2.5.0.2


    Was könnte ich Testen um das Echo zu minimieren (Leider sind die Ausführungen hier ziemlich "durcheinander".)
    Kann ich die Änderungen hier nur testen, wenn ich mir nen Dev-Branch von DoorPi auschecke , oder geht das auch mit dem Standard 2.5.0.2 ?


    Für Hinweise wäre ich dankebar.



    Gruß,


    Markus

  • Hi,


    nein, habe noch nichts hier aus dem Thread probiert, auch weil ich noch ncith die kmpl. Zusammenhänge / Abhängigkeit verstanden habe.
    Scheitert schon bei der Frage, ob ich das alles mit der 2.5.0.2 zu testen ist, oder mit welcher Version ich das testen kann.


    Ich werde mal versuchen aus den Angaben hier schlau zu werden und es dann zu testen.



    gruß,


    Markus