Diskussion über Softwareunterstützung für das HDMI-Interface

[[IDC]Dragon]

Hallo,

ich bin der Erbauer von dem HDMI-Interface, wer's noch nicht gesehen hat:
http://forum.tuxbox-cvs.sourceforge.net ... 19&t=47642

Entgegen meinen ersten Postings zieht das Thema doch an, mit dem Redesign verwende ich einen Chip für den es ein öffentliches Datenblatt gibt, und den man in kleinen Stückzahlen kaufen kann. HDMI "für's Volk" rückt in greifbare Nähe.

Ich verwende einen Atmel-uC, damit das Ganze unabhängig vom Image autark laufen kann. Das muß vielleicht nicht unbedingt sein (falls der VSync-Workaround anders lösbar ist, s.u.), aber eröffnet auch zusätzliche Möglichkeiten wie CEC.

Folgende Punkte sehe ich zum Thema Softwareunterstützung:

1. Der Transmitter-Chip wird z.Zt. vom uC initialisiert. Ferner muß ich am I²C auf die 4:3 / 16:9 Umschaltung des PAL-Encoders hochen, um das im HDMI-Chip nachzuziehen. In einer nativ drauf ausgelegten STB würde solche Dinge natürlich die Host-CPU tun.

2. HDMI-Transmitter wollen einen "echten" VSync oder embedded syncs, die Box arbeitet intern z.Zt. mit einem unüblichen Field Sync. Ich hielt diesen Sync erst für eine Privatsache zwischen Avia Gtx und dem PAL-Encoder SAA7126, aber der MPEG-Decoder hängt als Dritter auch mit dran.
Den SAA7126 kann man leicht umstellen, in "driver\saa7126\saa7126_core.c" die I²C-Tabelle saa7126_inittab_pal[] für die Subadresse 0x6B ändern, z.Zt. steht da 0x52 (Nokia, Sagem) bzw. 0x72 (Philips).
Bei den AVIAs bin ich ich mir nicht sicher, evtl. in "driver\dvb\drivers\media\dvb\avia\avia_av_core.c", avia_av_set_default(), VIDEO_MODE.
Im Moment erzeuge ich behelfmäßig ein VSync mit einer Pulsverdopplerschaltung. Mit dem Redesign habe ich Extra-Logik und uC-Mithilfe vorgesehen, bessere Möglichkeiten, aber auch nicht taktgenau, dazu bräuchte man ein CPLD oder so. All das könnte man vielleicht durch eine Umstellung einsparen. Nur wenn das gelingt kann später mal der uC komplett entfallen.

3. Das Interface hat die Möglichkeit, als Audio entweder den S/PDIF Bitstream oder das PCM-Signal hinter dem Gtx zu verwenden. Diese Wahl möchte man vielleicht steuern können. Nur der S/PDIF Bitstream kann AC3 transportieren, und nur hinter dem Gtx hört man von der CPU erzeugtes Audio wie z.B. mp3.

4. Es gibt in HDMI die Möglichkeit, für jeden Frame/ jedes Field die Bitrate und Art (I,P,B) anzugeben. Ein externer Scaler kann dann ein entsprechend starkes oder schwächeres Deblocking machen. Um das zu nutzen müßte man diese Information bildsynchron gewinnen.

5. Als Zukunftsmusik könnte man CEC nutzen, z.B. die Box über die Fernseher-Fernbedienung steuern, oder andere Geräte untereinander. Dazu braucht man den uC aber wieder, denn mit Empfang und Decodierung der Bits wollen wir das Image wohl nicht belasten. Ist eigentlich noch ein Interrupt frei+zugänglich?

6. Ich denke über einen möglichen Firmware-Update des uC über I²C durch die Box nach. Dazu müßte ein Bootloader im uC sein, mit einem Programm auf der Box könnten dann auch Anwender den Controller flashen.


Das waren erstmal die Punkte, die mir einfallen. Ich habe noch nie Software für die Box gebaut, keine Ahnung was für eine Entwicklungsumgebung man da braucht, wie das zusammenspielt und wie man das debuggt. Hier könnte ich gut Hilfe gebrauchen. Ist das ein Thema, haben wir hier die Kompetenz, mag jemand aufspringen?

Gruß und Dank, Jörg

[wolgade]

Das ist ja ein Mordsbetrieb in diesem Thread. Da es sicher nicht am grundsätzlichen Desinteresse liegt, vermute ich mal, daß es für die meisten einfach sehr schwierig ist, die Höhe der Hürden bei deinem Projekt einzuschätzen. Was muß ich können? Kann ich mit dem, was ich kann, überhaupt helfen?

Das kommt davon, wenn man den Leuten reihenweise die Kinnlade auf die Tischplatte fallen läßt. Da traut sich dann keiner mehr.

Ich habe keine Ahnung, ob ich irgendeinen Beitrag leisten kann, aber ich versuch jetzt einfach mal, das herauszufinden.

Ich verwende einen Atmel-uC, damit das Ganze unabhängig vom Image autark laufen kann. Das muß vielleicht nicht unbedingt sein (falls der VSync-Workaround anders lösbar ist, s.u.), aber eröffnet auch zusätzliche Möglichkeiten wie CEC.

Um wieviel verteuert der Atmel denn das Ganze? Ich kenne persönlich nur die ATMega-uCs, mit denen ich mal rumgespielt habe. Die kriegt man für 3-5 Euro nachgeworfen. Als Entwickler in der Industrie müßtest du natürlich jeden nur möglichen Cent einsparen, erst recht bei einem Consumergerät. Bei deinem Projekt könnte es am Ende ärgerlich sein, am falschen Ende zu sparen.

Der Transmitter-Chip wird z.Zt. vom uC initialisiert.

Wenn der Transmitter-Chip ohne uC durch die Box initialisiert werden soll, dann sollte das im u-boot passieren, da sonst über HDMI kein Bootlogo angezeigt wird. Ohne Bootlogo könnte man zwar leben, aber wer weiß, welche schrägen Signale der Transmitter-Chip vor der Initialisierung von sich gibt. Minutenlang kein Bild oder visualisierter Datenmüll wäre unschön.

Ich halte den uC zur Initialisierung für eine gute Idee. Grafikkarten haben auch ein eigenes BIOS.

Ferner muß ich am I²C auf die 4:3 / 16:9 Umschaltung des PAL-Encoders hochen, um das im HDMI-Chip nachzuziehen. In einer nativ drauf ausgelegten STB würde solche Dinge natürlich die Host-CPU tun.

Industrielle Entwickler einer STB haben im allgemeinen auch Zugriff auf sämtliche Datenblätter. Gibt es öffentliche Datenblätter der AVIAs? Nicht einmal das öffentlich verfügbare Datenblatt des SAA ist vollständig, Macrovision sei es gedankt.

Wer macht denn die 4:3 / 16:9 Umschaltung des SAA? Macht das der AVIA oder macht es Neutrino? Wenn es Neutrino macht, dann kann Neutrino natürlich auch den HDMI-Transmitter umschalten.

die Box arbeitet intern z.Zt. ein Field Sync. Ich hielt diesen Sync erst für eine Privatsache zwischen Avia Gtx und dem PAL-Encoder SAA7126, aber der MPEG-Decoder hängt als Dritter auch mit dran.

Hier stellt sich natürlich die Frage, warum die D-Box-Entwickler diesen Weg gegangen sind. Waren die zu doof, es richtig zu machen, war es ihnen egal oder brauchten sie diesen schrägen Modus damit die Kiste funktioniert?

Bevor das niemand genau weiß, würde ich davon ausgehen, daß die Pulsverdopplerschaltung gebraucht wird. Das könnte man aber natürlich ausprobieren, wenn die Einstellungen da stattfinden, wo du sie vermutest. Aber halt: Kommen diese Treibereinstellungen nicht erst zum Tragen, wenn Linux geladen wird? In welchem Betriebsmodus sind die beteiligten ICs denn nach der Initialisierung durch Bmon? Nimmt u-boot an AVIAs und SAA irgendwelche Einstellungen vor?

Worauf ich hinaus will: Wenn Bmon diesen merkwürdigen Modus einstellt und u-boot ihn nicht ändert, dann gibt es ohne Pulsverdopplerschaltung über HDMI erst ein Bild, nachdem Linux geladen ist.

Ich habe noch nie Software für die Box gebaut, keine Ahnung was für eine Entwicklungsumgebung man da braucht, wie das zusammenspielt und wie man das debuggt. Hier könnte ich gut Hilfe gebrauchen.

Welche Entwicklungsumgebung (du meinst IDE?) man braucht, weiß ich nicht. Vielleicht nutzen einige auch einen schlichten Texteditor.

Konkret: Hier verstehe ich die Frage nicht ganz. Geht es nur um die Frage, wie man ein ausgechecktes CVS kompiliert bekommt, wie man ein Linux-System mit den nötigen Tools versieht oder tatsächlich darum, welche IDE, wenn man denn eine braucht, am besten ist?

Jetzt hast du natürlich mehr Fragen als Antworten bekommen. Aber die meisten davon habe ich an alle hier gestellt. Vielleicht gibt es ja jetzt etwas mehr Resonanz in diesem Thread.

[[IDC]Dragon]

Das ist ja ein Mordsbetrieb in diesem Thread.

Danke, daß du das Schweigen brichst. Gelesen haben diesen "Tread" bisher ziemlich viele. Ich wollte auch noch mal nachsetzen, dass ich beileibe von niemandem erschöpfende Antwort auf all meine Punkte erwarte. Jeder kleine Beitrag ist willkommen.

Um wieviel verteuert der Atmel denn das Ganze? Ich kenne persönlich nur die ATMega-uCs, mit denen ich mal rumgespielt habe. Die kriegt man für 3-5 Euro nachgeworfen.

An reinen Bauteilekosten natürlich nicht viel, vielleicht 3 Euro für Atmel und 2 TTL-Chips, plus Platinenfläche. Ohne uC wäre die "Wartung" einfacher, so stellt sich die Frage wie man Updates der uC-Firmware macht.

Wenn der Transmitter-Chip ohne uC durch die Box initialisiert werden soll, dann sollte das im u-boot passieren, da sonst über HDMI kein Bootlogo angezeigt wird. Ohne Bootlogo könnte man zwar leben, aber wer weiß, welche schrägen Signale der Transmitter-Chip vor der Initialisierung von sich gibt. Minutenlang kein Bild oder visualisierter Datenmüll wäre unschön.

Guter Tipp. Ohne Init passiert da gar nichts, der Chip schläft.
Im U-Boot finde ich tatsächlich Code für SAA und Avia Initialisierung. Dort auch HDMI unterzubringen ist wohl nicht so toll, bläht es auf.

Gibt es öffentliche Datenblätter der AVIAs? Nicht einmal das öffentlich verfügbare Datenblatt des SAA ist vollständig, Macrovision sei es gedankt.

Wir brauchen ja kein Macrovision, insofern ist das SAA-Datenblatt wohl für uns ausreichend.
Vom Avia-Gtx habe ich sogar sehr zufällig ein Handbuch geerbt (auf Papier), habe ich jetzt erst gefunden, wir haben das Teil vor ca. 10 Jahren auch mal eingesetzt. Ich kriege das aber nicht richtig mit dem Code zur Deckung, vermutlich andere Firmware.

Wer macht denn die 4:3 / 16:9 Umschaltung des SAA? Macht das der AVIA oder macht es Neutrino?

Neutrino, der Avia fummelt ja nicht aktiv auf dem I²C-Bus rum. Die Stelle im Code habe ich glaubich schon gesehen.

Ich habe noch nie Software für die Box gebaut, keine Ahnung was für eine Entwicklungsumgebung man da braucht, wie das zusammenspielt und wie man das debuggt. Hier könnte ich gut Hilfe gebrauchen.

Welche Entwicklungsumgebung (du meinst IDE?) man braucht, weiß ich nicht. Vielleicht nutzen einige auch einen schlichten Texteditor.

Konkret: Hier verstehe ich die Frage nicht ganz. Geht es nur um die Frage, wie man ein ausgechecktes CVS kompiliert bekommt, wie man ein Linux-System mit den nötigen Tools versieht oder tatsächlich darum, welche IDE, wenn man denn eine braucht, am besten ist?

Ich meinte nicht den Editor, sondern die Crosscompiler, Kernel und sonstige externe Quellen, und ob man das unter Linux/Cygwin machen muß. Ferner was für Bestandteile es gibt, wie man die draufkriegt, wie man sie debuggt. Aber das steht bestimmt irgendwo, war zu faul zum suchen.
Ich bin halt völliger embedded-Linux-Noob. Im Moment könnte ich nicht mal ein Usermode-Programm schreiben, das den I²C-Treiber öffnet und eine Sequenz abfeuert.

[wolgade]

Ich meinte nicht den Editor, sondern die Crosscompiler, Kernel und sonstige externe Quellen, und ob man das unter Linux/Cygwin machen muß. Ferner was für Bestandteile es gibt, wie man die draufkriegt, wie man sie debuggt. Aber das steht bestimmt irgendwo, war zu faul zum suchen.

Das wollte ich wissen. Da können dir jetzt nämlich viele hier helfen.

Ob gegenwärtig noch jemand Cygwin nutzt, weiß ich nicht. Ich hab das nie richtig zum Laufen gekriegt.

Sehr viel einfacher ist es, Linux zu installieren und das als Umgebung zu nutzen. Sinnvoll wäre es dann wahrscheinlich, während der Entwicklung keine Images zu kompilieren, sondern YADDs, die man über das Netz booten kann. Die Anleitung für das Bauen von YADDs gibt es hier: http://cvs.tuxbox.org/cgi-bin/viewcvs.c ... n?rev=HEAD

[MarcM]

das gibst auch in deutsch....
http://cvs.tuxbox-cvs.sourceforge.net/c ... e?rev=HEAD

außerdem ist gibts da auch noch newmake....im Wiki sehr gut dokumentiert
http://wiki.tuxbox-cvs.sourceforge.net/wiki/Newmake

Marc

[Tommy]

Der gute Yjogol hat sich auch die Mühe gemacht den Buildprozess zu vereinfachen mit yBuild:
http://www.yjogol.com/development/index.php

[wolgade]

Jetzt kommt ja langsam Leben in den Thread.

Ich kann konkret Hilfe anbieten für das Einrichten der Serverdienste unter Linux (DHCP, TFTP, NFS), die gebraucht werden, damit die D-Box die selbstkompilierte YADD über das Netzwerk bootet. Diese Serverdienste machen das, was unter Windows der Bootmanager macht.

Auch über die typischen Einstiegshürden beim Erstkontakt mit Linux auf dem Desktop kann ich hinweghelfen.

Um zu einer brauchbaren Entwicklungsumgebung zu kommen, stehen jetzt folgende Schritte an:

• Windowspartition verkleinern, damit unpatitionierter Plattenplatz für die Linuxinstallation vorhanden ist. 10 GB reichen knapp, wenn du unter Linux nur D-Box-Entwicklung machen willst. Ich würde aber mindestens 20 GB vorsehen.

• Auswahl einer Linuxdistribution. Ubuntu und openSuse sind einsteigerfreundlich. Ich persönlich kenne mich mit openSuse besser aus.

• Linux installieren

• Die benötigten Entwicklungstools über die Paketverwaltung der Distri installieren

• DHCP, TFTP, NFS installieren und konfigurieren.

Fragen zu den einzelnen Punkten stellst du am besten konkret. Dann kann man sie auch konkret beantworten.

[[IDC]Dragon]

Jetzt kommt ja langsam Leben in den Thread.

Ja, aber auf einem Nebenkriegsschauplatz. Wie man zu einer Entwicklungsumgebung kommt war nicht mein Hauptthema. (Ist aber auf jeden Fall echt lieb von euch!)
Das würde ich am liebsten in einen anderen Tread verlagern, falls das noch länger wird. Da kann man doch bestimmt einen wiederbeleben... ;-)
Edit: gibt ja reichlich im CDK-Forum.
Noch ganz kurz: Ich würde wohl eher eine virtuelle Maschine nehmen. Mein Hauptarbeitsgerät ist ein Notebook. Ferner habe ich einen Server unter Linux laufen. Der eignet sich nicht wirklich zum compilieren, ist ein Stromspar-Mini-ITX der von Flashkarte läuft. Aber Dienste wie NFS und FTP macht er schon.

Generell hoffe ich, gern noch Mitstreiter an der Softwarefront zu gewinnen, falls es denn eine gibt. Vielleicht muß ich ja nicht alles alleine machen? Derzeit habe ich aber den Eindruck, ich sollte da lieber nicht drauf bauen und den uC-Ansatz soweit wie möglich weiterverfolgen. Für meine Punkte 3. bis 6. ist aber die Box gefordert.

[wolgade]

Noch ganz kurz: Ich würde wohl eher eine virtuelle Maschine nehmen. Mein Hauptarbeitsgerät ist ein Notebook.

Da solltest du sicherstellen, daß du aus der virtuellen Maschine auf den COM-Port, bzw. einen über USB nachgerüsteten COM-Port zugreifen kannst. Ein Bootlog wirst du brauchen.

Schwieriger wird es, wenn die Box jetzt dein Eigenkompilat vom Notebook booten soll. Dazu müßtest du sicherstellen, daß die DHCP- und TFTP-Requests an die virtuelle Maschine weitergeleitet werden. Auch NFS müßtest du entsprechend umleiten. Keine Ahnung, ob das geht. Alternativ könntest du natürlich den Bootmanager benutzen. Ich hatte allerdings schon vor ein paar Jahren das Problem, daß der meine selbstkompilierten YADDs nicht booten wollte.

Ferner habe ich einen Server unter Linux laufen. Der eignet sich nicht wirklich zum compilieren, ist ein Stromspar-Mini-ITX der von Flashkarte läuft. Aber Dienste wie NFS und FTP macht er schon.

Wenn du den Server zum Booten der YADD nutzen willst, dann mußt du ihn jedesmal komplett umkonfigurieren. Das ist sehr lästig. Nebenbei: TFTP und FTP ist nicht das Gleiche.

Vielleicht hast du ja noch einen Uralt-PC rumstehen, der sich zum Booten der YADDs nutzen läßt. Ich habe dafür meinen alten Pentium 166 recycelt. Da habe ich mit viel Geduld eine Suse 10.0 drauf installiert und alle Server eingerichtet. Über minicom wird geloggt. Das Ganze ist bequem per WLAN bedienbar.

[Houdini]

Also ich bin gerne dabei mitzuhelfen, allerdings ist meine Zeit auch ziemlich begrenzt.
Trotzdem würde ich dich gerne unterstützen

[seife]

Ich bin nicht wirklich der Treiber-Spezi, (aber ich hätte Leute an der Hand, die mir helfen könnten), jedoch denke ich, dass es kein Problem sein sollte, das wechseln von 4:3 in 16:9, was sowohl neutrino als auch enigma bisher auch den dekodern/enkodern mitteilen müssen, auch auf den i2c-Bus zu verkünden.

Wenn man deinem chip über den i2c-Bus auch sagen kann, ob er s/p-dif oder pcm verarbeiten soll, dann wird das auch noch einzubauen sein.

Zu Punkt 4: ob diese Information verfügbar ist, weiss ich nicht. Evtl. müsste man da mal carjay ansprechen, soweit ich weiss kennt der sich relativ gut sowohl mit der Hardware (avia) als auch mit den Treibern aus.

Also kurz: wenn es konkret was zu tun gibt, bin ich bereit zu helfen (und dabei habe ich gar keine HDMI-fähige Hardware ;-)), allerdings war halt kein Thema dabei, wo ich mich so richtig "zuständig" bzw. auch nur wirklich "befähigt" fühlte...

[doc]

Offtopic:
Um auf natives Linux umzustellen muss man nicht unbedingt den für einen Neuling doch etwas aufwendigen Weg der zusätzlichen Installation eines Linux OS gehen. Wenn ich mal schnell eine Distri testen will benutze ich inzwischen die Installation in Virtualbox. Dies ist dann ein "echtes Linux" ohne das Gebastel wegen cygwin.
Wenn man natürlich sowieso umsteigen will dann kann man aber auch den Weg über die komplette Installation in einer seperaten Partition gehen. Dies ermöglicht dann auch die doch sonst etwas beschränkten Netzwerkbootfunktionen unter Windows.

[[IDC]Dragon]

Also ich bin gerne dabei mitzuhelfen, allerdings ist meine Zeit auch ziemlich begrenzt.
Trotzdem würde ich dich gerne unterstützen

Prima Einstellung, danke!

Ich bin nicht wirklich der Treiber-Spezi, (aber ich hätte Leute an der Hand, die mir helfen könnten), jedoch denke ich, dass es kein Problem sein sollte, das wechseln von 4:3 in 16:9, was sowohl neutrino als auch enigma bisher auch den dekodern/enkodern mitteilen müssen, auch auf den i2c-Bus zu verkünden.

Das wird heute schon auf I2C "verkündet", für den SAA. Nur deshalb kann das mit dem Lauschen funktionieren. (Ich habe es noch nicht implementiert.)

Wenn man deinem chip über den i2c-Bus auch sagen kann, ob er s/p-dif oder pcm verarbeiten soll, dann wird das auch noch einzubauen sein.

Dem Transmitter kann man das sagen. Wenn der aber in der Version mit uC nicht direkt am I2C Bus hängt, sondern der uC, muß dieser einen I2C Slave implementiert haben und das rüberreichen. Das ist schon anspruchsvoller, plane ich nicht für die erste Betaversion. Muß für alle anderen Konfigurationsgeschichten aber auch sein.

Zu Punkt 4: ob diese Information verfügbar ist, weiss ich nicht. Evtl. müsste man da mal carjay ansprechen, soweit ich weiss kennt der sich relativ gut sowohl mit der Hardware (avia) als auch mit den Treibern aus.

Bitte mach mal, ich kenne mich mit "carjay" nicht aus. ;-)

Also kurz: wenn es konkret was zu tun gibt, bin ich bereit zu helfen (und dabei habe ich gar keine HDMI-fähige Hardware ;-)), allerdings war halt kein Thema dabei, wo ich mich so richtig "zuständig" bzw. auch nur wirklich "befähigt" fühlte...

Ich erwarte von niemandem, sich zu bemühen ohne gar Hardware zu haben. Die ersten 6 Prototypen sollte man schon geschickt aufteilen, mal sehen wie das gelingt.
So 10 Stück mehr wäre auch nicht schlecht, das kann ich mit meinen Mustern aber nicht bestreiten. Dazu ist ein weiterer Platinen-Run nötig und eine Bauteilbestellung bei Digikey USA. In diesen Kleinstückzahlen ist das noch recht teuer.

Erstmal will ich die Sache soweit treiben, das sie autark läuft. Und die Konzept-Gedanken hier anregen.

[Carjay]

Ja, das wirklich dazu passende API-Interface für die MPEG2-Firmware hatten wir auch nicht, da wurde einfach das gemacht was die BR gemacht hat und irgendwo gab es auch eine Kopie der älteren API.

Ist bei dem MPEG2-Decoder ungünstig, weil die wesentlichen "Register" dort eher Offsets in einen Speicher sind und somit beliebig umdefinierbar. Aber scheint ja soweit funktioniert zu haben.

Für mich ungewöhnlich, daß der HDMI-Chip keinen field vsync erwartet, den vertikalen Sync kenne ich eigentlich nur field-basiert. Ist das evtl. kein Sync, sondern ein Top/Bottom Field-Signal? Aber ich kenne den HDMI-Standard nicht.

Der Avia kann aber sowohl ITU-R-BT.601 als auch ITU-R-BT.656 (D1) ausgeben (beide Avias, also 500 und 600). Dann hättest du ja embedded sync. Könnte das evtl. schon reichen? War vermutlich nicht eingeschaltet, weil der SAA das nicht benötigt.

Das dazugehörige Setup-Bit ist zu finden in avia_av_core.c in der Funktion avia_av_setdefault(void).

Achtung, im Original steht der Setup für "val" in einem #ifdef 0-Block, muß also da drunter, hier der Patch dafür:

Code: Alles auswählen

Index: avia_av_core.c
===================================================================
RCS file: /cvs/tuxbox/driver/dvb/drivers/media/dvb/avia/avia_av_core.c,v
retrieving revision 1.98.2.10
diff -u -r1.98.2.10 avia_av_core.c
--- avia_av_core.c	9 Oct 2007 21:52:20 -0000	1.98.2.10
+++ avia_av_core.c	31 May 2008 14:35:41 -0000
@@ -771,8 +771,8 @@
 #if 0
 	val |= (0 << 2);	/* 1: tristate */
 	val |= (0 << 0);	/* 0: slave 1: master HSYNC/VSYNC */
-	val |= (0 << 0);	/* 0: BT.601 1: BT.656 */
 #endif
+	val |= (1 << 0);	/* 0: BT.601 1: BT.656 */
 
 	avia_av_dram_write(VIDEO_MODE, val);
 

[[IDC]Dragon]

Sorry, ich habe die Antwort von Carjay erst jetzt gesehen, hatte diesen Thread schon quasi abgeschrieben.

Der Avia kann aber sowohl ITU-R-BT.601 als auch ITU-R-BT.656 (D1) ausgeben (beide Avias, also 500 und 600). Dann hättest du ja embedded sync. Könnte das evtl. schon reichen? War vermutlich nicht eingeschaltet, weil der SAA das nicht benötigt.

Das dazugehörige Setup-Bit ist zu finden in avia_av_core.c in der Funktion avia_av_setdefault(void).

Das wäre hochinteressant. Embedded Syncs würden eine Menge Krampf unnötig machen. Keine "Reparierlogik" nötig und 2 Drähte weniger anzuschließen.

Das spräche sehr für eine Lösung "per Image" statt einer autarken Platine. Dann kann man auch die Audio-Umschalterei zwischen S/PDIF mit AC3-Möglichkeit und I²S mit CPU-Sounds dort regeln, sowie die 16:9 / 4:3 Umschaltung und einen Standby.

Dem Projekt fehlt jemand, der in der Software drinsteckt und ein HDMI-Interface haben will... ;-)

[AudioSlyer]

... oder dem fehlt die Box Hab leider keine Dbox2 mehr, sonst wäre da sicherlich was machbar...