HE und EL I mit EL II

[fesix]

Hallo Leute

Endlich habe ich nun meinen hauptptojektor und zwei Sats fertig umgebaut
Musste natürlich gleich mal Showgeguckt werden

An dem Haupt hab ich eine EasyLase II und an meinen Sats eine EasyLase I OEM, wo das Signal durchgeschlleift und gespiegelt wird.

Jetzt habe ich bemerkt, dass je nach Pubnktzahl der Frames die Ausgabe auf den Sats immer flüssig läuft, aber bei vielen Punkten die Ausgabe auf dem haupt anfängt zu stottern, also der EL interne Framespeicher zum Tragen kommt

Kennt jemand as Problem?

Eiegntlich sollte s ja so sein, dass die Ausgabe auf der EL II flüssiger sein soll und generell besser, aber da hab ich eher das Gefühl, dass die EL I ihren Job besser macht...

Gruß

Felix

[die-zunge]

Hi
Mit was für einem PC, und USB1.1 oder 2?
Grüßle
Uwe

[fesix]

Der PC ist ein Quadcore (weiß nich genau wie viel, aber schnell) mit 3GB Ram auf Win XP. USB ist (natürlich) 2.0, also eine recht guet Kiste.

Ich dachte erst, dass es an meinem alten PC liegt, der schon ein wenig langsamer ist, aber bei dem neuen meiner Mutter das gleiche problem.

[gento]

So weit mir bekannt bindet /bastet Erich gerade mit der neuen jmlaser.dll rum.
Ich gehe dann davon aus das die Ausgabe dann besser wird.
Also wait ....

Gento

[tschosef]

hai hai..

die umgebastelte vesion kommt bald... aber ich kann evtl keine hoffnung machen:

Aktuell (mit der mir aktuell vorliegenden dll) stelle ich ein "Delay" bei der EL II fest. Darüber hab ich auch schon mal mit Afrob / Jojo gesprochen.

es ist wohl so, dass zwecks besserer "performance" (höhere mögliche pps zahl der EL II) eine Art Buffer eingebaut wurde (in der DLL oder in der firmware der EL II bin mir nicht sicher wo genau) was wohl zu einem Delay führt.

Wenn ich eine Ausgabe auf 3 verschiedene Karten mache (lumax, netlase, EL II, einfach ein Quadrat auf allen 3 Projektoren, das im Sekundentakt an und aus geht) dann sieht man dieses Delay bei der EL II ganz deutlich. (ich hatte dazu auch ein Video... habs aber schon vom Server genommen).. bei Netlase und Lumax sieht man auf den ersten blick keinen unterschied.

Fazit also derzeit: Mischbetrieb verschiedener karten ist wohl etwas unschön! Es wurde aber Besserung versprochen, evtl auf kosten der max pps zahl der ELII, was aber für die meisten hier keine große rolle spielen dürfte, oder scannt jemant mit 100 000 pps?

dieses verhalten hängt wohl auch etwas mit der Punktzahl zusammen, wobei ich den zusammenhang nicht mehr komplett im kopf habe, da müsst ich afrob nochmal fragen. Dieses Verhalten habe ich mit der alten he-ls version (Netlase aufrufe der dll) und auch mit der zukünftigen Version (jmlaser Aufrufe der dll) feßtgestellt!
Währe interessant ob dieses Verhalten auch andere "mehr karten mischbetrieb nutzer" so verifizieren können (gento??)

Viele Grüße derweil
Erich

[adminoli]

Hi,

wenn das Delay gleichmässig ist, könnte man sich doch so behelfen, dass in den Settings für jede Karte ein Delay in Millisekunden eizugeben ist um damit die Syncronität der Karten untereinander zu erreichen. Natürlich muss das Delay auch auf die Soundwiedergabe wirken, so dass dann hier das größte Delay für eine der Karten den Sound dementsprechend Zeit versetzt und die langsamste Karte ihren Frame sofort bekommt und schnellere Karten den Delays entsprechend später.

Gruß
Oliver

[jojo]

Technisch gesehen ist die ELII eigentlich die "bessere" Karte.
Es kommt aber bei Softwareimplementierung hin und wieder zu Problemen, weil sich die Karten nicht zu 100% exakt gleich verhalten. Das Timing ist etwas unterschiedlich, weshalb man ein paar Dinge beachten muss, die evtl. bei der alten EasyLase nicht so relevant waren.
Ob das von Fesix genannte "Stottern" damit zu tun tun hat, kann ich noch nicht sagen.
Ich muss das mal selber anschauen.
Bei großen Frames dürfte das eigentlich eher nicht passieren.
Problematischer wird es eigentlich bei kleinen Frames, weil hier durch die kurzen Framedauern (50 Punkte bei 50Kpps = 1000 Frames pro Sekunde) die Anzahl der Frames extrem ansteigt. Das würde den Datendurchsatz extrem erhöhen und auch die Rechnerbelastung unnötig ansteigen lassen. 1000 Frames pro Sekunde kann kein Mensch mehr differenzieren.
Daher ist in der DLL eine Art "Bremse" eingebaut, d.h. sehr kleine Frames werden zu einem größeren Frame wiederholt. Diese Framegröße ist momentan noch fest, was den Effekt im Zusammenspiel mit anderen Karten hervorrufen könnte.
Wir werden das evtl. noch anders versuchen.
Erstmal muss ich aber schauen, ob das wirklich der von Fesix genannte Effekt ist.

Ein andere möglicher Effekt (das ist auch Lennart mit LDS 2010 passiert) könnte sein, dass der Ready/Busy Status zu schnell, also quasi in einer Endlosschleife abgefragt wird. Auch dadurch ist die CPU-Last extrem angestiegen und die Karte hatte angefangen zu stottern bzw. der Rechner einzufrieren. Die Mechanismen der EasyLase 1 und II unterschieden sich da etwas.
Man muss bei der Abfrage Ready/Busy einen Sleep von ein paar Millisekunden einbauen, wenn die Karte Busy ist.
Vielleicht vergleicht mal jemand die CPU-Last bei HE nur mit einer EasyLase II und im Gegenzug nur mit einer EL1, NetLase oder Lumax.
Erich, wir klären das.

Gruß

Joachim

[afrob]

Jetzt habe ich bemerkt, dass je nach Pubnktzahl der Frames die Ausgabe auf den Sats immer flüssig läuft, aber bei vielen Punkten die Ausgabe auf dem haupt anfängt zu stottern, also der EL interne Framespeicher zum Tragen kommt

Ich nehme an das, wenn nur eine Karte verwendet wird, diese ohne stottern läuft? Wird eventuell die selbe Spur an mehrere Karten ausgegeben?

Ich würde folgende Ursache vermuten:
Die EasyLase II arbeitet sehr exakt mit der eingestellen PPS-Rate.
Die EasyLase I ist ungenauer; es wird nicht jede PPS-Rate genau getroffen. Die Karte läuft meist etwas langsamer als der eingestellte PPS-Wert.

Wenn die Software nun an beide Karten ausgibt und auf beide Karten wartet bestimmt die langsamere Karte die Framerate (=EasyLase I).
Dadurch wird aber die schnellere Karte(=EL II) nicht mit neuen Frames bedient und beginnt Frames zu wiederholen. Bei grossen Frames führt
das zum Stottern der Ausgabe.

Ich habe leider keine Ahnung wie HE-Laserscan die Ausgabekarten bedient und ob das hier zutrifft.

Grüsse,
afrob

[gento]

Sollte es nicht so sein das jede 'Ausgabespur' selbständig in der Timeline berechnet wird und unabhängig voneinander fortschreitet aber syncron bleibt !

Oder berechnet Erich etwa in festen Schritten/Zeitraster die dann recht groß sind ?
Wenn letzes zutreffend ist , sollte die Ausgabehardware schon ähnliche Güte haben.

Gento

[gento]

Nachtag !
Ich gehe folgend vor:
1) Alle 5 mSek Anfrage an Karte ,kannste neuen Frame gebrauchen.(Das kostet keine 1% Last)
2) Wenn Ja ,wo stehe ich in der Timeline , dann berechne mal schnell und reiche rüber.

So würden alle Karten ausreichend versorgt und flüssig laufen.
Ständig berechnen und dann anfragen kannste ,kostet nur CPU.

Wie man was in seiner Software macht ist eine Frage der Programierphilosophie , was die Programiersoftware biete und wie gute die Ausgabedll (incl Framebuffer) ist.

Gento

[tschosef]

hai hai....

Nachtag !
Ich gehe folgend vor:
1) Alle 5 mSek Anfrage an Karte ,kannste neuen Frame gebrauchen.(Das kostet keine 1% Last)
2) Wenn Ja ,wo stehe ich in der Timeline , dann berechne mal schnell und reiche rüber.

ich mach es anders (bzw HE-LS)

1) Frage: Welche Songzeit haben wir grad
2) setze alle Figuren und wende die effekte darauf an (je nach aktueller zeit)
3) Schleife für jede karte 1 bis n
4) Optimiere frame, und wende Farb und Geometriekorrektur an
5) Frage karte n "Bist du bereit für einen Frame?"
6) Wenn 5. = JA dann sende Frame an karte
7) Wenn 5. = NEIN dann schmeiß den Frame der karte weg (was nützt es, jetzt zu warten und dann lauter veraltete Frames zu schicken?)
8 ) Ende Schleife Nächste Karte (also wieder zu punk 3)
9) Gehe zu 1. für nächsten "Song Zeitpunkt"

ist das die gewünschte antwort die ihr haben wollt?

die "tücke" bei 5.6.7 ist natürlich blöde... a) führt das dazu, dass der Rechner immer volle kanne zu tun hat, selbst wenn der frame dann müll ist, b) rechnet die software unnötiges zeug.... ABER was nützt es zu warten bis die karte nen frame vertragen kann.. der ist dann ja definitiev "schon nicht mehr aktuell" und es müsste eigentlich ein anderer gesendet werden. c) das "Prinzip" ein Delay, ein zu bauen, um alle karten die "flotter" sind aus zu bremsen gefällt mir nicht so sehr..... aber wenns nicht anders ginge.... "wie" ich das dann in die oben genannte struktur einbaue ist eh noch fraglich. Ich hatte eigentlich beim proggen eh erwartet dass man eine art "Reihenfolge effekt" entdecken würde.. sprich dasss man sieht wie eine karte nach der anderen ihren frame bekommt... das is aber nicht der fall, es geht "schnell genug" um nicht auf zu fallen. Selbst wenn ich die EL II als "erste karte" wähle... kommt sie als letztes mit der tatsächlichen Ausgabe kleiner frames daher...

viele Grüße derweil
Erich

[gento]

Sobesehen , durch den Rechenpower z.Z und kommend noch mehr.

Sollten Gute Ausgabedll's selbständig intern 1 Frame Ausgabebuffer anlegen.
Falls das die Hardware das nicht schon hat , wie z.T JoJo's 'Kram'.

Dann braucht sich die Lasersoftware nicht unnütz totrechen und viel verwerfen.

lg Gento

[afrob]

So eine Ausgabekarte ist wie ein Fass, das man oben mit Eimerweise mit Wasser (Frames) befüllt und wo unten das Wasser kontinuierlich herausläuft.

Damit unten Wasser kontinuierlich herauslaufen kann darf das Fass nicht leer sein. Es müssen oben also hin und wieder neue Eimer mit Wasser eingefüllt werden.
Es gibt da verschiedene Herangehensweisen:
-Immer erst einen Eimer nachfüllen wenn gerade der letzte Tropfen aus dem Fass läuft.
Wenn das aber mal einen Moment zu spät geschieht, ist das Fass leer und unten kam kein Wasser mehr heraus.
-Immer dann einen Eimer nachfüllen, wenn der Füllstand das Fasses geringer ist als der Inhalt eines Eimers.
-Immer einen Eimer Wasser in das Fass Füllen, egal ob es voll ist oder nicht.
Wenn es voll ist wird das Wasser aber überlaufen und nie unten aus dem Fass kommen. Alternativ kann man
das Wasser auch neben das Fass kippen, wenn es voll ist.

Wichtig auch:
Wenn das Fass nicht leer ist, kommt das Wasser, das ich oben hinein schütte, nicht sofort unten heraus.

Die Ausgabekarten mit doppelter Pufferung signalisieren wenn einer der beiden Puffer frei ist. Das Frame was dann geschrieben wird, wird aber nur dann sofort ausgegeben, wenn der Puffer leer ist. Sonst wird das Frame im anderen Puffer erst vollständig ausgegeben, bis das neue Frame ausgegeben wird. Wenn die Karte schnell genug bedient wird ist das sogar der Normalfall.
Prinzipbedingt gibt es also immer eine Verzögerung zwischen Berechnung und Ausgabe eines Frames.

Grüsse,
afrob

[gento]

<Prinzipbedingt gibt es also immer eine Verzögerung zwischen Berechnung und Ausgabe eines Frames.>

Technisch sicher , egal ob mit Framebuffer per Hardware oder Software.

Aber egal wie , 20-50 mSek Zeitversatz läst sich im Gegensatz zu Framelöchern nicht wirklich wahrnehem.

lg Gento

[tschosef]

Prinzipbedingt gibt es also immer eine Verzögerung zwischen Berechnung und Ausgabe eines Frames.

jou... stimmt schon... blöd is nur, wenn die Verzögerung bei unterschiedlichen karten stark unterschiedlich ist.
die "zu erwartende Verzögerung" ist ja in etwa (1000 ms / pps ) * Punktzahl der Frames.

bei ner "normalen nicht flackernden show" die mit 30 k gescannt wird... also mindestens 15 frames die sekunde hat, sind das höchstens 66 ms pro frame... also knapp 2000 punkte (dann flackerts aber eben schon mit 15 hz...)
das sind extremalwerte !!!! ein "typischer Frame" ist sicherlich meistens kürzer als 66ms... gento hat schon recht... das "sieht" man kaum....

wenn aber natürlich eine karte dann wegen noch mehr buffer etwas mehr hinhterher hinkt, dann sieht man es nun mal.

Viele Grüße derweil
Erich