Beiträge von beta

  • [Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    Hallo Gerald,

    gda schrieb:

    Ist er eben doch, lies den Thread den du verlinkt hast, dort steht doch, dass die Wetek Hub geht, weil sie eben das C-Stepping von vorneherein hatte und die aktuellen Odroids haben das C-Stepping eben jetzt auch.

    ich bilde mir schon ein, dass ich des Lesens mächtig bin. Post 9 sagt lediglich, dass die "Wetek Produkte ... warten mussten". Die Wetek-2 hat den AML 905-H Prozessor, ebenso wie die Wetek-Hub. Ich kann weder auf der Wetek-Seite noch in dem von mir zitierten Thread etwas von einem C-Stepping lesen. Aber wer weiß, vielleicht bin ich des Lesens doch nicht mächtig. Dennoch sage ich Danke für den Hinweis, dass der Odroid-C2 jetzt offensichtlich mit C-Stepping ausgeliefert wird.


    Gruß
    beta

  • [Announce] softhddevice mit mmal Ausgabe

    Hallo Zille,


    der Audio Menü-Fehler ist weg. Vielen Dank.

    Zille schrieb:

    Zitat von »beta«




    - Audio passthrough funktioniert nicht (liefert dann bei mir nur Stereo aber kein DTS)
    Den Fehler vermute ich nicht im softhddevice. Der Audio Code ist 1 : 1 vom Original übernommen.

    Ich habe mit einer externen USB-Soundkarte und mit Raspberry Pi HDMI getestet. Es funktioniert nur Stereo, kein Dolby Digital PCM passthough. Mit rpihddevice geht das einwandfrei. Darum schließe ich Verkabelungsfehler etc. aus...


    Gruß
    beta

  • [Announce] softhddevice mit mmal Ausgabe

    @zille:


    Mit der lite-Version läuft es, mit der full-Version nicht - seltsam. Es gibt ncoh ein paar Bugs:


    - Audio passthrough funktioniert nicht (liefert dann bei mir nur Stereo aber kein DTS)
    - Wenn man im Menü grün drückt für Audio ist der Text nicht lesbar nach Auswahl
    - Ab und an crasht das ganze


    Ich habe den Eindruck, dass die lite nicht ganz stabil läuft (auch nicht mit rpihddevice). Ich sollte wahrscheinlich auf Gentoo wechseln!?


    Viele Grüße
    beta

  • [Announce] softhddevice mit mmal Ausgabe

    Hallo,

    vectra130 schrieb:

    beta
    Hast du Ton über HDMI? Was hast du als Audio angegeben?
    Egal was ich mache, ob

    Code
    1. -a hw:0,0

    oder

    Code
    1. -a hw:0,1

    oder den Parameter ganz weg lassen. Ich bekomme keinen Ton raus.

    bei mir ist kommt der Ton immer über HDMI, egal, was ich einstelle. Bild habe ich keines und das log zeigt nichts verdächtiges. Ich vermute, dass die neuere Firmware und/oder der Kernel dazu beiträgt.


    @Zille: Funktioniert es bei Dir noch, wenn Du ein sudo rpi-update machst?


    Gruß
    beta

  • [Announce] softhddevice mit mmal Ausgabe

    Hallo Zille,


    Ich habe leider immer noch kein Bild (nur Ton). Ich habe allerdings auch auf die letzte Firmware ge-upgraded (inkl. neuester Kernel).
    Ich werde auf einer anderen SD-Karte noch einmal eine neue Installation machen...


    Gruß
    Beta

  • [Announce] softhddevice mit mmal Ausgabe

    Hallo Zille,


    ich konnte heute Nachmittag nur remote testen und da sah erst einmal alles gut aus. Vor dem TV sitzend stelle ich jetzt aber fest, dass der Ton funktioniert, aber kein Bild kommt. Die Distribution ist die raspbian von der raspberry foundation web seite...


    Gruß,
    beta

  • [Announce] softhddevice mit mmal Ausgabe

    @zille:


    Wer lesen kann, ist klar im Vorteil. Es funktioniert in der Tat mit Deiner ffmpeg-Version. Ich hatte den library-Path in der falschen Reihenfolge im Makefile, d.h. er hat immer die falsche eingebunden. Da ändert dann auch ein LD_LIBRARY_PATH nichts dran...


    Jetzt scheint es zu funktionieren. Sorry wegen der Verwirrung.


    Gruß,
    beta

  • [Announce] softhddevice mit mmal Ausgabe

    Hallo Zille,


    folgende Einträge im Makefile:


    Code
    1. _CFLAGS += $(shell pkg-config --cflags libavcodec) -L/opt/vc/lib -L/usr/lib/arm-linux-gnueabihf
    2. LIBS += -lrt -lmmal -lmmal_core -lvcos -lxcb -lxcb-icccm -lvchostif -lbcm_host $(shell pkg-config --libs libavcodec
    3. )


    und


    Code
    1. INCLUDES += -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/interface/vmcs_host/linux -I/opt/
    2. vc/include/interface/vmcs_host/linux


    Dazu in video.c zweiVariablen einkommentieren, da ich sonst undefined symbols hatte.
    Ich nutze Debian (neueste Firmware und neuester Kernel).


    Edit: Der Crash ist unabhängig von der ffmpeg-Version. Wenn ich Deine unter /usr/local/lib mit LD_LIBRARY_PATH verwende, gibts einen Crash an derselben Stelle.


    Edit2: Die einkommentierten Variablen sind VideoZoomModes und VideoSetGeometry.


    Gruß,
    beta

  • [Announce] softhddevice mit mmal Ausgabe

    @zille:


    Ich finde die Idee sehr gut. Zum Compilieren musste ich einige Pfade und zusätzliche Bibliotheken ins Makefile eintragen. Beim Start allerdings crasht das Plugin:



    Mein Test war allerdings ohne externe Soundkarte, sondern nur Karte 0: ALSA [bcm2835 ALSA], Gerät 1: bcm2835 ALSA [bcm2835 IEC958/HDMI].


    Gruß,
    beta

  • [Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    rfehr schrieb:

    P.S.: gib bescheid, ob es läuft ;)


    Hallo Roland,


    ja und nein. Es läuft auf dem ersten SD Kanal ohne Crash. Allerdings habe ich beim Umschalten kein Bild mehr und HD geht gar nicht. Das liegt aber sicherlich daran, dass mein Image inzwischen "vermurkst" ist. Ich werde es noch einmal neu aufsetzen.
    Jetzt müssen wir noch das Problem mit wetekdvb.ko lösen. Das crasht die Wetek nämlich komplett mit amlhddevice.


    Gruß
    beta

  • [Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    Hallo Roland,


    Prima! Ich habe Thomas rootfs in ein Image gepackt und das funktioniert ebenfalls einwandfrei. emerge auf einem arm macht wirklich keinen Spaß :( Dann kann ich ja jetzt auch wieder auf mein altes Image wechseln.


    Danke nochmal an alle fürs Helfen und besonders an Thomas für die viele Arbeit und die freundliche Unterstützung.


    Viele Grüße
    beta

  • [Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    rfehr schrieb:

    und bist du schon weiter gekommen?


    Hallo Roland,


    ich habe gestern noch ein Image gemacht, welches ich mit meinem boot.img gestartet habe. Das rootfs habe ich erfolgreich gebootet, hatte allerdings keine Netzverbindung (ich bin blutiger Gentoo-Neuling ;)). Es bootet erst einmal und VDR startet zumindest mit dem OSD.
    Ich werde heute Abend erst einmal das Netzwerk aktivieren und schauen, ob das Plugin mit diesem Image prinzipiell bei mir läuft. Wenn ja, werde ich Stück für Stück tauschen/debuggen um rauszufinden, wo die Unterscheide sind. Ich melde mich dann.


    Viele Grüße
    beta

  • [Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    ollo schrieb:

    Deswegen noch 'ne Frage - welche Version vom WeTek OS habt ihr im NAND? OE verlangt ja auch immer nach der Neusten (aktuell 1.1.5) weil wohl auch U-Boot mit aktualisiert wird.


    Und habt ihr Einstellungen im "WeTek Konfigurator" geändert? Dort kann man ja die default Auflösung umstellen (720p -> 1080p) bzw. auch den Audio Out (PCM vs. HDMI)


    Hallo ollo,


    Ich habe im NAND auf die aktuellste Android-Version upgedated. Auflösung habe ich auf 1080p umgestellt. Meine Android-Einstellungen bzgl. Audio out hatten keinerlei Auswirkungen. Ich habe - egal bei welcher Einstellung - sowohl Audio über SPDIF als auch über HDMI gehabt. SPDIF war dabei immer Stereo (getestet mit Wetek Theatre, kein 5.1, das kann aber an Theatre liegen).


    Da das Ubuntu-Image down ist, mache ich gerade ein backup von meinem, bevor ich Thomas rootfs installiere und gegenteste. Wahrscheinlich bekommst Du (wie ich auch) 25 MB Speicher für den Framebuffer, wenn Du Android auf 1080p umstellst und wirst dann beim selben Audio-Crash laden wie Roland und ich. Dank Thomas habe ich aber bald was, gegen das ich vergleichen und debuggen kann.


    Einen Tipp noch für vmalloc: Ich habe mkbootimg native für Wetek übersetzt und ins Kernel-Verzeichnis kopiert. Wenn ich wie Thomas vorgeschlagen hat mit make uImage-dtb das uImage baue, als Parameter dann initfs und wetekplay.dtb angeben, nimmt er die Parameter, die in wetekplay.dtb gesetzt sind (z. B. vmalloc=300m) und überschreibt die des NAND uboots (vmalloc=256m). Achte darauf, dass die Kernel-Config wetekplay.dtd heißt und nicht wetek_play.dtd.


    Viele Grüße
    beta

  • [Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    Jetzt fällt mir nicht mehr viel zur Suche ein, außer, dass Thomas uns sein Image zur Verfügung stellt oder wir uns ein eigenes Gentoo basteln, um den Unterschied herauszufinden.
    Kernel ist derselbe, config passt, amlibs sind identisch, Kernel-Parameter passen mit Ausnahme 720p (teste ich heute Abend). Dann kann es ja nur irgendein Installationspaket sein, was noch benötigt wird und bei Gentoo anders ist.


    Gruß
    beta

  • [Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    rfehr schrieb:

    beta , welche hast du genommen?

    Hallo Roland,


    ich habe dieselbe Quelle wie Thomas genutzt (openELEC). Die md5-Summe der Firmware stimmt mit meiner überein. Ich habe es aber auch mit den anderen Sourcen versucht. Daran liegt es leider nicht. Hat es denn überhaupt jemand das Plugin auf der Wetek laufen außer Thomas? Was könnte denn bei Gentoo anders sein als bei Ubuntu bzw. MLD?


    Gruß
    beta

  • [Prototyp] Ausgabeplugin für Amlogic SoC (z.B. Wetek Play)

    reufer schrieb:

    Edit: Weshalb willst du ein eigenes U-Boot für die SD-Karte?


    Gruss
    Thomas

    Hallo Thomas,


    Ich habe es nicht geschafft, nur mit mit image-dtb zu booten. Ich muss mir ein eigenes boot.img mit mkbootimage bauen, dem ich image-dtb, initfs und weteplay.dtb als Parameter mitgebe. Lasse ich initfs weg, bootet der Kernel nicht. Hätte ich ein eigenes u-boot auf der Karte, könnte ich den Bootvorgang mit Tastendruck anhalten und mit setenv verschiedene Kernelparameter setzen/testen. Das wäre deutlich schneller, als jedesmal wetekplay.dtd zu editieren und ein boot.img zu generieren.
    Momentan habe ich echt keine Idee mehr, was bei Deinem gentoo-Image anders ist als bei meinem Ubuntu oder bei der MLD. Audio sollte mit Hilfe des Kernels initialisiert werden und mit amlib dekodiert werden. Alsa wird - denke ich - gar nicht benötigt. Die sound-devices sind alle da und trotzdem läuft der Audio-Buffer voll. Ich mache heute Abend noch einen Versuch mit 720p im Android NAND. Ein fbset auf 720p hat jedenfalls keine Verbesserung gebracht. Vielleicht hilft ja auch ein syslog-Ausschnitt von Dir, wenn Du amlhddevice startest. Dann könnte ich schauen, ab wo es auseinanderläuft. amffmpeg wird ja nicht benötigt, oder liegt hier unser Fehler? Ich versuche mal, den Tsplayer zu übersetzen, vielleicht sehe ich hier etwas bzgl. Audio-Initialisierung.


    Viele Grüße und danke für Deine Hilfe
    beta