Anderer Echo Canceller (OSLEC) im mISDN möglich?

[schlaile]

ohoh, das funktioniert so vermutlich nicht.

Lade das Modul mal von Hand mit modprobe und den passenden Parametern bis auch im Syslog ein delay ungleich 0 steht!

Viele Grüße,
Peter

 

[jackfritt]

Hmm, geht irgendwie nicht oder ich verstehe dich falsch.

modprobe  mISDN_dsp_oslec delay=32
FATAL: Error inserting mISDN_dsp_oslec (/lib/modules/2.6.22.6/extra/mISDN_dsp_oslec.ko): Unknown symbol in module, or unknown parameter (see dmesg)

syslog:

Jan 17 13:01:48 gw kernel: dsp_pipeline_module_init: dsp pipeline module initialized
Jan 17 13:01:48 gw kernel: mISDN_dsp_element_register: hwec registered
Jan 17 13:01:48 gw kernel: mISDN_dsp_oslec: Unknown parameter `delay'
Jan 17 13:02:56 gw kernel: mISDN_dsp_element_unregister: hwec unregistered
Jan 17 13:02:56 gw kernel: dsp_pipeline_module_exit: dsp pipeline module exited

Scheinbar wird der Parameter gar nicht erst erkannt.


Gruss,

Jörg

 

[jackfritt]

Ich habe dafür aber manchmal eine neue Meldung im syslog

Jan 17 13:28:01 gw kernel: ECHOCAN: TXBUF Underrun:4000 txbuflen:0 rxcancellen:32

Wie wirkt sich das aus ? Brennts da evtl doch schon heimlich ?

Gruss,

Jörg

 

[onkel_fritz]

mich interessiert immer noch unheimlich, wie bei einem rein digitalen system wie misdn es ist, überhaupt ein echo auftreten kann ....

das scheint aber niemand genau zu wissen gg

 

[sterkel]

Also spätestens im Telefonhörer ist das Signal dann doch wieder analog. Zumindest bei mir ist das so, oder Du bist ein Cyborg der direkt ans digitale Netz gekoppelt ist?
Dort entsteht auch das meiste Echo.
Mikrofon und Lautsprecher sind im Telefonhörer oder Handy sehr dicht beeinander
, da gibts fast immer Rückkopplungen.
Es sind die letzten 20cm die einem den Ärger verursachen.

 

[schlaile]

Aaaalso: der Delay-Parameter gehört in die misdn.conf von Asterisk und zwar so:

pipeline=oslec(delay=32)

Die TXBUF-underruns haben jetzt unmittelbar mit dem Patch nix zu tun, verwundern mich aber auch immer wieder. So wie ich den Sourcecode verstanden habe, heisst die 4000 nämlich das sich ein Delay von 0.5 Sekunden zwischen gesendetem und empfangenen Signal aufgebaut hat... So krass ist es nun aber auch nicht. Naja, irgendwann wird sich das finden, hoffe ich...

Zum Thema Echo: Es gibt zwei Echo-Arten:

a) Line-Echo. Bekommt man nur, wenn die Gegenseite ein _analoges_ Telefon hat (z.B. über einen TA-Adapter, aber auch, wenn am anderen Ende der Telefonleitung einer ein Analog-Telefon hat!).
D.h. das Echo entsteht, weil bei Analogtelefonen dieselbe Leitung für Lautsprecher _und_ Mikrophon verwendet wird!

Um das wegzuschaffen benötigt man einen Echo-Cancellierer wie z.B. OSLEC direkt am Interface (da entsteht das Echo schliesslich, weil kurzerhand Hin- und Rücklaufendes Signal aufeinandergeschaltet werden). Beliebig große Zeitintervalle kann der natürlich auch nicht beobachten, daher muß man darauf achten, daß die korrekten Hin- und Rücklaufenden Signale miteinander verglichen werden. Sonst "findet" OSLEC das Echo schlichtweg nicht. Da misdn leider hier ein anderes Timing vorlegt (in Worten: zu _lahm_ ist), passt das nicht so wirklich aufeinander und gecancelt wird entweder gar nichts, oder es wird noch schlimmer Echo draufgerechnet... Der Delay-Patch ist jetzt dafür da, die Signalverzögerung innerhalb von misdn zumindest wieder auszugleichen. (Man nennt das auch einen Hack

Die älteste Form der Echo-Cancellierung von Line-Echo kann man nebenbei in uralten Schwarz-Weiß-Filmen bewundern: man dämpft einfach den Sende-Pegel künstlich runter. Dann muß man höllisch ins Mikrophon brüllen, aber das Echo ist dann wenigstens größtenteils weg

Übrigens auch eine Linderungsmöglichkeit für geplagte Asterisk-Benutzer: txgain=-2 hilft ein bisschen weiter...

b) Akustik-Echo am Headset. Erfreut nicht einen selbst, sondern den Anrufer. Problem hier: Signal geht über Kopfhörer raus und wird vom Mikrophon wieder aufgefangen. Hat mit OSLEC, misdn und so weiter _rein_ _gar_ _nichts_ zu tun! Lösung: Aktuelle sjphone-Version installieren, die macht Akustik-Echo-Cancellierung direkt am Headset (wo man es auch machen muß)...

Hoffe das hilft ein bisschen beim Verständnis.

Viele Grüße,
Peter

 

[jackfritt]

@schlaile

Übrigens: Ich habe den Echo-Trainings-Parameter für OSLEC bei der Gelegenheit auch mal ausgebaut. Grund: OSLEC macht kein Echo-Training, wer es aus Versehen verwendet hat, ist selbst schuld und wurde garantiert mit einer halben Sekunde Echo/Brummen am Anfang jedes Telefonats belohnt

Meinst du damit den echocancel Parameter in der misdn.conf von Asterisk ?
Der stand bei mir immer auf yes bei dialin port bzw. 256 bei meinen outports
Ich habe die jetz mal rausgenommen.


pipeline=oslec(delay=32) in der misdn.conf funktioniert hier.
Im syslog steht dann auch entsprechendes.

Jan 18 10:26:21 gw kernel: new: creating OSLEC with deftaps=128 and delay=32

Schauen wir mal was die Kollegen in den nächsten Tagen mit diesen Werten berichten.

Danke für deine Mühen.

Gruss,

Jörg

 

[schlaile]

Meinst du damit den echocancel Parameter in der misdn.conf von Asterisk ?
Der stand bei mir immer auf yes bei dialin port bzw. 256 bei meinen outports
Ich habe die jetz mal rausgenommen.

Aeh, nein. Es gibt noch einen "training"-Parameter. Der bringt nur bei OSLEC nix.
echocancel gibt die Anzahl der Taps (=Zeitbereich auf dem OSLEC cancelt) an.
Das kann man auch ruhig mal höher setzen und schauen, was passiert.

Viele Grüße,
Peter

 

[onkel_fritz]

Also spätestens im Telefonhörer ist das Signal dann doch wieder analog. Zumindest bei mir ist das so, oder Du bist ein Cyborg der direkt ans digitale Netz gekoppelt ist?
Dort entsteht auch das meiste Echo.
Mikrofon und Lautsprecher sind im Telefonhörer oder Handy sehr dicht beeinander
, da gibts fast immer Rückkopplungen.
Es sind die letzten 20cm die einem den Ärger verursachen.

na ein scharfer ton ist das, da müsst ich ja fast ->

aber nein ich bin kein cyborg, aber es scheint du bist nicht ganz so vertraut
micht dem misdn-echo-problemchen...

aber nur mal als tipp:

du rufst mit einem isdn-telefon ein anderes an, mit nur asterisk dazwischen und hast echo;
rufst du aber die recordingfunktion von asterisk an, hast du kein echo

sehr seltsam oder sterkel?

zwei möglichkeiten -> entweder erzeugen die siemens-telefone nur echo ein, wenn sie merken das man nicht aufzeichnet;
oder möglichkeit zwei:
das echo wird auf der digitalen seite von misdn/asterisk selbst verursacht
(und ist grund meines beitrags gewesen)

 

[Larry]

Ich habe mal wieder einen komplett ungetesteten Patch gegen mISDN-GIT verbrochen
[...]
Todesmutige sollten einfach mal delay=32 oder delay=64 als Module-Parameter für das OSLEC-Module ausprobieren (512 ist das konfigurierbare Maximum), um einfach mal zu kucken, was dann passiert.

Moin großer Meister!

Ich melde mich als Todesmutiger mit delay=32 zurück. Bislang keine Probleme oder Auffälligkeiten. Funktioniert super!

Übrigens: Ich habe den Echo-Trainings-Parameter für OSLEC bei der Gelegenheit auch mal ausgebaut. Grund: OSLEC macht kein Echo-Training, wer es aus Versehen verwendet hat, ist selbst schuld und wurde garantiert mit einer halben Sekunde Echo/Brummen am Anfang jedes Telefonats belohnt

Ach guck an. Daher kam also der kurze Brumm bei mir am Anfang eines Gesprächs. Jedenfalls isser jetzt nach Deinem neuen Patch wech. Gespräche sind jetzt sehr sauber, echofrei und Frauenfreundlich (WAF).

:nemma::groesste:
-
Larry

 

[jackfritt]

Ich habe hier mit delay 32 und folgender misdn config

[PORT 4]
 -> name: dialin                     -> allowed_bearers: all
 -> far_alerting: no                 -> rxgain: -1
 -> txgain: -1                       -> te_choose_channel: yes
 -> pmp_l1_check: no                 -> reject_cause: 21
 -> block_on_alarm: no               -> hdlc: no
 -> context: Extern                  -> language: de
 -> musicclass: default              -> callerid:
 -> method: standard                 -> dialplan: 0
 -> localdialplan: 0                 -> cpndialplan: 0
 -> nationalprefix: 0                -> internationalprefix: 00
 -> presentation: -1                 -> screen: -1
 -> always_immediate: no             -> nodialtone: no
 -> immediate: no                    -> senddtmf: no
 -> astdtmf: no                      -> hold_allowed: yes
 -> early_bconnect: yes              -> incoming_early_audio: no
 -> echocancel: 0                    -> pipeline: oslec(delay=32)
 -> need_more_infos: no              -> noautorespond_on_setup: no
 -> nttimeout: no                    -> bridging: yes
 -> jitterbuffer: 0                  -> jitterbuffer_upper_threshold: 0
 -> callgroup: 1                     -> pickupgroup: 1
 -> max_incoming: -1                 -> max_outgoing: -1
 -> l1watcher_timeout: 0             -> overlapdial: 0
 -> msns: *                          -> faxdetect: no
 -> faxdetect_context:               -> faxdetect_timeout: 5
 -> ptp: no

sehr viel im syslog stehn.

Jan 23 15:02:18 gw kernel: new: creating OSLEC with deftaps=128 and delay=32
Jan 23 15:02:54 gw kernel: ECHOCAN: TXBUF Underrun:4032 txbuflen:32 rxcancellen:32
Jan 23 15:03:24 gw last message repeated 21 times
Jan 23 15:04:24 gw last message repeated 56 times
Jan 23 15:05:24 gw last message repeated 54 times
Jan 23 15:06:03 gw last message repeated 38 times
Jan 23 15:06:05 gw kernel: ECHOCAN: TXBUF Underrun:4033 txbuflen:33 rxcancellen:   32
Jan 23 15:06:06 gw kernel: ECHOCAN: TXBUF Underrun:4033 txbuflen:34 rxcancellen:   32
Jan 23 15:06:07 gw kernel: ECHOCAN: TXBUF Underrun:4033 txbuflen:35 rxcancellen:   32
Jan 23 15:06:08 gw kernel: new: creating OSLEC with deftaps=128 and delay=32
Jan 23 15:06:09 gw kernel: ECHOCAN: TXBUF Underrun:4033 txbuflen:36 rxcancellen:   32
Jan 23 15:06:10 gw kernel: ECHOCAN: TXBUF Underrun:4034 txbuflen:38 rxcancellen:   32
Jan 23 15:06:11 gw kernel: ECHOCAN: TXBUF Underrun:4034 txbuflen:40 rxcancellen:   32
Jan 23 15:06:12 gw kernel: ECHOCAN: TXBUF Underrun:4032 txbuflen:40 rxcancellen:   32
Jan 23 15:06:13 gw kernel: ECHOCAN: TXBUF Underrun:4034 txbuflen:42 rxcancellen:   32
Jan 23 15:06:14 gw kernel: ECHOCAN: TXBUF Underrun:4035 txbuflen:45 rxcancellen:   32
Jan 23 15:06:15 gw kernel: ECHOCAN: TXBUF Underrun:4033 txbuflen:46 rxcancellen:   32
Jan 23 15:06:17 gw kernel: ECHOCAN: TXBUF Underrun:4034 txbuflen:48 rxcancellen:   32
Jan 23 15:06:18 gw kernel: ECHOCAN: TXBUF Underrun:4034 txbuflen:50 rxcancellen:   32
Jan 23 15:06:19 gw kernel: ECHOCAN: TXBUF Underrun:4033 txbuflen:51 rxcancellen:   32
Jan 23 15:06:20 gw kernel: ECHOCAN: TXBUF Underrun:4033 txbuflen:52 rxcancellen:   32
Jan 23 15:06:21 gw kernel: ECHOCAN: TXBUF Underrun:4033 txbuflen:53 rxcancellen:   32
Jan 23 15:06:22 gw kernel: ECHOCAN: TXBUF Underrun:4035 txbuflen:56 rxcancellen:   32
Jan 23 15:06:24 gw kernel: ECHOCAN: TXBUF Underrun:4032 txbuflen:56 rxcancellen:   32
Jan 23 15:06:25 gw kernel: ECHOCAN: TXBUF Underrun:4033 txbuflen:57 rxcancellen:   32
Jan 23 15:06:26 gw kernel: ECHOCAN: TXBUF Underrun:4034 txbuflen:59 rxcancellen:   32
Jan 23 15:06:27 gw kernel: ECHOCAN: TXBUF Underrun:4032 txbuflen:59 rxcancellen:   32
Jan 23 15:06:28 gw kernel: ECHOCAN: TXBUF Underrun:4035 txbuflen:62 rxcancellen:   32
Jan 23 15:06:29 gw kernel: ECHOCAN: TXBUF Underrun:4033 txbuflen:63 rxcancellen:   32
Jan 23 15:06:30 gw kernel: ECHOCAN: TXBUF Underrun:4033 txbuflen:33 rxcancellen:   32
Jan 23 15:06:31 gw kernel: ECHOCAN: TXBUF Underrun:4032 txbuflen:33 rxcancellen:   32
Jan 23 15:07:02 gw last message repeated 29 times
Jan 23 15:07:50 gw last message repeated 47 times
Jan 23 15:08:24 gw kernel: new: creating OSLEC with deftaps=128 and delay=32
Jan 23 15:08:27 gw kernel: ECHOCAN: TXBUF Underrun:4032 txbuflen:32 rxcancellen:   32
Jan 23 15:08:39 gw last message repeated 7 times
Jan 23 15:15:02 gw kernel: new: creating OSLEC with deftaps=128 and delay=32
Jan 23 15:15:14 gw kernel: ECHOCAN: TXBUF Underrun:4032 txbuflen:32 rxcancellen:   32

Wobei dort in mehreren Gesprächen in den letzten Tagen echo´s drin sind. Die syslog Ausgabe hat also scheinbar primär nix damit zu tun.

Wo sollte ich dran drehn bzw. den Feuerlöscher hinstellen ?


Gruss,

Jörg

 

[schlaile]

Etwas Off-Topic: Probleme mit BN2E1 vor Alcatel OmniPCX

Hallo zusammen,

ich helfe gerne weiter beim Löschen von Echo-Bränden, bräuchte dafür aber kurz zwischendurch Eure Unterstützung:
(siehe separater Thread: http://www.ip-phone-forum.de/showthread.php?t=159621 )

Da ich ohne das hier nicht wirklich weiterentwickeln kann (sonst kann ich auf hfc_multi nicht produktiv testen und das scheinen ja hier auch ein paar andere zu verwenden

Viele Grüße & besten Dank im voraus,
Peter

 

[Junialter]

Gehe ich recht in der Annahme, dass in der aktuellen GIT-Version des mISDN das oslec patch bereits integriert ist?

 

[jackfritt]

Gehe ich recht in der Annahme, dass in der aktuellen GIT-Version des mISDN das oslec patch bereits integriert ist?

Jop, siehe hier

http://git.misdn.org/?p=mISDN.git;a=commit;h=088d9ee004926280bd888101557e4cfbcf817b17

Gruss,

Jörg

 

[KlausHo]

Hallo,

ne "vermutlich doofe" Frage zu mISDN V2 und OSLEC.

Brauche ich das Original-Kernel Modul von OSLEC noch mit mISDN V2?

Die entsprechenden Syslog-Meldungen (creating OSLEC with deftaps=128 and training=0) kommen auch ohne das Kernel Modul.

Gruß und Danke,
Klaus

 

[jackfritt]

Hallo,

ne "vermutlich doofe" Frage zu mISDN V2 und OSLEC.

Brauche ich das Original-Kernel Modul von OSLEC noch mit mISDN V2?

Die entsprechenden Syslog-Meldungen (creating OSLEC with deftaps=128 and training=0) kommen auch ohne das Kernel Modul.

Gruß und Danke,
Klaus

Ich glaube nicht das mISDN V2 und asterisk chan_misdn zusammenlaufen. Das geht ja über chan_lcr und ich weiss nicht ob das oslec unterstützt beziehungsweise wie dort überhaupt die EC Sache funktioniert.

Gruss,

Jörg

 

[KlausHo]

Ja, das läuft alles über lcr und chan_lcr.
Allerdings benutzt lcr auch mISDN V2 und der EC sitzt weiterhin im mISDN (war bei V1 auch so).
Mit lcr (und chan_lcr) kann man verschieden EC's zur Laufzeit ansprechen, unter anderem auch OSLEC.

Ich bin mir jetzt halt nur nicht sicher ob OSLEC bei mISDN dabei ist oder nur die Schnittstelle.

Den Meldungen im Syslog nach zu urteilen müsste es dabei sein. Ich weiß es aber nicht, deshalb die Frage.

Gruß, Klaus

 

[jackfritt]

Ja, das läuft alles über lcr und chan_lcr.
Allerdings benutzt lcr auch mISDN V2 und der EC sitzt weiterhin im mISDN (war bei V1 auch so).
Mit lcr (und chan_lcr) kann man verschieden EC's zur Laufzeit ansprechen, unter anderem auch OSLEC.

Ich bin mir jetzt halt nur nicht sicher ob OSLEC bei mISDN dabei ist oder nur die Schnittstelle.

Den Meldungen im Syslog nach zu urteilen müsste es dabei sein. Ich weiß es aber nicht, deshalb die Frage.

Gruß, Klaus

Ich kann mich dran erinnern wenn man die Parameter zur Laufzeit verändert hat dies im syslog zu sehen war. Sollte das bei dir auch der Fall sein würde ich davon ausgehen das es klappt. Ansonsten die misdn Mailingliste ? Evtl kann man dir dort noch weiterhelfen.

Gruss,

Jörg

 

[HobbyStern]

Hallo Jackfritt und alle anderen mISDN Pioniere

Wie steht der aktuelle oslec Stand?
Ich muss gestehen den Überblick verloren zu haben, habe mir zwar alle Beiträge zu gemüte geführt, jedoch konnte ich nicht nachvollziehen:

"Ist der Patch noch immer machbar (*1.2 / mISDN 1.1.6)"

und vorallem...

"Update ich nur einfach auf 1.1.8 ist oslec nicht schon standard?"

siehe gefunden Code in der Source:

kernel//usr/src/mISDN/drivers/isdn/hardware/mISDN/mISDN_dsp_oslec.ko

Wäre nett wenn jemand hierzu kurzen Rat hätte, Danke.

Grüsse, Stefan

 

[jackfritt]

Hallo Jackfritt und alle anderen mISDN Pioniere

Wie steht der aktuelle oslec Stand?
Ich muss gestehen den Überblick verloren zu haben, habe mir zwar alle Beiträge zu gemüte geführt, jedoch konnte ich nicht nachvollziehen:

"Ist der Patch noch immer machbar (*1.2 / mISDN 1.1.6)"

und vorallem...

"Update ich nur einfach auf 1.1.8 ist oslec nicht schon standard?"

siehe gefunden Code in der Source:

kernel//usr/src/mISDN/drivers/isdn/hardware/mISDN/mISDN_dsp_oslec.ko

Wäre nett wenn jemand hierzu kurzen Rat hätte, Danke.

Grüsse, Stefan

Leider habe ich auch nur ein Bastelsystem für die Treiber allerdings kannst du dir mal diesen Thread anschaun da steht was zum echo problem und der stabiliät.

Ich habe an meinem laufenden System wie in der Signatur nichts mehr geändert da es nur Probleme bei höheren Versionen (Kernel,mISDN,asterisk und pickup patche) gibt.
Sollte sich was ändern melde ich natürlich gerne

Gruss,

Jörg