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

[the-chopper]

Also scheint sehr gut zu laufen, allerdings habe ich sehr viele meldungen in syslog a lá:

ECHOCAN: TXBUF Underrun:4096 txbuflen:92 rxcancellen:128
ECHOCAN: TXBUF Underrun:4127 txbuflen:115 rxcancellen:128

kann man das irgendwie beeinflüssen?

Ich habe die selbe Debug-Meldung. Versuch einfach mal in misdn.conf den echocancel= Wert unter den kleinsten Wert hinter txbuflen: zu setzen. Also hin deinem Fall 64. Da es aber bei mir die Sprachquali noch nicht beeinflusst hat, hab ichs net getestet.


EDIt: nur in ner ruhigen Minute ausprobieren, hat bei mir grad nach dem Verbindungsaufbau das Gespräch gekillt.

 

[Larry]

BTW:
Habe gestern mal * auf den aktuellen Stand gebracht und bei der Gelegenheit auch mal wieder einen Blick auf das mISDN-GIT (mISDN v1.2) geworfen. Der GIT-Baum (Stand gestern) ließ sich diesmal sofort und einwandfrei durchkompilieren.

Folgende Neuerungen sind mir aufgefallen:
- OSLEC-Patch bereits integriert (OSS)
- OctWare's SoftEcho ebenfalls enthalten (Kommerziell)

Was mir bei den Test-Telefonaten noch auffiel, ist, dass OSLEC mir jetzt nicht mehr hörbar die Echo-Trainingsphase für 1-2 Sekunden ins Ohr brummt.

-
Larry

 

[onkel_fritz]

BTW:
Habe gestern mal * auf den aktuellen Stand gebracht und bei der Gelegenheit auch mal wieder einen Blick auf das mISDN-GIT (mISDN v1.2) geworfen. Der GIT-Baum (Stand gestern) ließ sich diesmal sofort und einwandfrei durchkompilieren.

hi larry

hört sich toll an; kannst du mir deine genaue kernelversion sagen, mit der dir das geglückt ist?
oder könntest du einmal mit dem letzten GIT-KERNEL probieren?

mfg onkel_fritz

 

[sterkel]

Bei mir hat es mit mit Kerneln aus der 2.6.22.x-Reihe geklappt. Bei den 2.6.23.x Versionen hatte ich keinen Erfolg.

 

[sterkel]

geworfen. Der GIT-Baum (Stand gestern) ließ sich diesmal sofort und einwandfrei durchkompilieren.

Folgende Neuerungen sind mir aufgefallen:
- OSLEC-Patch bereits integriert (OSS)

So, nun habe ich auch versucht, alles auf den neusten Stand (über git) zu bringen und das ist das traurige Resultat:

  == Parsing '/etc/asterisk/misdn.conf': Found
Dec 12 16:11:14 WARNING[2899]: misdn_config.c:665 _build_port_config: misdn.conf: "pipeline=oslec" (section: first_extern) invalid or out of range. Please edit your misdn.conf and then do a "misdn reload".

Das ist chan_misdn-rc36.

...
HFC 3 cards installed
mISDN_dsp: Audio DSP  Rev. 1.30 (debug=0x0) dtmfthreshold(100)
mISDN_dsp: DSP clocks every 64 samples. This equals 2 jiffies.
dsp_pipeline_module_init: dsp pipeline module initialized
mISDN_dsp_element_register: hwec registered
mISDN_dsp_element_register: mec2 registered
mISDN_dsp_element_register: mg2ec registered
mISDN_dsp_element_register: kb1ec registered
mISDN_dsp_element_register: oslec registered
Zaptel Transcoder support loaded

Der Oslec ist anscheinend drin.

Ausgabe von lsmod:
voip2007:/etc/asterisk# lsmod
Module Size Used by
zttranscode 7336 0
mISDN_dsp_oslec 7168 0
mISDN_dsp_kb1ec 5280 0
mISDN_dsp_mg2ec 6272 0
mISDN_dsp_mec2 5280 0
mISDN_dsp 194976 4 mISDN_dsp_oslec,mISDN_dsp_kb1ec,mISDN_dsp_mg2ec,mISDN_dsp_mec2

 

[Larry]

Mogähn!

hört sich toll an; kannst du mir deine genaue kernelversion sagen, mit der dir das geglückt ist?

Guckst Du Footer, siehst Du Kernel-Version
Es ist 2.6.22-gentoo-r9

oder könntest du einmal mit dem letzten GIT-KERNEL probieren?

Du meinst eine GIT-Version von Stand 13./14.12.? Das kann ich nachher gerne mal austesten...
Ich kann auch ggf. "meinen" GIT-Stand als Attachement bereitstellen; ich weiß nur nicht, ob es gerne gesehen wird, hier ständig immerhin 3.8 MB rumzuwuchten

-
Larry

 

[Larry]

So, nun habe ich auch versucht, alles auf den neusten Stand (über git) zu bringen und das ist das traurige Resultat:

  == Parsing '/etc/asterisk/misdn.conf': Found
Dec 12 16:11:14 WARNING[2899]: misdn_config.c:665 _build_port_config: misdn.conf: "pipeline=oslec" (section: first_extern) invalid or out of range. Please edit your misdn.conf and then do a "misdn reload".

Das ist chan_misdn-rc36.

Hmmm...hast Du auch in /etc/mISDN.conf eingetragen, dass Du OSLEC haben möchtest?
Zum Bleistift:

[b]/etc/mISDN.conf:[/b]
[...]
<module>mISDN_dsp_oslec</module>
[...]

-
Larry

 

[sterkel]

Ja, das Modul wird geladen (lsmod):

mISDN_dsp             195008  5 mISDN_dsp_oslec,mISDN_dsp_kb1ec,mISDN_dsp_mg2ec,mISDN_dsp_mec2

Als chan_misdn verwende ich die rc36. Und die mag die Option "pipeline=oslec" nicht.

Und im Kernelmodul ist:

  dmesg | grep "ISDN Stack core"
Modular ISDN Stack core version (1_2_0) revision ($Revision: 1.40 $)

 

[shasta]

Moin,

Als chan_misdn verwende ich die rc36. Und die mag die Option "pipeline=oslec" nicht.

Bring mal ein -DMISDN_1_2 in den CFLAGS im chan_misdn Makefile rein.

MfG
MB

 

[sterkel]

Danke! Das war die Lösung!

new: creating OSLEC with deftaps=128 and training=0
ECHOCAN: TXBUF Underrun:4096 txbuflen:64 rxcancellen:128

Jetzt werd ich noch ein wenig Feintuning machen.
Hoffentlich spiele ichs dabei nicht wieder kaputt

 

[jackfritt]

Ich wollte heute auch mal misdn GIT-Master branch testen, da ich mich leider selbst höre. Trotz angeblich gepatchtem mISDN 1.1.7.

Leider compiliert der git tree nicht und der patch von der mailingliste der das
compilieren ermöglichen soll läßt sich nicht mehr anwenden.

/usr/src/mISDN.git# patch -p1 < ../mISDN-1_1_6.patch
(Stripping trailing CRs from patch.)
patching file drivers/isdn/hardware/mISDN/capi.c
Hunk #1 FAILED at 258.
Hunk #2 FAILED at 269.
Hunk #3 FAILED at 280.
Hunk #4 FAILED at 291.
4 out of 4 hunks FAILED -- saving rejects to file drivers/isdn/hardware/mISDN/capi.c.rej
(Stripping trailing CRs from patch.)
patching file drivers/isdn/hardware/mISDN/hfc_multi.c
Hunk #1 FAILED at 167.
Hunk #2 FAILED at 238.
Hunk #3 FAILED at 4428.
3 out of 3 hunks FAILED -- saving rejects to file drivers/isdn/hardware/mISDN/hfc_multi.c.rej
(Stripping trailing CRs from patch.)
patching file drivers/isdn/hardware/mISDN/udevice.c
Hunk #1 FAILED at 2025.
1 out of 1 hunk FAILED -- saving rejects to file drivers/isdn/hardware/mISDN/udevice.c.rej

Da ich mit dem gepatchten 1.1.7+oslec das echo problem habe und leider nicht weiß welche Parameter ich dort ändern kann wäre es toll wenn mir jemand ein paar Ideen nennen könnte wo ich dran rumschrauben soll.

Es wäre nämlich auch mal toll ein paar Statistiken abrufen zu können bzw. irgendetwas in den log files zu sehen wie es ja scheinbar mit dem git tree zu sehen ist.

Danke für Ideen,

Jörg

 

[Larry]

Tach auch!

Leider compiliert der git tree nicht und der patch von der mailingliste der das compilieren ermöglichen soll läßt sich nicht mehr anwenden.

/usr/src/mISDN.git# patch -p1 < ../mISDN-1_1_6.patch

Nanu? Du versuchst, den Patch für mISDN-v1.16 auf mISDN-GIT (v1.2) anzuwenden? Das wird Dir wohl eher nicht gelingen, woll?

Im Zweifelsfalle lies Dir nochmals die vergangenen Beiträge durch; speziell meine Erfolgsmeldungen mit Sourcen.

Guckst Du hier:
http://www.ip-phone-forum.de/showpost.php?p=977144&postcount=35
und hier:
http://www.ip-phone-forum.de/showpost.php?p=993184&postcount=42

Und wenn das alles nicht hilft, gib Laut, dann lasse ich Dir meinen letzten GIT-Stand aus Post #42 zukommen.

Gutes Gelingen,
wünscht Larry

 

[schlaile]

Hallo,

habe gerade eben auch den aktuellen GIT-Baum zum ersten Mal gebaut

Auf einem 2.6.22.5-er Kernel muß man tatsächlich noch etwas Hand anlegen und die capi.c
mit einem

#define MISDN_COMPAT_KMEMCACHE 1

verschönern. Was immer noch bitter aufstößt: hfcpci-Treiber entladen führt weiterhin zielsicher in einen Kernel-OOPs.

Naja, ansonsten scheint es zu rennen.

Echo-Verhalten wirkt in der Tat etwas besser als bei mISDN-1.1.5...

@larry: hast Du zufällig schonmal eine hfcpci-Karte zu "Echo-freundlichem" Verhalten überreden können? hfcmulti hat ja netterweise einen poll-Parameter, den man runterziehen kann, die hfcpci-Karten leider nicht...

Viele Grüße,
Peter

 

[Larry]

hfcpci-Treiber entladen führt weiterhin zielsicher in einen Kernel-OOPs.

Kann ich bzgl. hfcpci bestätigen; das ist zwar ärgerlich, aber (für mich) verschmerzbar, da die Angalgen üblicher Weise 24/7 laufen.

Echo-Verhalten wirkt in der Tat etwas besser als bei mISDN-1.1.5...

Unbedingt!

@larry: hast Du zufällig schonmal eine hfcpci-Karte zu "Echo-freundlichem" Verhalten überreden können? hfcmulti hat ja netterweise einen poll-Parameter, den man runterziehen kann, die hfcpci-Karten leider nicht...

Ja, guckst Du hier:
http://www.ip-phone-forum.de/showpost.php?p=965963&postcount=30
kurzum: seit dem Post laufen diese beiden Installationen quasi perfekt.
(siehe ergänzend hierzu auch
http://www.ip-phone-forum.de/showpost.php?p=993184&postcount=42 )

-
Larry

 

[jackfritt]

@schlaile
#define MISDN_COMPAT_KMEMCACHE 1

Das wars ! compiliert nun einwandfrei allerdings habe ich auch einen kernel oops beim entladen von misdn.

Jan  4 08:40:26 gw kernel: mISDN_dsp_element_unregister: oslec unregistered
Jan  4 08:40:26 gw kernel: mISDN_dsp_element_unregister: hwec unregistered
Jan  4 08:40:26 gw kernel: dsp_pipeline_module_exit: dsp pipeline module exited
Jan  4 08:40:26 gw kernel: WARNING: at /usr/src/mISDN/drivers/isdn/hardware/mISDN/stack.c:850 release_stack()
Jan  4 08:40:26 gw kernel:  [<f08b4b84>] release_stack+0x61/0x11d [mISDN_core]
Jan  4 08:40:26 gw kernel:  [<f08b3483>] mISDN_ctrl+0x33e/0x5e1 [mISDN_core]
Jan  4 08:40:26 gw kernel:  [<c0309fe6>] klist_release+0x27/0x30
Jan  4 08:40:26 gw kernel:  [<c01e3fd2>] kref_put+0x5f/0x6c
Jan  4 08:40:26 gw kernel:  [<c030ab1b>] wait_for_completion+0xf/0x81
Jan  4 08:40:26 gw kernel:  [<c017c9b9>] sysfs_hash_and_remove+0x102/0x10f
Jan  4 08:40:26 gw kernel:  [<c01f21b4>] pci_device_remove+0x16/0x35
Jan  4 08:40:26 gw kernel:  [<c023b443>] __device_release_driver+0x6e/0x8b
Jan  4 08:40:26 gw kernel:  [<c023b83e>] driver_detach+0x64/0xa2
Jan  4 08:40:26 gw kernel:  [<c023b003>] bus_remove_driver+0x57/0x75
Jan  4 08:40:26 gw kernel:  [<c01f2249>] pci_unregister_driver+0xc/0x45
Jan  4 08:40:26 gw kernel:  [<c0131416>] sys_delete_module+0x16f/0x195
Jan  4 08:40:26 gw kernel:  [<c0140726>] remove_vma+0x36/0x3b
Jan  4 08:40:26 gw kernel:  [<c0140f90>] do_munmap+0x193/0x1ac
Jan  4 08:40:26 gw kernel:  [<c0103a96>] sysenter_past_esp+0x5f/0x85
Jan  4 08:40:26 gw kernel:  =======================
Jan  4 08:40:26 gw kernel: release_l1 id 100
Jan  4 08:40:26 gw kernel: release_l1 id 200
Jan  4 08:40:26 gw kernel: release_l1 id 300
Jan  4 08:40:26 gw kernel: release_l1 id 400
Jan  4 08:40:26 gw kernel: ACPI: PCI interrupt for device 0000:01:08.0 disabled
Jan  4 08:40:26 gw kernel: free_Application: no garbage
Jan  4 08:40:26 gw kernel: mISDNcore mISDN_modulelist not empty
Jan  4 08:40:26 gw kernel: mISDNd: daemon exit now (current:ed5a60d0)
Jan  4 08:40:26 gw kernel: mISDNcore unloaded

Ich habe einfach mal die hfc_pci.c und hfc_pci.h von 1.1.7 rüberkopiert und damit geht laden und entladen. Und scheinbar läuft Asterisk damit auch prima.

Config Dateien wie folgt.

misdn.conf von mISDN

....
<module poll="128" debug="0" timer="no">hfcmulti</module>
...
<module debug="0" options="0">mISDN_dsp_oslec</module>
....

misdn.conf von Asterisk

[default]
...
jitterbuffer_upper_threshold=0
jitterbuffer=0
[dialout]
pipeline=oslec
echocancel=256
senddtmf=yes
ports=1,2,3
rxgain=-1
txgain=-1
callgroup=1
pickupgroup=1
context=MSN
msns=*

lsmod

mISDN_dsp_oslec         7552  0
mISDN_dsp             194912  2 mISDN_dsp_oslec
hfcpci                 28100  0
hfcmulti               71276  1
mISDN_capi             92620  1
l3udss1                37508  1
mISDN_l2               35580  1
mISDN_l1               11364  1
mISDN_core             75104  7 mISDN_dsp,hfcpci,hfcmulti,mISDN_capi,l3udss1,mISDN_l2,mISDN_l1

syslog output

Jan  4 08:58:08 gw kernel: Modular ISDN Stack core version (1_2_0) revision ($Revision: 1.40 $)
Jan  4 08:58:08 gw kernel: mISDNd: kernel daemon started (current:effbb5b0)
Jan  4 08:58:08 gw kernel: mISDNd: test event done
Jan  4 08:58:08 gw kernel: ISDN L1 driver version 1.20
Jan  4 08:58:08 gw kernel: ISDN L2 driver version 1.32
Jan  4 08:58:08 gw kernel: mISDN: DSS1 Rev. 1.47
Jan  4 08:58:08 gw kernel: mISDN Capi 2.0 driver file version 1.21

.....................


Jan  4 08:47:04 gw kernel: mISDN_dsp: Audio DSP  Rev. 1.30 (debug=0x0) dtmfthreshold(1000)
Jan  4 08:47:04 gw kernel: mISDN_dsp: DSP clocks every 64 samples. This equals 2 jiffies.
Jan  4 08:47:04 gw kernel: dsp_pipeline_module_init: dsp pipeline module initialized
Jan  4 08:47:04 gw kernel: mISDN_dsp_element_register: hwec registered
Jan  4 08:47:04 gw kernel: mISDN_dsp_element_register: oslec registered

Leider sehe ich immer noch keine Statusmeldungen ala ECHOCAN im syslog.
Das Echo immer noch nich weg (Ich höre mich selbst der Angerufene hat KEINE Probleme).
Alle Telefonate laufen über hfcmulti. Die hfcpci is bei mir nur für interne
Sachen. Da is echo nich so wichtig. (Ich glaube da habe ich auch keins.)

Was mache ich falsch ?

EDIT:

Ich habe einen Fehler gefunden !!!
-DMISDN_1_2 wars. Oder noch besser einfach asterisk komplett neu compilieren !
Also vorher nochmal configure und dann ein make.

Dann scheint er auch mISDN 1.2 zu erkennen. Jetz habe ich auch endlich die Meldung im syslog

gw kernel: new: creating OSLEC with deftaps=128 and training=0


Allerdings is das Echo immer noch nich weg

EDIT:

Fehler gefunden !!!! Jetz gehts auch!!!
Es liegt genau an einer Option im Dialstring.
exten => _ZXX.,n,dial,misdn/g:dialout/${EXTEN}/n||
Nehmt dieses /n raus. Das soll eigentlich die DTMF Erkennung abschalten. Schaltet allerdings auch das echocancel ab

Und noch was es flooded die Asterisk console mit folgenden sich wiederholenden Meldungen !!

P[ 0] Unhandled Message: prim 282 len 64 from addr 52010100, dinfo 500 on this port.

Ich habe auf der misdn-asterisk lists.beronet.com mailingliste gelesen das dort noch jemand dieses Probleme hatte.
Ihm ist nach einiger Zeit sogar der ganze Rechner wegen dieser Meldung abgestürzt.


Also jetz funktioniert es auch bei mir prima. Nochmal vielen Dank fürs mitlesen und die netten Tips und
natürlich für den genialen patch



Gruss,

Jörg

 

[schlaile]

@jackfritt:

Setz noch den poll-Wert der hfcmulti auf 32 runter, dann ist es gänzlich echofrei.

Wenn die hfcpci doch auch so eine Option hätte ...

Viele Grüße,
Peter

 

[jackfritt]

@schlaile
Habe den Wert auf 32 gesetzt und muss sagen somit ist es nochmals viel besser.

Die letzen "gefühlten 40ms Echo" liegen wohl am Treiber oder ?


Gruss,

Jörg

 

[Sachmet]

Mit mISDN 1.2 habe ich auch fühlbar weniger Echo. Habe trotzdem wieder auf 1.1.5 zurückgewechstelt, da ich mit 1.2 reproduzierbar kernel oops bei gebridgten outgoing-Fax anrufen habe.

Wenn ich die Laune dazu finde, werde ich das genauer unter die Lupe nehmen. Im Produktivbetrieb geht das nun mal nicht.

Gruss,
Sachmet.

 

[schlaile]

Delay Kompensations-Patch

Hallo zusammen!

Ich habe mal wieder einen komplett ungetesteten Patch gegen mISDN-GIT verbrochen:

http://peter.schlaile.de/mISDN/misdn_delay_patch

Bekanntermassen hat mISDN ja ein kleines Verarbeitungszeit-Problem. Das zu beheben habe ich jetzt mal anderen überlassen. Was man zur Umgehung auch tun kann, ist einfach das TX-Signal, das der Echo-Cancellierer sieht, so weit verzögert verarbeiten, daß es zum zu verarbeitenden RX-Signal paßt.

Das tut der obige Patch in konfigurierbarer Weise. 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.

Der Parameter funktioniert übrigens auch bei allen anderen ECs, falls das jemandem hilft.

Ü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

Viel Erfolg und bitte einfach Feedback geben, was gebrannt hat...

Viele Grüße,
Peter

 

[jackfritt]

So,

nachdem mir immer noch Mitarbeiter von "echo" berichten (Zitat: "Ich höre mich manchmal selbst") habe ich mich an dem neuen patch probiert. Also gebrannt hat hier noch nix. Ich habe hier jetz einfach mal delay=32 genommen.

/etc/mISDN.conf

<module debug="0" options="0" delay="32">mISDN_dsp_oslec</module>

Im syslog taucht der Parameter beim laden allerdings nicht auf.

Jan 17 11:35:18 gw kernel: dsp_pipeline_module_init: dsp pipeline module initialized
Jan 17 11:35:18 gw kernel: mISDN_dsp_element_register: hwec registered
Jan 17 11:35:18 gw kernel: mISDN_dsp_element_register: oslec registered
Jan 17 11:36:02 gw kernel: new: creating OSLEC with deftaps=128 and delay=0
Jan 17 11:38:16 gw kernel: new: creating OSLEC with deftaps=128 and delay=0
Jan 17 11:40:15 gw kernel: new: creating OSLEC with deftaps=128 and delay=0

Mal schaun wie das so läuft. Ich berichte weiter.


Gruss,


Jörg