[atmocontroller] Betrieb unter Windows

Naja ist nicht so schlimm, wenn es nicht mit verschiedenen Einstellung geht, würde mich trotzdem riesig freuen, wenn du es überhaupt einbaust, das man 2 oder sogar 3 Atmo-Platinen betreiben kann.

Ok - ich könnte es dann so einbauen - das es einen virtuelle AtmoAdapter gibt der 2-3 -- der Quatroplatinen ansteuern kann - damit könnte man dann also 8 bzw. 12 Zonen realisieren.

Platine 1: Zone 0..3
Platine 2: Zone 4..7
Platine 3: Zone 8..11

recht so?

Igor

jo, das wäre super, kann kaums erwarten dies zu testen.

tomekcp
ok - in der nächste Beta von der 0.45 dürfte ich sowas dabei haben,
ist ja nicht weiter schwierig - dafür noch einen Adapter zu schreiben.

Das einzige Problem was ich noch sehe ist - die Latenz - d.h. wenn ich z.B. 4 Serielle Schnittstelle der Reihe nach mit jeweils 4 Atmo Kanälen bedienen muss - wird diese ja der Reihe nach geschehen ... ob man da evtl. einen Zeitversatz sieht?? -- wir reden hier sicherlich von 2 stelligen ms Versatz??
(hilft wohl nur das gute alte Programmierermotto versuch macht kluch)

Ok - und hiermit gebe ich auch gleich mal noch bekannt - dass auf meinem Server die nächste Beta der 0.45 Multi Zone Version bereitliegt.

- die GUI wurde erweitert

- die Konfiguration der Hardware / Schnittstelle ausgelagert - d.h. jede Hardware kann jetzt seinen eigene Schnittstellendialog mitbringen - was die ganze Sache besser anpasspar machen dürfte.

- das DMX Device bietet jetzt die Möglichkeit den Basiskanal direkt einzustellen
- sowie festzulegen wieviel ATMO Kanäle ab diesem gebildet werden sollen.

- die CPU Last düfte ein wenig geringer geworden sein

- der Dialog für das Kanalmapping ist fertig d.h. nicht länger auf 5 Kanäle / Zonen fixiert.

- das Nachladen der Zonendefinition aus Bitmapdateien erfolgt nun auch Wahlweise - in Abhängigkeit von der verwendeten Hardware / und oder dem Zonenlayout - die Vorgabeordner werden dabei automatisch angelegt. Die Bitmaps heißen wie gehabt Zone_%d.bmp - könne aber auch in jeder ebene der automatisch angelegt Ordnerstruktur abgelegt werden. Je nachdem wie global man diese halt verwenden möchte.
Es gilt z.B. für den Fall des Dummy devices mit einer 4x2x4 Konfiguration wird die Bitmaps in folgenden Ordnern gesucht:

.\AtmoWin\Dummy\4x2x4\
.\AtmoWin\Dummy\
.\AtmoWin\

(4x2x4 bedeutet oben vier Zonen, je zwei Zonen links und rechts, und vier Zonen unten.)

Die Spasseffekte / Colorchanges müssen noch angepaßt werden, das ist der nächste Schritt auf meiner Liste.

http://eldo.gotdns.com/atmowin/atmoWin_0.45.zip
http://eldo.gotdns.com/atmowin/atmoWin_0.45_source.zip

(sowie auf meinen unten angeben locations)

Igor

Zitat

Original von Igor
Das einzige Problem was ich noch sehe ist - die Latenz - d.h. wenn ich z.B. 4 Serielle Schnittstelle der Reihe nach mit jeweils 4 Atmo Kanälen bedienen muss - wird diese ja der Reihe nach geschehen ... ob man da evtl. einen Zeitversatz sieht?? -- wir reden hier sicherlich von 2 stelligen ms Versatz??

Das sollte kein Problem sein. Wenn Du per WriteFile() (oder wie auch immer) die Daten an den UART-Treiber sendest, puffert der Treiber diese und schiebt sie per Interrupt nach draußen. Da WriteFile() nur in den Puffer schreibt, sollten mehrere parallele UART's nahezu zeitgleich die Daten rausschieben. Probleme könnte es geben, wenn die UART's mit FILE_FLAG_WRITE_THROUGH geöffnet werden (wenn das überhaupt geht).

Gruß
e9hack

e9hack
- hab nochmal im SDK nachgelesen - müsstest eigentlich Recht haben. Das die Daten nur im FIFO Buffer landen und die WriteFile Funktion danach sofort zurückkehrt - und somit der zeitlich versatz zwischen den Controllern kaum spürbar / sichtbar sein dürfte.

Igor

Zitat

Original von Igor
und somit der zeitlich versatz zwischen den Controllern kaum spürbar / sichtbar sein dürfte.

Wenn es darum geht, welcher zeitlicher Versatz sichtbar sein könnte, mein Toshiba LCD-TV verzögert das Bildsignal um ca. 100ms. Mit dem Aurora-Plugin sind harte Übergänge (z.B. weiß nach schwarz) als Unterschied zwischen LED-Beleuchtung und TV-Bild sichtbar. Ich habe da eine Verzögerung ins Aurora-Plugin eingebaut. Ich würde mal behaupten, 40ms Differenz sind nicht wahrnehmbar, 80ms sind wahrnehmbar und 120ms sind deutlich sichtbar.

Gruß
e9hack

und gibt es schon ergebnisse??? (mehrere Platinen steuern)

So wo ich jetzt "meinen" Thread wieder für mich habe *g* - erstmal die Sachen nachreichen, welche jetzt leider mit im anderen Thread verschwunden sind.

tomekcp
ja - ist in der 0.45 Testversion schon drin - als "Multi-Atmo"

e9hack
die neue Version hat einen einstellbaren Delay zwischen Capture und Ausgabe - dazu habe ich zwischen das InputDevice - und die eigentliche Berechnung ne Warteschlage gebaut - aus welcher die Ausgabe die Frames holt... somit kann man sich nen fast beliebig hohe Delay einbauen...

slime
ich hoffe die Implementierung des Protokolls in meiner neusten 0.45 von jetzt eben - hat das Protokoll von dir richtig verstanden?
Das Device habe ich Mangels eines Namens - weniger hübsch "Slime-Device" getauft - wenns dir nicht gefällt einfach mal nen Namen nennen.

So die neuste Version der 0.45 wie gehabt ...

http://eldo.gotdns.com/atmowin/atmoWin_0.45.zip
http://eldo.gotdns.com/atmowin/atmoWin_0.45_source.zip

und auf den unten angegeben URL's

Igor

Zitat

Original von Igor
slime
ich hoffe die Implementierung des Protokolls in meiner neusten 0.45 von jetzt eben - hat das Protokoll von dir richtig verstanden?
Das Device habe ich Mangels eines Namens - weniger hübsch "Slime-Device" getauft - wenns dir nicht gefällt einfach mal nen Namen nennen.

der korrekte namen wäre "mondolight"
die chips habe ich mittlerweile auch zuhause, PCB wird die nächsten tage angefertigt. also in ca. zwei-drei wochen hab ich wohl den prototyp fertig.
ich bin noch am überlegen das protokoll leicht zu ändern, aber das werde ich dann selbst ins atmowin reinhacken. dafür muss ich ja net coden können

da stellt sich mir aber auch direkt die frage: welchen compiler/entwicklungsumgebung verwendest du für atmowin?

slime
ich verwende Visual Studio 2003 - also richtig auf dem neusten Stand *g*

-> der Code sollte sich denke ich aber auch mit neueren Versionen noch kompilieren lassen. (sofern man dort noch win32 native anwendungen erstellen kann.)

Wenn du deine Änderungen an "CSlimeConnection" *g* - welche ich nochmal umbenennen werde gemacht hast - wäre es nett mir deine Änderungen zukommen zu lassen.

Igor

slime
so nächstes 0.45 Build -- steht zum Download bereit

- so langsam dürfte ich alle Macken welche ich durch den Umbau eingeschleppt wurden - beseitgt sein.

- Änderungen in diesem Build:
-- SlimeDevice -> Mondolight umbenannt
-- Speicherleck in AtmoPacketQueue beseitigt.

noch einige kleinere Optimierungen am Code, in der Hoffnung die CPU Last noch einen Hauch zu senken...

Bei mir unter Windows 2000 mit Videolan als Zuspieler - ereicht AtmoWin ca. 5-8% bei der Berechnung von 12 Zonen und der Ausgabe auf das Dummydevice. (als CPU habe ich eine 4600+ X2)

Sollte keiner mehr größere Macken oder Verschlechterungen im Vergleich zur 0.44b feststellen, würde ich dann an den üblichen Stellen auf die 0.45 verlinken.
Einsprüche werden noch bis Montag entgegen genommen

Igor

hört sich super an!
ich werde leider nicht viel zum testen kommen, aber da ich ein paar atmo-devices im freundeskreis untergebracht habe (und die fort nur unter win32 zum spielen benutzt werden) gibts da hoffentlich auch feedback.

ich werde das hier mal laden: http://www.microsoft.com/germa…download/webdownload.aspx
mal kucken ob das tut. ich lads runter, sobald ich wieder breitband hab.

die änderungen fliessen natürlich wieder an dich zurück!

Ich verstehe zwar nicht viel von der Materie (Programmieren) ...
Doch egal was ihr geändert habt, ich liebe es...

Habe jetzt auch unter Vista/Win 7 eine deutlich niedrigere CPU Auslastung und kein ruckeln mehr bei HD Inhalten...

Eine schöne Sache

Habe das ganze jetzt auch mal auf meinen Blog gestellt mit ein paar Beispielen unter www.colorcorner.de unter Entertainment / Ambilight Marke Eigenbau...

Ich bin mal gespannt was da noch kommt...

Hallo an alle, zuerst mal vielen Dank für das was ihr bislang erreicht habt.
aber ich brauch jetzt einen Tipp, denn es haut mit dem Atmowin bei mir nicht richtig hin
Ich habe Bildaussetzer im DVBViewe im Takt der GDI Capture Framerate.
Die Die Aussetzer treten im Live-TV sowie auch bei Files auf.

CPU-Last DVBViewer und Atmowin bei LiveTV ( HD ) ca. 30%, bei 720p MKV ca. 40%, 1080p MKV ~ 50%.
MB ist das Intel DG45id, CPU Intel 8500, ausgabe über HDMI.
Ich hab beim DVBviewer die Codecs schon durch, auch die Ränderer hab ich ausprobiert, ist überall dasselbe...Als Codecs hab ich ffdshow und Cyberlink und Elecard, bei den Ränderern VMR7/8.

Auch der Google bringt nix gescheites. Jemand hatte mit Atmo VDR probleme, aber das kann man ja nicht so vergleichen....

PLs Help,
Wolfgang

Hallo,

dein Problem ist das generelle Problem vom Screencapture - mittels GDI - solange niemand einen passenden DirectShowfilter implementiert, welcher sich in die Verarbeitungskette deines DVB-Viewers einklinkt - wird das wohl nicht problemlos funktionieren.

Zur Zeit ist VideoLan wohl der einzige Player womit es relativ problemlos funktionieren dürfte.

Das Problem durch GDI Capture wird vermutlich irgendwo in der Treiberarchitektur von Windows eine Sperre etabliert - unbewusst - welche die restliche Verarbeitung (Videoausgabe) wohl stört, und eine ziemliche CPU Last verursacht -- genaueres weiss ich auch nicht zu diesem Problem.

Ein Problem mit den Codecs kann ich mir nicht direkt vorstellen.

Igor

Hi Igor, danke für die schnelle Antwort.
Bei anderen scheint es ja zu funktionieren...bringt vielleicht der Umstieg auf Vista etwas oder liegt das Problem eigentlich beim DVBViewer?

lg
Wolfgang

Hi,

also Vista wirds glaube ich nicht besser machen, ist mir zumindest nicht bekannt. Das Problem wird wohl nicht direkt am DVB-Viewer selbst liegen, sondern wohl eher an der Art und Weise wie er die Bilddaten ausgibt, so das AtmoWin diese mittels GDI abgreifen kann, selbst bei anderen Usern die nicht VideoLan verwenden - ist die CPU Last sichtbar erhöht - gegenüber einer Wiedergabe ohne AtmoWin.

Für solche DirectShow basierten Player / Software - ist wirklich die einzige Chance, um die CPU Last in den Griff zu kriegen - ein passender DirectShow Filter - den allerdings bisher niemand geschrieben hat...

Das Framegrabbing via GDI ist nunmal eine "Notlösung" - aus meiner Sicht.

Igor

Igor
Danke für die Erklärung.

Hallo zusammen,

erst einmal ein dickes Lob an die, die das Ambilight für den Normalverbraucher realisiert haben

Ich habe auch schon eine Frage xD.

Ich habe bei mir zu Hause die USB-Platine mit jeweils 4 LED Clustern. Die Hard- und Software laufen einwandfrei nur ein bisschen fehlt mir noch.

Die Atmowin Software unterstützt doch "Multiatmo", was muss ich Software mäsig nun tun damit ein USB-Controller den oberen Bildschirmabschnitt in 4 Teile teilt und die Farben nicht mehr von der ganzen Bildschirm länge abhängig sind sondern nur noch von einem Viertel des Bildschirms?

Und wie sieht das ganze dann bei 2 oder 4 USB-Controller aus?

Für jede USB-Platine ist ja ein USB-Port notwendig, kann ich es auch so realisieren damit z.B. 2 Atmocontroller auf einer Platine sitzen und sich die Daten von einem USB-Port teilen oder gibt es hierbei Porblem?

Danke schonmal im vorraus
toben