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

  • 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 :)
    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)
  • Das könnte ein Thema sein, ich habe in der Datei from_linphone.py die vermutlich equivalente Stelle gefunden:

    Python-Quellcode

    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:


    • 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.
    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)
  • AndyGR42 schrieb:

    Da müsste jetzt mal jemand ran, der die Module in doorpi besser kennt
    Jop - geht los - was gibts zu tun...

    Joker schrieb:

    vermutlich equivalente Stelle
    Richtig - das ist die Stelle.

    AndyGR42 schrieb:

    aus der DoorPi.ini rauswerfen können
    Ungern...

    AndyGR42 schrieb:

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

    Shell-Script

    1. [SIP-Phone]
    2. firewallpolicy = PolicyNoFirewall
    3. audio_codecs = PCMA,PCMU
    4. call_timeout = 30
    5. capture_device = ALSA: USB PnP Sound Device
    6. dialtone = !BASEPATH!/media/ShortDialTone.wav
    7. dialtone_renew_every_start = False
    8. dialtone_volume = 35
    9. echo_cancellation_enabled = False
    10. identity = DoorPi
    11. local_port = 5060
    12. max_call_time = 900
    13. playback_device = ALSA: USB PnP Sound Device
    14. record_while_dialing = False
    15. records = !BASEPATH!/records/%Y-%m-%d_%H-%M-%S.wav
    16. sipphonetyp = linphone
    17. sipserver_password = ****
    18. sipserver_realm = 192.168.1.1
    19. sipserver_server = 192.168.1.1
    20. sipserver_username = 621
    21. stun_server =
    22. ua.max_calls = 2
    23. video_codecs = VP8
    24. video_device = V4L2: /dev/video0
    25. video_display_enabled = False
    26. video_size = vga
    27. [keyboards]
    28. dummy = dummy
    29. [EVENT_OnTimeHour0]
    30. 10 = call:11
    Alles anzeigen





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

    Shell-Script

    1. [rtp]
    2. download_ptime=0
    3. audio_rtp_port=7078
    4. video_rtp_port=9078
    5. audio_jitt_comp=60
    6. video_jitt_comp=60
    7. nortp_timeout=30
    8. audio_adaptive_jitt_comp_enabled=1
    9. video_adaptive_jitt_comp_enabled=1
    10. text_rtp_port=11078
    11. [sip]
    12. sip_port=5060
    13. media_encryption=none
    14. guess_hostname=1
    15. #contact=sip:pi@unknown-host
    16. inc_timeout=30
    17. in_call_timeout=900
    18. delayed_timeout=4
    19. use_ipv6=0
    20. register_only_when_network_is_up=1
    21. register_only_when_upnp_is_ok=1
    22. #keepalive_period=10000
    23. use_info=0
    24. use_rfc2833=0
    25. only_one_codec=0
    26. ping_with_options=1
    27. #auto_net_state_mon=1
    28. contact=DoorPi <sip:doorpi@127.0.0.1>
    29. root_ca=/etc/ssl/certs
    30. verify_server_certs=1
    31. verify_server_cn=1
    32. default_proxy=3
    33. sip_tcp_port=5060
    34. sip_tls_port=-1
    35. [video]
    36. display=0
    37. capture=1
    38. show_local=0
    39. size=vga
    40. enabled=0
    41. self_view=1
    42. #device=V4L2: /dev/video0
    43. device=V4L2: /dev/video0
    44. [net]
    45. download_bw=0
    46. upload_bw=0
    47. mtu=0
    48. firewall_policy=none
    49. #stun_server=stun.ekiga.net
    50. #nat_address=80.112.33.11
    51. [sound]
    52. remote_ring=/usr/share/sounds/linphone/ringback.wav
    53. playback_gain_db=0.000000
    54. mic_gain_db=0.000000
    55. playback_dev_id=ALSA: USB PnP Sound Device
    56. ringer_dev_id=ALSA:USB PnP Sound Device
    57. capture_dev_id=ALSA: USB PnP Sound Device
    58. agc=1
    59. #mic_gain=1.0
    60. #playback_gain_db=0.0
    61. #dc_removal=0
    62. echocancellation=1
    63. ec_delay=0
    64. ec_tail_len=60
    65. ec_frame_size=128
    66. echolimiter=0
    67. el_speed=0.03
    68. el_thres=0.1
    69. el_force=10
    70. el_sustain=100
    71. noisegate=1
    72. ng_thres=0.05
    73. ng_floorgain=0.0005
    Alles anzeigen





    from_linphone.py:

    Python-Quellcode

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

    Dieser Beitrag wurde bereits 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.
    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)
  • Klingt ja schon sehr gut, ich kanns kaum erwarten es auszuprobieren bei mir.

    Noch ein Vorschlag von mir:

    AndyGR42 schrieb:

    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.
  • AndyGR42 schrieb:

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

    AndyGR42 schrieb:

    Das funktioniert so ohne Echo.
    Hattest Du vorher ein Echo?

    AndyGR42 schrieb:

    nicht alle Parameter über die Python API (oder Java etc.) direkt Ansprechbar.
    das hab ich mir gedacht...

    AndyGR42 schrieb:

    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.

    AndyGR42 schrieb:

    In der "class linphone.LpConfig"

    gibt es einige Funktionen wie z.B.
    Hat DoorPi auch:
    github.com/motom001/DoorPi/blo…onf/config_object.py#L194

    AndyGR42 schrieb:

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

    Joker schrieb:

    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.
    --
    MfG Thomas
  • motom001 schrieb:

    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

    motom001 schrieb:

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

    motom001 schrieb:

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

    motom001 schrieb:

    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.
    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)
  • 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.
    --
    MfG Thomas
  • 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.

    Shell-Script

    1. [sip]
    2. root_ca=/etc/ssl/certs
    3. verify_server_certs=1
    4. verify_server_cn=1
    5. contact=DoorPi <sip:doorpi@127.0.0.1>
    6. media_encryption=none
    7. sip_port=5060
    8. sip_tcp_port=5060
    9. sip_tls_port=-1
    10. in_call_timeout=900
    11. inc_timeout=30
    12. default_proxy=0
    13. [misc]
    14. uuid=02c6d919-6bd7-48a2-bf0e-2687ba4595d9
    15. [sound]
    16. echocancellation=0
    17. capture_dev_id=ALSA: USB PnP Sound Device
    18. playback_dev_id=ALSA: USB PnP Sound Device
    19. [video]
    20. display=0
    21. capture=1
    22. device=V4L2: /dev/video0
    23. size=vga
    24. [net]
    25. download_bw=0
    26. upload_bw=0
    27. firewall_policy=none
    28. [audio_codec_0]
    29. mime=opus
    30. rate=48000
    31. channels=2
    32. enabled=0
    33. [audio_codec_1]
    34. mime=speex
    35. rate=16000
    36. channels=1
    37. enabled=0
    38. [audio_codec_2]
    39. mime=speex
    40. rate=8000
    41. channels=1
    42. enabled=0
    43. [audio_codec_3]
    44. mime=PCMU
    45. rate=8000
    46. channels=1
    47. enabled=0
    48. [audio_codec_4]
    49. mime=PCMA
    50. rate=8000
    51. channels=1
    52. enabled=1
    53. [audio_codec_5]
    54. mime=GSM
    55. rate=8000
    56. channels=1
    57. enabled=0
    58. [audio_codec_6]
    59. mime=G722
    60. rate=8000
    61. channels=1
    62. enabled=1
    63. [audio_codec_7]
    64. mime=speex
    65. rate=32000
    66. channels=1
    67. enabled=0
    68. [audio_codec_8]
    69. mime=L16
    70. rate=44100
    71. channels=2
    72. enabled=0
    73. [audio_codec_9]
    74. mime=L16
    75. rate=44100
    76. channels=1
    77. enabled=0
    78. [video_codec_0]
    79. mime=VP8
    80. rate=90000
    81. enabled=1
    82. [proxy_0]
    83. reg_proxy=sip:192.168.1.1
    84. reg_identity="DoorPi" <sip:621@192.168.1.1>
    85. quality_reporting_enabled=0
    86. quality_reporting_interval=0
    87. reg_expires=3600
    88. reg_sendregister=1
    89. publish=0
    90. avpf=-1
    91. avpf_rr_interval=5
    92. dial_escape_plus=0
    93. privacy=32768
    94. [auth_info_0]
    95. username=621
    96. ha1=e7c37769eedc4ba76bad57461f601bba
    97. realm=fritz.box
    98. domain=192.168.1.1
    Alles anzeigen
    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)

    Dieser Beitrag wurde bereits 1 mal 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.
    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)
  • 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:
    github.com/motom001/DoorPi/blo…one/from_linphone.py#L179 bis Zeile 198

    Konfiguration in der doorpi-ini mittels:

    Quellcode

    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:

    Quellcode

    1. [SIP-Phone]
    2. factory_config_path=/home/pi/.linphonerc
    --
    MfG Thomas
  • 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!

    motom001 schrieb:

    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

    AndyGR42 schrieb:

    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:

    Quellcode

    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.
    Bis Ende September beruflich und privat abwesend. Ab Oktober geht es mit DoorPi weiter :)
  • Joker schrieb:

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