.titleBar { margin-bottom: 5px!important; }

Neuer (aktueller) Bristuff und EC

Dieses Thema im Forum "Asterisk ISDN mit Bristuff (hfc, zaptel)" wurde erstellt von thorsten.gehrig, 9 März 2005.

  1. thorsten.gehrig

    thorsten.gehrig Mitglied

    Registriert seit:
    14 Juni 2004
    Beiträge:
    490
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  2. sion

    sion Neuer User

    Registriert seit:
    18 Sep. 2004
    Beiträge:
    129
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  3. fly-a-lot

    fly-a-lot Neuer User

    Registriert seit:
    24 Feb. 2005
    Beiträge:
    63
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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.
     
  4. lo4dro

    lo4dro Mitglied

    Registriert seit:
    14 Okt. 2004
    Beiträge:
    656
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    @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.
     
  5. lo4dro

    lo4dro Mitglied

    Registriert seit:
    14 Okt. 2004
    Beiträge:
    656
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    @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.
     
  6. fly-a-lot

    fly-a-lot Neuer User

    Registriert seit:
    24 Feb. 2005
    Beiträge:
    63
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    @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?
     
  7. sion

    sion Neuer User

    Registriert seit:
    18 Sep. 2004
    Beiträge:
    129
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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ß
     
  8. fly-a-lot

    fly-a-lot Neuer User

    Registriert seit:
    24 Feb. 2005
    Beiträge:
    63
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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?
     
  9. fly-a-lot

    fly-a-lot Neuer User

    Registriert seit:
    24 Feb. 2005
    Beiträge:
    63
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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.

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

    sion Neuer User

    Registriert seit:
    18 Sep. 2004
    Beiträge:
    129
    Zustimmungen:
    0
    Punkte für Erfolge:
    0

    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
     
  11. fly-a-lot

    fly-a-lot Neuer User

    Registriert seit:
    24 Feb. 2005
    Beiträge:
    63
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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.
     
  12. sion

    sion Neuer User

    Registriert seit:
    18 Sep. 2004
    Beiträge:
    129
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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.
     
  13. fly-a-lot

    fly-a-lot Neuer User

    Registriert seit:
    24 Feb. 2005
    Beiträge:
    63
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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.
     
  14. sion

    sion Neuer User

    Registriert seit:
    18 Sep. 2004
    Beiträge:
    129
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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).
     
  15. lo4dro

    lo4dro Mitglied

    Registriert seit:
    14 Okt. 2004
    Beiträge:
    656
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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.
     
  16. fly-a-lot

    fly-a-lot Neuer User

    Registriert seit:
    24 Feb. 2005
    Beiträge:
    63
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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!
     
  17. pygmalion

    pygmalion Neuer User

    Registriert seit:
    12 Nov. 2004
    Beiträge:
    56
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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?
     
  18. Starwing

    Starwing Neuer User

    Registriert seit:
    27 Apr. 2005
    Beiträge:
    32
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    IT - Support
    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.