Neuer (aktueller) Bristuff und EC

thorsten.gehrig schrieb:

Hallo

nachdem ich die ganze Zeit mit 0.2.0RC2 gut gefahren bin habe ich nun (nach meinem Urlaub) gesehen dass es die RC7k gibt.
Hier scheint sich ja einiges - gerade im Thema HFC und EC getan zu haben.

Ich setzte ein: eine Fritz (für Telekom-ISDN) und eine HFC-Karte (für meine ISDN-Telefone).

Was muss ich jetzt tun damit EC optimal geschaltet ist?
Reicht die Konfiguration in zapata.conf:
echocancel=yes
echocanelwhenbridged=yes

oder muss ich in den Dialplan noch was einschalten wie
ZapEC(on) - oder ist das dann per default auf on?

Und der Echochancel-Patch ist dann ja auch überflüssig, oder?

Gruß
Thorsten Gehrig

Zum Vergrößern anklicken....

Also ich habe seit ein paar Tagen den
Asterisk 1.0.6-BRIstuffed-0.2.0-RC7j
laufen, ohne Echo-Patch - und die Ergebnisse sind sehr vergleichbar mit alten Version inkl. Echo-Patch. Bin ziemlich zufrieden damit!

Benutze folgende Einstellungen:
/etc/asterisk/zapata.conf:echocancel=yes
/etc/asterisk/zapata.conf:echocancelwhenbridged=yes
/etc/asterisk/zapata.conf:echotraining=no

Viel Spaß damit,
Sion

sion schrieb:

Also ich habe seit ein paar Tagen den
Asterisk 1.0.6-BRIstuffed-0.2.0-RC7j
laufen, ohne Echo-Patch - und die Ergebnisse sind sehr vergleichbar mit alten Version inkl. Echo-Patch. Bin ziemlich zufrieden damit!

Zum Vergrößern anklicken....

Sion,
darf ich mal nachfragen welche CPU Du benutzt? Interessiert mich deshalb brennend, weil ich gerade mit RC7k herumspiele und ziemlich schlechte Resultate habe. Das Echo ist so stark, dass das ganze System in dieser Form unbrauchbar ist.

Mein Asterisk-System (Pentium3-700) hat auch noch noch keinen IO-APIC und zeigt daher mit "cat /proc/interrupts" entsprechend die Verwendung des alten XT-PIC als Interrupt Handler an. Hast Du das auch, oder steht bei Dir IO-APIC-edge oder so etwas?

Wie man meiner Fragerei entnehmen kann verdächtige ich die Geschwindigkeit der Interrupt-Verarbeitung das Echo zu erzeugen. Noch bin ich mir nicht ganz sicher, bekomme aber das Echo bei Verwendung von 2 HFC-Karten (1*NT, 1*TE mode) intern oder extern oder in beide Richtungen - je nachdem über welche Karte(n) das Telefonat läuft.

Deshalb mag ich im Moment auch nicht glauben, dass das hiesige Telekom-Netz und mein internes ISDN-Telefon in gleicher Weise ein praktisch nicht unterdrückbares Echo produzieren.

@fly-a-lot
Ich hab ein P2-400 Mhz und nutz ohne Probleme BRIstuffed-0.2.0-RC7k

eingebaut sind inzwischen wider zwei hfc Karten.

@fly-a-lot
Ich hab ein P2-400 Mhz und nutz ohne Probleme BRIstuffed-0.2.0-RC7k

eingebaut sind inzwischen wider zwei hfc Karten.

@lo4dro:

Oh, Mann!
Danke für die Info! Da scheine ich wohl doch falsch zu liegen wenn Dein kleiner Renner das schafft :gruebel:

Welchen Kernel benutzt Du? RTAI vermutlich passend von www.rtai.org oder?

fly-a-lot: Habe da eine ziemliche Schleuder stehen (Athlon XP2100+), der macht aber noch anderes als nur VoIP weiterzuleiten. Der ist recht neu und hat dementsprechend einen APIC...
Dafür habe ich seit ein paar Tagen manchmal ein ziemliches "Gebrutzel" auf der Leitung
Wenn ich Lust & Zeit hätte würde ich das mal unter RTAI testen, habe ich aber beides nicht.

Gruß

Mal kurz abgesehen von der Echo-Problematik:

Ich war deshalb auf die Idee gekommen, dass es bei der Interrupt-Verarbeitung klemmt weil sich der zaphfc bei mir andauernd beschwert.
Aus /var/log/messages:
Apr 13 22:01:37 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=3047, z2=3054)
Apr 13 22:02:33 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=2799, z2=2806)
Apr 13 22:05:46 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=1423, z2=1430)
Apr 13 22:06:49 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=5967, z2=5974)
Apr 13 22:10:01 AsteriskFR /usr/sbin/cron[7122]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Apr 13 22:10:06 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=8047, z2=8055)
Apr 13 22:10:49 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=3479, z2=3486)
Apr 13 22:13:33 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=5535, z2=5542)
Apr 13 22:14:43 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=4927, z2=4934)
Apr 13 22:17:53 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=4303, z2=4310)
Apr 13 22:19:04 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=4407, z2=4414)
Apr 13 22:20:01 AsteriskFR /usr/sbin/cron[7134]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Apr 13 22:21:13 AsteriskFR zaphfc: empty HDLC frame or bad CRC received (framelen = 2, stat = 0xff).
Apr 13 22:21:25 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=5367, z2=5374)
Apr 13 22:22:32 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=7815, z2=7822)
Apr 13 22:25:40 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=8087, z2=8094)
Apr 13 22:26:53 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=7319, z2=7326)
Apr 13 22:29:55 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=3143, z2=3150)
Apr 13 22:30:01 AsteriskFR /usr/sbin/cron[7147]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Apr 13 22:30:42 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=4127, z2=4134)
Apr 13 22:33:01 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=6855, z2=6862)
Apr 13 22:34:20 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=8071, z2=8078)
Apr 13 22:37:10 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=5439, z2=5446)
Apr 13 22:38:27 AsteriskFR zaphfc: dropped audio (z1=7028, z2=7010, wanted 8 got 18, dropped 10).
Apr 13 22:40:01 AsteriskFR /usr/sbin/cron[7175]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Apr 13 22:40:42 AsteriskFR zaphfc: dropped audio (z1=3851, z2=3826, wanted 8 got 25, dropped 17).

Zu anderen Zeitpunkten auch mal überwiegend dropped audio wie hier in der letzten Zeile
z.B. hier:
Apr 13 17:45:08 AsteriskFR zaphfc: dropped audio (z1=5277, z2=5256, wanted 8 got 21, dropped 13).
Apr 13 17:46:13 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=7543, z2=7550)
Apr 13 17:46:52 AsteriskFR zaphfc: bchan tx fifo full, dropping audio! (z1=2783, z2=2790)
Apr 13 17:50:06 AsteriskFR zaphfc: dropped audio (z1=2338, z2=2305, wanted 8 got 33, dropped 25).
Apr 13 17:50:30 AsteriskFR zaphfc: dropped audio (z1=1065, z2=1042, wanted 8 got 23, dropped 15).
Apr 13 17:51:20 AsteriskFR zaphfc: dropped audio (z1=3272, z2=3252, wanted 8 got 20, dropped 12).
Apr 13 17:51:20 AsteriskFR zaphfc: dropped audio (z1=3463, z2=3443, wanted 8 got 20, dropped 12).
Apr 13 17:51:26 AsteriskFR zaphfc: dropped audio (z1=5890, z2=5866, wanted 8 got 24, dropped 16).
Apr 13 17:51:26 AsteriskFR zaphfc: dropped audio (z1=5989, z2=5965, wanted 8 got 24, dropped 16).
Apr 13 17:51:34 AsteriskFR zaphfc: dropped audio (z1=5032, z2=4998, wanted 8 got 34, dropped 26).
Apr 13 17:51:34 AsteriskFR zaphfc: dropped audio (z1=5090, z2=5069, wanted 8 got 21, dropped 13).
Apr 13 17:51:34 AsteriskFR zaphfc: dropped audio (z1=6371, z2=6345, wanted 8 got 26, dropped 18).
Apr 13 17:51:34 AsteriskFR zaphfc: dropped audio (z1=6522, z2=6501, wanted 8 got 21, dropped 13).
Apr 13 17:51:34 AsteriskFR zaphfc: dropped audio (z1=716, z2=696, wanted 8 got 20, dropped 12).
Apr 13 17:51:34 AsteriskFR zaphfc: dropped audio (z1=976, z2=956, wanted 8 got 20, dropped 12).
Apr 13 17:53:45 AsteriskFR zaphfc: dropped audio (z1=1827, z2=1792, wanted 8 got 35, dropped 27).

Wenn ich nun in zaohfc.c mal zu verstehen versuche was da eigentlich passieren soll, stosse ich bei den "bchan tx fifo full" Fehlermeldungen auf die die Funktion hfc_btrans, die offenbar Daten in den Channel schreiben soll. Bedauerlicherweise ist aber der Puffer voll und das führt zu dieser Fehlermeldung.
Die andere Fehlermeldung "dropped audio" führt zu einer Routine hfc_brec . Freundlicherweise ist die Fehlermeldung hier mit einem Kommentar versehen: "if the system is too slow to handle it, we will have to drop it all [...]". Da fragt man sich nur was um Himmels willen zaphfc hier überhaupt empfangen will. Es hat weder jemand telefoniert noch hat das Telefon geschellt noch ist sonst irgendwas los gewesen.

Kann damit schon irgendjemand etwas anfangen oder kommt das jemandem bekannt vor? Mich würde auch sehr interessieren ob solche Fehlermeldungen auch bei jemandem auftreten wo alles ohne Echo funktioniert. lo4dro, könntest Du mal in Deine /var/log/messages schauen, bitte?

sion schrieb:

Wenn ich Lust & Zeit hätte würde ich das mal unter RTAI testen, habe ich aber beides nicht.

Zum Vergrößern anklicken....

Ach?
Habe ich da was verpasst? Ich dachte die RC7j würde auch schon auf RTAI aufsetzen. Wittere ich da etwa eine Alternative für den Fall, dass RTAI gar nicht installiert ist? Das habe ich nämlich gar nicht ausprobiert, sondern das neue Asterisk (ich habe noch eine ganz alte Version laufen, den Rechner rühr ich aber sicherheitshalber nicht mehr an :roll gleich auf einen anderen Rechner mit frischem 2.6er kernel und RTAI installiert.

sion schrieb:

Dafür habe ich seit ein paar Tagen manchmal ein ziemliches "Gebrutzel" auf der Leitung

Zum Vergrößern anklicken....

Hmm, das hört sich aber auch irgendwie nach verpassten Interrupts an...

fly-a-lot schrieb:

sion schrieb:

Wenn ich Lust & Zeit hätte würde ich das mal unter RTAI testen, habe ich aber beides nicht.

Zum Vergrößern anklicken....

Ach?
Habe ich da was verpasst? Ich dachte die RC7j würde auch schon auf RTAI aufsetzen. Wittere ich da etwa eine Alternative für den Fall, dass RTAI gar nicht installiert ist? Das habe ich nämlich gar nicht ausprobiert, sondern das neue Asterisk (ich habe noch eine ganz alte Version laufen, den Rechner rühr ich aber sicherheitshalber nicht mehr an :roll gleich auf einen anderen Rechner mit frischem 2.6er kernel und RTAI installiert.

sion schrieb:

Dafür habe ich seit ein paar Tagen manchmal ein ziemliches "Gebrutzel" auf der Leitung

Zum Vergrößern anklicken....

Hmm, das hört sich aber auch irgendwie nach verpassten Interrupts an...

Zum Vergrößern anklicken....

Bei der RC7j ist ein RTAI Modul dabei, unter TESTING/realzap. Du mußt dafür zuerst RTAI (bzw. ADEOS) in den Kernel einpatchen, neu compilieren und neu booten. Dann ließt du dir mal die readme-datei zu realzap durch ("If this is the first time you hear about RTAI, it's smart to NOT try using this module. Run!!!") und überlegst dir das vielleicht nochmal. Wenn nicht, dann kannst du ja mal versuchen das Modul zu laden....(vermutlich) genaue Infos siehe http://www.ip-phone-forum.de/forum/viewtopic.php?t=14185. Viel Spaß ;-)

Was mein Gebrutzel angeht: Das kann sehr gut an verpassten Interrupts liegen, da hast du schon recht. Vermutlich hat da gerade meine DVB-Karte was aufgenommen, die steht in der Interrupt-Häufigkeit der HFC in nichts nach...u.U. würde mir RTAI also auch helfen.

Gruß. Sion

Jetzt hast Du mich verwirrt, Sion.

So wie Du es beschreibst, hast Du dann ja adeos/RTAI doch verwendet. Nichts anderes mache ich auch, nur habe ich eine Gentoo-Installation mit Kernel 2.6.10 von kernel.org und das entsprechende rtai-3.2-test3 von rtai.org verwendet. Aber darauf sollte es ja nun wirklich nicht ankommen.

Was meintest Du vorher mit "Wenn ich Lust & Zeit hätte würde ich das mal unter RTAI testen"? Irgendwie habe ich Dich da misverstanden und dachte schon es ginge auch ohne RTAI. Aber das war wohl ein Irrtum.

Übrigens, so eine Konfiguration mit Asterisk und DVB-Karte(n) in einem Gerät hatte ich mir ursprünglich auch einmal vorgestellt. Aber Asterisk erschien mir dann zu instabil für solche Lösungen zu sein. Daher liegt der Plan auf Eis und ich versuche erst einmal mit meinen alten Rechnern die Telefonanlagen zu ersetzen.

Im Moment hadere ich allerdings schon damit, ob zumindest der eine Rechner nicht schon zu alt ist. Aber wenn das auch auf lo4dro's PII-400 läuft müsste mein System das doch auch schaffen können.

Also nochmal: Ich verwende kein RTAI, auch wenn es vielleicht helfen würde.
Wenn du nicht an deinem Kernel rumgespielt hast, dann verwendest du es auch nicht. Vielleicht würde das aber helfen.

Für VoIP + DVB sollte ein P2/400 nicht zu alt sein, beides braucht relativ wenig CPU-Leistung, da die Daten hauptsächlich nur hin- und hergeschoben werden, aber nicht besonders umkodiert (außer, du verwendest komprimierungs-codes bei VoIP). Wenn du aber pech hast, bekommst du beim Aufnehmen (DVB) Knackser ins Telefon (was ja meine Vermutung ist), das ist dann aber unabhängig von deiner verwendeten CPU.

sion schrieb:

Also nochmal: Ich verwende kein RTAI, auch wenn es vielleicht helfen würde.
Wenn du nicht an deinem Kernel rumgespielt hast, dann verwendest du es auch nicht. Vielleicht würde das aber helfen.

Zum Vergrößern anklicken....

Danke für die Klarstellung.

Allerdings ich habe tatsächlich am Kernel "rumgespielt" wie ich vorher schon einmal erwähnt hatte. Ich hatte auf diesem Asterisk-System Gentoo installiert, den vanilla 2.6.10 kernel genommen, Adeos eingepatcht und RTAI hinzukompiliert (Adeos/RTAI gibt es als Paket für diverse Kernel bei rtai.org).

Der für mich erkennbare Vorteil von RTAI liegt in der geringeren Interrupt-Belastung auf dem PCI-Bus. Im Prinzip nutzt Klaus-Peter Junghanns das RTAI als eine Art 1000 Hz Taktgeber. Allerdings ist RTAI ein komplettes "RealTime Application Interface" und sowohl mächtig als auch ordentlich groß. Für die "Taktgeberfunktion" eigentlich fast schon zu mächtig und zu groß.

Mein derzeitiges Rätsel lässt sich vielleicht so zusammenfassen, dass mir nicht wirklich klar ist ob auf meinem System sonst etwas schief läuft oder ob das RTAI in Verbindung mit der immer noch verbleibenden Interrupt-Last etwas zuviel für meinen alten Rechner ist. Es ist übrigens ein Pentium 3 mit 700 MHz. Der P2-400 ist der Rechner von lo4dro.

Die Video-Server Pläne liegen bei mir zur Zeit auf Eis. Mein Hauptproblem liegt im Moment darin, dass ich zwischen mehreren Wohnungen pendele (verschiedene Gründe) und die Telefonanlagen komplett auf Asterisk umstellen und "zusammenschalten" möchte. Der Video-Server ist in meiner Prioritätenliste ordentlich nach unten durchgerutscht. Hatte mal MythTV ins Auge gefasst aber für Fernsehen und Videos habe ich im Moment ohnehin so gut wie keine Zeit.

Aber noch einmal zurück zum zaphfc.
Wie hast Du Bristuff kompiliert ohne RTAI installiert zu haben? Wenn ich das auf einem 2.6.10 System ohne Adeos und RTAI versuche, bricht der Compiler bei zaphfc mit Fehlermeldungen ab.

Habe gerade mal die bristuff-0.2.0-RC7k.tar.gz runtergeladen, entpackt, download.sh ausgeführt und im zaphfc-Unterverzeichnis "make" aufgerufen - und schon wurde das Kernelmodul problemlos compiliert.

Du hast recht, RTAI wird benutzt um einen 1kHz-Takt für den Treiber zu bekommen. Vermutlich werden dann die Karten abgefragt (gepollt), und erzeugen keinen eigenen Interrupt (mit 8kHz) mehr.

Würde mich ehrlichgesagt etwas wundern, wenn das Echo von einem zu langsamen Rechner kommt! Das ist eher Einstellungssache, liegt an dem verwendeten Telefon oder am Telefonanbieter (bei Sipgate bekomme ich auch manchmal Echo, bei freenet soll es noch schlimmer sein).

fly-a-lot schrieb:

@lo4dro:

Oh, Mann!
Danke für die Info! Da scheine ich wohl doch falsch zu liegen wenn Dein kleiner Renner das schafft :gruebel:

Welchen Kernel benutzt Du? RTAI vermutlich passend von www.rtai.org oder?

Zum Vergrößern anklicken....

Hallo.

Dach ich ein gepatchter zaphfc benutze funktionieren die rtai geschichten nicht.
Ich hab deswegen auch ein IRQs 8000 pro Sec.

Ich hab die original Treiber mal mit rtai getestet. Danach hatte ich ein IRQ Last von 1000 pro Sec., allerdings war danach die sprachqualität so schlecht das ich wider zurückgewechselt habe.

Ich hatte mir mal den source code von zaphfc angesehen und bei der Gelegenheit auch mal nachgeschaut wie man zaphfc ohne RTAI kompiliert. Nun, jetzt habe ich es auch hinbekommen. :roll:

Das interessante Ergebnis auf meinem System (PentiumIII-700 MHz):
Das zuvor vorhandene und praktisch nicht zu beseitigende Echo ist zumindest auf meinem nunmehr minimalistischen Testrechner (nur noch eine Karte im TE mode) völlig verschwunden. In der zapata.conf habe ich folgende Einstellungen:
echocancel=yes
echotraining=800
echocancelwhenbridged=yes

Wie gesagt, unter RTAI hatte ich ein enormes Echo, ausserdem zeitlich stark verzögert. Ohne RTAI praktisch gar nichts. Welch ein Unterschied!

Ich bin etwas verwirrt bzgl. der Echo-Konfiguration. Neulich las ich, das Echos bei ISDN nicht auftreten und deshalb das Echocanceling abgestellt werden sollte. Nun schreibt ihr hier, das die Einstellung bei euch einen Sinn macht.
Ist also die erste Aussage falsch?

Manchmal kann es auch das Board sein was die Zaphfc Karte verrückspielen lässt.

Vielleicht hat ja jemand die Probs mit diesen Zaphfc audio dropped .
und dieses hilft vielleicht:

man sollte die IDE schnittstelle von board mit in den Kernel einbauen bzw als modul laden lassen damit das udma aktiviert ist.

ich hatte danach diese Audio dropped nicht mehr.