CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

    Hallo zusammen,


    ich hoffe, ich bin im richtigen Thread, falls nicht bitte ich schon mal vorab um Entschuldigung.


    Ich habe mir letzte Woche eine Cine S2 mit Duflex S2 Erweiterung und CI Modul sowie ein Inverto Unicable LNB gekauft. Betrieben wird das ganze in einer unter Xen 4.1 erstellten paravirtuallisierten yavdr 0.5 Installation. Die S2 Karte samt S2 Erweiterung funktioniert unter Einsatz des


    media-build-experimental-dkms 0~20131204.221601-1yavdr1~precise


    einwandfrei.


    Allerdings habe ich das CI Modul noch nicht richtig lauffähig bekommen.



    Das Cam is gemäß der in diesem und anderen Threads vorliegenden Informationen mittels redirect Parameter eingebunden und auch das ddbridge module mit "options ddbridge adapter_alloc=3" geladen.
    Das Cam (Alphacrypt Light v3.23, Sky S02 Karte) werden im vdr Menue angezeigt, aber


    ich bekomme kein Bild auf keinem Kanal


    [edit]
    Ich bekomme jetzt zumindest auf den FTA Kanälen ein Bild, habe den für den reinen S2 Betrieb (ohne CAM) nicht notwendigen Xen Parameter iommu= soft und pci=nomsi beim Start der DomU hinzugefügt. Die Sky Kanäle zeigen aber immer noch kein Bild. Mal abwarten, ob sich die Karte erst noch aktivieren muss.
    [edit]


    Wenn ich das CI Modul (nicht nur das CAM) wieder aus dem Rechner entferne zeigen alle 4 Tuner wieder ein Bild. Hat vielleicht jemand hier eine Idee, was ich falsch mache?


    LG, Oliver

    XEN host: ASRock B450 Pro4, AMD Ryzen 7 3700X 8x , 32 GB DDR4, 1TB Samsung 970 EVO NVMe, 2 x 8TB Seagate Exos (Raid 1), AMD/ATI RV710 [Radeon HD 4350/4550], Debian 12.5, Xen 4.17.3
    VDR DomU:     1 Cores, 2GB Ram, 20GB System LVM, 3.6TB Video LVM, Cine S2 v6.5 + Duoflex S2 v6.5, ubuntu 22.04.5, vdr & plugins by Seahawk1986's PPA
    Client 1: FireTV Stick    , Kodi 19.4, vnsi client
    Client 2:     FireTV Stick 4K, Kodi 19.4, vnsi client
    Client 3:     FireTV Stick 4K, Kodi 19.4, vnsi client

    Einmal editiert, zuletzt von yosamite9999 () aus folgendem Grund: Teilerfolg

    Ich kann derzeit nicht viel helfen, weil ich meinen Bandscheibenvorfall im Urlaub wieder aktiviert habe.
    Du kannst aber hier mal sehen, wie man das Debugging des CI Protokoll Treibers einschalten kann. Da kommt aber recht viel. Ev. musst in den Kernel Sourcen das eine oder andere abdrehen (auskommentieren).
    Mit dem konnte ich eine Ursache meiner CAM Probleme finden.


    Auf der anderen Seite scheint der Kernel und der VDR das CAM aber zu sehen:

    Zitat

    [ 435.975458] dvb_ca adapter 0: DVB CAM detected and initialised successfully


    Das Cam (Alphacrypt Light v3.23, Sky S02 Karte) werden im vdr Menue angezeigt, ...


    Durch das Module Redirect ordnest du einem Tuner das CAM 1:1 zu. Also so, als wäre das CAM auf dem einen Tuner direkt angeschlossen. Der VDR sucht sich die Tuner aber selbst aus. Genau weiß ich nicht wie das geht, aber wenn er einen SKY Channel auf einen Tuner routet der das CAM nicht zugeordnet hat, dann kann des nicht funktionieren. Du könntest mal alle Tuner bis auf einen weg konfigurieren. Der eine hat dann das CAM zugeordnet und dann schau mal ob es geht.


    Was mir noch einfällt ist CI+ . Ich weiß ja nicht ob deine SKY Karte das benutzt. Falls ja, dann wird das alles nicht so einfach, bis unmöglich, zumindest, wenn du dich nicht in rechtliche grau bis schwarz Bereiche begeben möchtest. CI+ ist etwas, dass man boykottieren muss!


    LG
    Jasmin

    Einmal editiert, zuletzt von jasminj ()

    Für den vdr müssen die device-Nummern übereinstimmen, d.h. ca0 muss man mit frontend0 verknüpfen, sonst wird das nichts.


    Lars

    Ich bin ein wenig eingerostet den VDR betreffend. Könntest du Oliver erklären wie man das macht.

    Ich auch. :)


    Oliver, zeig mal bitte

    Code
    ls -la /dev/dvb/*


    damit ich die Devicenummern sehe. Der dmesg-Ausgabe kann man nicht trauen, da ist noch ein kleiner Fehler drin, der die falsche Nummer ausgibt (es können nicht alle adapter 0, frontend 0 sein).


    Lars.


    Hallo Rainer,


    du musst noch für den ddbridge Treiber die Option "ddbridge adapter_alloc=3" aktivieren


    /etc/modprobe.d/ddbridge.conf

    Code
    options ddbridge adapter_alloc=3


    und den redirect Parameter des Treibers nutzen, z.B. so:


    /etc/udev/rules.d# less 80-ddbridge.rules

    Code
    SUBSYSTEM=="dvb", ACTION=="add", KERNEL=="dvb0.ca0", RUN+="/etc/udev/redirect.sh"


    und /etc/udev/redirect.sh

    Bash
    #!/bin/sh


## Der folgende Befehl geht davon aus, das das CAM Modul auf Tab2 der Cine angeschlossen ist
echo "00 02" > /sys/class/ddbridge/ddbridge0/redirect


exit 0


    Nicht vergessen, beide Dateien ausführbar zu machen!


    Nach einem Neustart (nicht reboot) solltest du im dmesg ein redirect 00, 02 finden und das CAM wird auch im VDR OSD angezeigt.


    Viele Grüße


    Oliver

    XEN host: ASRock B450 Pro4, AMD Ryzen 7 3700X 8x , 32 GB DDR4, 1TB Samsung 970 EVO NVMe, 2 x 8TB Seagate Exos (Raid 1), AMD/ATI RV710 [Radeon HD 4350/4550], Debian 12.5, Xen 4.17.3
    VDR DomU:     1 Cores, 2GB Ram, 20GB System LVM, 3.6TB Video LVM, Cine S2 v6.5 + Duoflex S2 v6.5, ubuntu 22.04.5, vdr & plugins by Seahawk1986's PPA
    Client 1: FireTV Stick    , Kodi 19.4, vnsi client
    Client 2:     FireTV Stick 4K, Kodi 19.4, vnsi client
    Client 3:     FireTV Stick 4K, Kodi 19.4, vnsi client

    Hallo,


    entschuldigt, das ich mich erst jetzt melde, war mit meiner Holden ein paar Tage in Berlin.


    Hier die Ausgabe von


    Die Sky Kanäle werden jetzt angezeigt, war wohl ein Problem der Kartenaktivierung.


    jasminj: Bin ganz deiner Meinung, HD+ ist kompl. vera... . Ist auch nicht aktiv!


    Liebe Grüße


    Oliver

    XEN host: ASRock B450 Pro4, AMD Ryzen 7 3700X 8x , 32 GB DDR4, 1TB Samsung 970 EVO NVMe, 2 x 8TB Seagate Exos (Raid 1), AMD/ATI RV710 [Radeon HD 4350/4550], Debian 12.5, Xen 4.17.3
    VDR DomU:     1 Cores, 2GB Ram, 20GB System LVM, 3.6TB Video LVM, Cine S2 v6.5 + Duoflex S2 v6.5, ubuntu 22.04.5, vdr & plugins by Seahawk1986's PPA
    Client 1: FireTV Stick    , Kodi 19.4, vnsi client
    Client 2:     FireTV Stick 4K, Kodi 19.4, vnsi client
    Client 3:     FireTV Stick 4K, Kodi 19.4, vnsi client

    Ja, das einzige, was etwas störend ist, ist die Tatsache, das man den geplanten Aufnahem keinen dedizierten Tuner zuweisen kann. Wenn eine Nicht-Sky Aufnahem läuft ist Tuner 1 belegt und Sky wird nicht mehr dekodiert.


    Ich vermute, dafür gibt es immer noch keine Lösung, oder?


    LG, Oliver

    XEN host: ASRock B450 Pro4, AMD Ryzen 7 3700X 8x , 32 GB DDR4, 1TB Samsung 970 EVO NVMe, 2 x 8TB Seagate Exos (Raid 1), AMD/ATI RV710 [Radeon HD 4350/4550], Debian 12.5, Xen 4.17.3
    VDR DomU:     1 Cores, 2GB Ram, 20GB System LVM, 3.6TB Video LVM, Cine S2 v6.5 + Duoflex S2 v6.5, ubuntu 22.04.5, vdr & plugins by Seahawk1986's PPA
    Client 1: FireTV Stick    , Kodi 19.4, vnsi client
    Client 2:     FireTV Stick 4K, Kodi 19.4, vnsi client
    Client 3:     FireTV Stick 4K, Kodi 19.4, vnsi client

    Das sollte eigentlich nicht so sein. Kannst du mal den Ausschnitt des syslogs vom Start des vdr zeigen, wo er die DVB-Karten und das CI anzeigt? Eigentlich sollte eine FTA-Aufnahme nur einen Tuner ohne CAM belegen.
    Oder hast du ein böses Plugin in Gebrauch?


    Lars

    Hallo mini73,


    kein pöses PI geladen, ganz normal mit Alphcrypt Light und Sky02 Karte im Abo. Hier der Ausschnitt aus dem syslog:



    Wäre ja klasse, wenn der vdr für FTA Aufnahmen immer einen Tuner OHNE assoziiertes CAM nehmen würde.


    LG, Oliver

    XEN host: ASRock B450 Pro4, AMD Ryzen 7 3700X 8x , 32 GB DDR4, 1TB Samsung 970 EVO NVMe, 2 x 8TB Seagate Exos (Raid 1), AMD/ATI RV710 [Radeon HD 4350/4550], Debian 12.5, Xen 4.17.3
    VDR DomU:     1 Cores, 2GB Ram, 20GB System LVM, 3.6TB Video LVM, Cine S2 v6.5 + Duoflex S2 v6.5, ubuntu 22.04.5, vdr & plugins by Seahawk1986's PPA
    Client 1: FireTV Stick    , Kodi 19.4, vnsi client
    Client 2:     FireTV Stick 4K, Kodi 19.4, vnsi client
    Client 3:     FireTV Stick 4K, Kodi 19.4, vnsi client

    Noch eine Frage zu folgender Meldung aus dem syslog:


    Code
    Feb 18 10:46:21 HAM-MM01 vdr: [20926] CAM 1: replies to QUERY - multi channel decryption possible


    Gibt es hierzu etwas neues oder geht das unter Linux weiterhin nicht?


    LG, Oliver

    XEN host: ASRock B450 Pro4, AMD Ryzen 7 3700X 8x , 32 GB DDR4, 1TB Samsung 970 EVO NVMe, 2 x 8TB Seagate Exos (Raid 1), AMD/ATI RV710 [Radeon HD 4350/4550], Debian 12.5, Xen 4.17.3
    VDR DomU:     1 Cores, 2GB Ram, 20GB System LVM, 3.6TB Video LVM, Cine S2 v6.5 + Duoflex S2 v6.5, ubuntu 22.04.5, vdr & plugins by Seahawk1986's PPA
    Client 1: FireTV Stick    , Kodi 19.4, vnsi client
    Client 2:     FireTV Stick 4K, Kodi 19.4, vnsi client
    Client 3:     FireTV Stick 4K, Kodi 19.4, vnsi client

    Das heißt, dass das CAM es kann, mehr nicht.
    Der VDR kann das von sich aus nicht. Mit dem Redirect wird das CI genau einem Tuner zuordnet, als ob es per HW Kabel direkt am Tuner angeschlossen wäre.


    In diesem Thread steht bez. des Multi Channel decodens ja schon einiges. Außerdem wird derzeit daran im Treiber gearbeitet. Der genaue Stand ist mir unbekannt. Ich pers. bin mir auch nicht so sicher, ob das in den Kernel gehört. Der Kernel stellt Schnittstellen für die HW zur Verfügung und das mit dem Redirect war schon eine Notlösung, weil das Kernel Konzept kein allgemeines CI Interface erlaubt hat, sondern nur fix dem Tuner assoziert.
    DD (L4M) hat das erstmals mit ihrer HW ermöglicht. Ich finde das genial, weil dann theoretisch jede SAT Karte das DD CI Interface verwendet könnte. Es müsste eben nur durch das User Mode Programm entsprechend gesteuert werden und das Programm müsste die Videodaten zum CAM schicken.
    Sprich der VDR, oder was immer zum Anzeigen benutzt wird.


    An den Treibern für DD hat sich ja erst im Dezember wieder was getan. Ralph hat ein neues Device dazu gebaut, aber verwendet tut das derzeit keine User Mode Applikation, außer eine Testapp von Ralph.


    Wenn mein 2ter BS-Vorfall wieder besser ist und mein neuer VDR werkelt, dann werde ich mich mal wieder damit beschäftigen. Ev. hat ja Lars (Mini73) einmal Lust sich das im VDR anzusehen. Es gibt ja Hinweise von Klaus, dass das ddci Plugin so nicht nötig wäre, weil der VDR das anders könne. Immerhin ist ja VDR 2.x um einiges erweitert worden und ddci ist noch auf Basis VDR 1.x gebaut worden.


    LG
    Jasmin

    Ja, vdr 2.1.4 bietet da eine erweiterte Schnittstelle für Plugin-CIs, hab da auch schon mal reingesehen, allerdings noch nichts zustande gebracht.


    Das hier ist die Stelle im vdr 2.0.3, der das Device raussucht, das für eine Aufnahme bzw. Live-TV benutzt wird. Da müsste man sonst mal Logmeldungen reinstreuen, damit man herausfindet, warum der vdr sich für welches Device entscheidet.


    Lars.

    Hallo mini73,


    ich gebe dir Recht, nach dem Code (bin kein Programmierer) sieht es so aus, als würde er mit CAM versehene Interfaces nicht für FTA Aufnahmen nutzen.
    Ich werde das mal weiter testen und dann berichten.


    LG, Oliver

    XEN host: ASRock B450 Pro4, AMD Ryzen 7 3700X 8x , 32 GB DDR4, 1TB Samsung 970 EVO NVMe, 2 x 8TB Seagate Exos (Raid 1), AMD/ATI RV710 [Radeon HD 4350/4550], Debian 12.5, Xen 4.17.3
    VDR DomU:     1 Cores, 2GB Ram, 20GB System LVM, 3.6TB Video LVM, Cine S2 v6.5 + Duoflex S2 v6.5, ubuntu 22.04.5, vdr & plugins by Seahawk1986's PPA
    Client 1: FireTV Stick    , Kodi 19.4, vnsi client
    Client 2:     FireTV Stick 4K, Kodi 19.4, vnsi client
    Client 3:     FireTV Stick 4K, Kodi 19.4, vnsi client

    Hallo jasminj,


    Danke für deine Ausführungen, ich hatte nur die neueren Threads zum Thema MCD (noch) nicht gelesen, daher die Frage.


    Es sit ja schön zu hören, das der aktuelle vdr eine erweiterte Schnittstelle bereitstellt. Alle vier Tuner der Cine durch ein CAM decrypten zu können wäre einfach genial. Ich drücke die Daumen und bin auch gerne bereit, zu testen, wenn das hilft.


    Noch einen Hinweis an den/die Weiterentwickler des Treibers. Das aktulle GIT von ufo erzeugt auf einer unter Xen 4.1 laufenden vollvirtuallisierten yavdr 0.5 Installation I2C Fehler. Der ddbridge Treiber ließ/läßt sich dort nicht in Funktion bringen (habe ich auch an DD gemeldet, die waren jedoch relativ ratlos).


    LG, Oliver

    XEN host: ASRock B450 Pro4, AMD Ryzen 7 3700X 8x , 32 GB DDR4, 1TB Samsung 970 EVO NVMe, 2 x 8TB Seagate Exos (Raid 1), AMD/ATI RV710 [Radeon HD 4350/4550], Debian 12.5, Xen 4.17.3
    VDR DomU:     1 Cores, 2GB Ram, 20GB System LVM, 3.6TB Video LVM, Cine S2 v6.5 + Duoflex S2 v6.5, ubuntu 22.04.5, vdr & plugins by Seahawk1986's PPA
    Client 1: FireTV Stick    , Kodi 19.4, vnsi client
    Client 2:     FireTV Stick 4K, Kodi 19.4, vnsi client
    Client 3:     FireTV Stick 4K, Kodi 19.4, vnsi client

    Zitat von jasminj

    Außerdem wird derzeit daran im Treiber gearbeitet. Der genaue Stand ist mir unbekannt.

    Das hat sich als nicht richtig erwiesen. Gehört da ja auch nicht rein ;)


    Zitat von jasminj

    DD (L4M) hat das erstmals mit ihrer HW ermöglicht. Ich finde das genial, weil dann theoretisch jede SAT Karte das DD CI Interface verwendet könnte. Es müsste eben nur durch das User Mode Programm entsprechend gesteuert werden und das Programm müsste die Videodaten zum CAM schicken.
    Sprich der VDR, oder was immer zum Anzeigen benutzt wird.

    Ich hab da mal eine neue Version des ddci Plugins gebaut (ddci2). Das funktioniert auch schon mal ganz gut mit dem Tuner von DD, allerdings natürlich ohne dem Redirect im Treiber, weil das jetzt das Plugin übernimmt. Damit kann das DD CI jetzt von jedem beliebigen Tuner verwendet werden 8) :tup .


    Das Projekt ist hier zu erreichen: https://github.com/jasmin-j/vdr-plugin-ddci2
    Aber Achtung, dass ich Alpha SW!!!
    Ich habe nur einige wenige Tests damit gemacht. Auf der anderen Seite ist das alles aber nicht sehr schwierig, sieht man mal von den Dingen ab, die nirgends stehen und die man sich mit Debugausgaben selbst zusammen suchen muss. Außerdem hab ich ja noch nicht viel Ahnung von PIDs und PMTs ?(


    Das Plugin funktioniert NUR mit VDR Version 2.1.6. Zumindest habe ich diese zum Entwickeln benutzt. Wie man es compiliert und auf was man achten muss steht im README File (man muss ein VDR Header File derzeit noch patchen).
    Ich würde jetzt einige Tester brauchen, die das Plugin mit anderen Karten zusammen testen. Wie oben schon beschrieben, sollte damit das DD-CI mit jedem anderen Tuner zusammen arbeiten können. Also auch mit Karten die gar keine CI Schnittstelle vorgesehen oder angeschlossen haben.
    Ich habe auch noch keinen Test mit einem DD Octopus Twin CI gemacht. Das Plugin sollte dann jedem Tuner ein CI zuordnen.


    Wichtig ist den Redirect Modus des Treibers nicht zu verwenden. Außerdem muss man den Modul Parameter "adapter_alloc" für ddbridge entfernen, oder zumindest auf 1 oder 2 setzen. 3 darf nicht verwendet werden, weil sonst der VDR das caX Device sieht und es dem jeweiligen frontendX zuordnet und mein Plugin kann das caX Device nicht mehr öffnen. Das PLugin geht das neue ciX Device suchen und erstellt für jedes gefundene Device einen CI Adapter für den VDR. Genauer ordnet es jedem gefundenen Tuner Device einen CI Adapter zu. Das heißt auch, dass dieses Plugin derzeit nicht MTD unterstützt und auch nicht mit dem Dynamite Plugin gemeinsam verwendet werden kann (denke ich), weil das ja den VDR viele Devices vorspielt. Wobei ... eigentlich müsste mein Plugin die CI Adapter den Devices in der VDR Reihenfolge zuordnen ... bitte ausprobieren.


    Ich habe vor das Plugin um die MTD Fähigkeit zu erweitern. Allerdings bedarf das entweder einer umständlichen "Außen Herum" Implementierung, alla DvbApi, welches für jedes Device einen CI Adapter erzeugt, oder ich kann dem VDR die 1:1 Zuordnung von CAM und Device in den Basisklassen abgewöhnen. Ich muss mir das aber alles noch im VDR genauer ansehen. Und ja, auch mit Klaus besprechen.


    Das Plugin versteht sich als erster Schritt und bringt zumindest mal für Karten ohne CI die Möglichkeit das DD CI zu verwenden.
    Außerdem wäre ich über ein Review der SW dankbar. Falls das jemand machen möchte, also besonders mein Engleutsch in Englisch übersetzen und natürlich auch Hinweise, was im Code zu verbessern wäre. Dann entweder per eMail (Adresse steht im README), oder das Repository clonen und mir Pull Requests schicken. Danke schon mal im Voraus :O .


    LG
    Jasmin

    Moin!


    Das Plugin läuft hier mit einem DD-Dual-CI mit nur einem AC Light und 2 C/T-Flex-Modulen.


    Allerdings ist die Load noch ziemlich hoch, beide CPU-Kerne arbeiten am Limit, was vermutlich am Schreiben/Lesen von 188 Byte-Blöcken liegt. Ich versuche, durch den Code durchzusteigen, aber die vielen read-receive-send-deliver-Buffer verwirren mich noch ein wenig... :)


    Lars.

    Zitat von mini73

    Allerdings ist die Load noch ziemlich hoch, beide CPU-Kerne arbeiten am Limit, was vermutlich am Schreiben/Lesen von 188 Byte-Blöcken liegt.

    Das glaub ich nicht, weil ich genau deshalb so viel wie geht in das ciX Device schreibe und auch lese. Also wirklich große vielfache von 188 Byte. Ich habe da 126xxx bei meinen Tests gesehen.


    Zitat von mini73

    Ich versuche, durch den Code durchzusteigen, aber die vielen read-receive-send-deliver-Buffer verwirren mich noch ein wenig... :)

    Es gibt einen Sendebuffer in der Klasse DdCiTsSend. Das ist auch zugleich ein Thread, der in das ciX Device schreibt (DdCiTsSend::Action) und zwar so viel wie geht (vielfache von 188 Byte). Die DdCiCamSlot Klasse kennt den Sendebuffer und schreibt pro Decrypt Aufruf immer 188 Byte in den Sende-Ringbuffer. Das muss ich so machen, weil wenn man da alles was man in der Decrypt Funktion bekommt reinschreibt, dann geht es nicht.
    Die Klasse DdCiTsRecv ist der Receive Thread und enthält den DdCiReadBuf. Das ist der, der derzeit in vielfachen von 188 Byte vom ciX Device liest. DdCiTsRecvDeliver kennt den DdCiReadBuf und ist der Thread, der die Daten zum DdCiCamSlot bringt. Das musste ich in 2 Threads aufteilen, weil der Receive Thread auf das ciX Device warten kann und dann keiner die schon empfangenen TS Packerln weiter schaufelt. Im Übrigen kann der Deliver Thread auch stecken bleiben, wenn der Receive Buffer in DdCiCamSlot voll ist.
    Der CamSlot wiederum enthält den DdCiRecvBuf. Das ist deshalb so, weil die Decrypt Funktion vom Device Thread für jedes TS Packerl aufgerufen wird und immer eines (188 Byte) zurück gibt. Außerdem ist dieses Design für MTD vorbereitet, weil da im DdCiCamSlot noch für jedes Device ein Receive Buffer kommen wird.


    Wenn man das zusammen zählt, dann wird in Senderichtung jedes Packerl in den Sendebuffer kopiert und dann von dort in den Kernel. Das macht mal 2 Kopiervorgänge.
    In der anderen Richtung wird es vom Kernel in den Receivebuffer kopiert und von dort in den 2ten Receivebuffer im CamSlot und dann in der Decrypt Funktion weiter zum VDR, der das sicher wieder kopiert. Macht in Summe also 3 Kopiervorgänge. Wenn man für diese Richtung keine Ringbuffer verwendet, sondern etwas intelligenteres, dann könnte man sich ev. einmal kopieren sparen. Allerdings darf man auch nicht 188 Byte-Weise vom ciX Device lesen, somit ein Pool (Array) zum allocieren von 188 Byte Blöcken ausscheidet. Ich weiß auch nicht ob das Einsparen eines Kopiervorgangs so viel bringt. Man müsst den Code mal mit Messpunkten versehen und schauen, wo die CPU Zeit wirklich vergeht.
    Wenn man das ganz Clever machen möchte, dann müsste man das auf ein Zero-Copy Design (ich kenn das unter dem Namen) ändern. Das ist aber im VDR nicht so implementiert und geht auch gar nicht so einfach, weil man ja nicht nur immer 188 Bytes aus dem frontendX Device liest, sondern auch so viel wie die Buffer hergeben. Somit muss man aus dem Buffer dann sequentiell rausholen und damit arbeiten und wenn man es länger aufheben will, wieder in einen andern Buffer kopieren. Man könnte so etwas aber sehr wohl innerhalb des ddci Plugins realisieren, denke ich. Ich muss mir halt nur den Kopf noch ein wenig mehr zerbrechen.
    Ev. kann man sich einiges sparen, wenn man die Kernel Schnittstelle anders implementieren würde. Dann würden die Send- und Receivebuffer direkt in den Kernel übergeben werden. Das Verfahren heißt mmap. Nachdem das aber nicht mal für das frontendX Device so gemacht wird, brauchen wir es jetzt beim ciX Device auch nicht so implementieren, denke ich.


    LG
    Jasmin

    Zitat von mini73

    Allerdings ist die Load noch ziemlich hoch, beide CPU-Kerne arbeiten am Limit, ...

    Ich hab es gefunden :D ! Neue Version (0.0.10) ist im Git.
    Der Deliver Thread hat jeden Frame sofort zugestellt, wenn was vom ciX Device nachgekommen ist, weil ich kein Get Timeout für den Buffer in DdCiReadBuf definiert habe. Wenn man so ein Timeout definiert, dann ist der RingBuffers so "nett" und stößt einen wartenden Thread erst an, wenn wieder 10% im Buffer sind. Was das Problem aber nicht löst, wenn mal ein großer Schwung vom ciX Device kommt. Das muss aber die Praxis zeigen. Wenn eine CPU so schwach ist, dass sie dann 100kByte auf einmal nicht weiter schieben kann, dann sollte man sie eben tauschen, wenn man dieses Plugin verwenden will. Man muss eben die Frames zum CAM schaufeln und wieder holen und mehr als das in großen Blöcken zu tun, geht nicht.
    Wenn dann MTD geht, dann werden das auch mehr Daten / Sekunde werden. Ev. kann dann eine Verbesserung in der Buffer Struktur (siehe voriger Post) etwas verbessern.


    Ich werde im Treiber übrigens auch was ändern, damit ich die ReadChunk Funktion nicht mehr brauche, somit Read verwenden kann und der Patch im VDR überflüsig wird. Der Treiber will nämlich die Daten in 188 Byte Blöcken haben, was gar nicht notwendig wäre, weil das der DMA Zugriff schon berücksichtigt, somit man auch Byteweise vom DMA Buffer lesen könnte, was Read dann macht, wenn der Schreibzeiger sich dem Buffer Ende nähert und nur noch weniger als 188 Byte frei sind.
    Bei mir läuft der Treiber auch schon so, ich muss den Patch nur zuerst von Ralph reviewen lassen.


    LG
    Jasmin

    Einmal editiert, zuletzt von jasminj ()

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden