Thema: Miniaturrechner diverses ... (Raspberry Pi etc.)

[Jürgen]

Sie können den Raspberry Pi bei uns vorbestellen.

Der genaue Termin wann wieder ausgeliefert werden kann steht zum heutigen Tag (07.03.2012) noch nicht fest.

Haben die die erste Charge komplett verpasst, oder brauchen sie unbedingt jemanden, der ihre Webseite pflegt???

[Dragonix]

Die ersten Raspberries sind inzwischen bei den Besitzern eingetroffen und folgende Benchmaks wurden gepostet. Als Distro wurde raspbmc verwendet

[...]

Die in vorherigen Posts angesprochene Problematik mit den mpeg2 Video- & Audio-Codecs ist leider so wie erwartet zum tragen gekommen. Jedoch hat die Raspberry Foundation jetzt angekündigt die Lizenzen für Mpeg2 doch noch erwerben zu wollen.

Sollte dies tatsächlich passieren mausert sich der RPi zu einem sehr interessanten low cost dvb-cube

Zwei vermutlich ziemlich blöde Fragen: Wurde da nur getestet, was in Hardware geht, oder ist der wirklich zu schwach, um diverse Audio Codecs in Software zu dekodieren? Und, wenn die Mpeg2 Lizenzen holen, wo ist das gespeichert? Wird da in Hardware ein "Bit" umgelegt (=> nur neue Chargen), oder erfolgt das per Softwareupdate - bei letzterem frage ich mich dann aber, wie man generell die Feauters von dem Chip einschränkt, man könnte ja dann einfach die Binaries von einem völlig anderen Gerät nehmen, dass für alles freigeschalten ist (bzw. evtl selber ein, zwei Bits händisch umschubsen)...?

Grüße
Matthias

[mtron]

Haben die die erste Charge komplett verpasst, oder brauchen sie unbedingt jemanden, der ihre Webseite pflegt???

Letzteres. Ein Kollege hat via email 5 RPi's um 168 € (incl allem) bestellt ( Bestätigung schon erhalten). Auf die Einschränkung auf 1 gerät pro Bestellung pfeifen die Herren anscheinend. Liefertermin ist für Anfang August angegeben.

Wurde da nur getestet, was in Hardware geht, oder ist der wirklich zu schwach, um diverse Audio Codecs in Software zu dekodieren?

Der 700 MHZ ARM ist zu schwach um mpeg2 in software zu dekodieren. Auch wenn dies mit einem 700 MHZ x86 (knapp?) möglich wäre ist ein ARM dennoch nicht vergleichbar und bringt das ohne Software optimierungen nicht.

Und, wenn die Mpeg2 Lizenzen holen, wo ist das gespeichert? Wird da in Hardware ein "Bit" umgelegt (=> nur neue Chargen), oder erfolgt das per Softwareupdate

So einfach ist das nicht. Der chip kann es zwar, jedoch existiert schlicht keine externe API, also die Funktion ist im binary treiber nicht implementiert. Lässt sich natürlich über ein software update des treibers nachrüsten, sofern sie die Lizenzen für Mpeg2 erstehen.

man könnte ja dann einfach die Binaries von einem völlig anderen Gerät nehmen, dass für alles freigeschalten ist

schon mal versucht ein kernel modul zu laden das nicht für den verwendeten kernel kompiliert wurde? No way Jose...

[Dragonix]

Der 700 MHZ ARM ist zu schwach um mpeg2 in software zu dekodieren. Auch wenn dies mit einem 700 MHZ x86 (knapp?) möglich wäre ist ein ARM dennoch nicht vergleichbar und bringt das ohne Software optimierungen nicht.

Ich hab aber nach Audio Codecs gefragt, bei denen kann ich nämlich den CPU Ressourcenbedarf kaum abschätzen.

schon mal versucht ein kernel modul zu laden das nicht für den verwendeten kernel kompiliert wurde? No way Jose...

Über Wrapper wäre das durchaus möglich (die Herren von AMD/nVidia machen ja letztlich nix anderes, und das es nicht uneingeschränkt (ARM auf x86, etc) geht ist auch klar), aber ich hab eben nicht gewusst, wie der Chip angesprochen wird - merci

[mtron]

Ich hab aber nach Audio Codecs gefragt,

Mea culpa

Audio wird vom 2835 SoC im RPi übernommen. Der Chip funktioniert mit open source kernel drivers, Ausgabe via HDMI oder PWM.  Sonst weiss ich diesbezüglich nix.

Über Wrapper wäre das durchaus möglich

Ich habe jetzt seit einiger Zeit mit ARM Hardware herumgespielt (zuerst mit dem N800 dann mit meinem Android ZTE blade) aber sloche wrapper für binary blobs die solche module 'portabel' unter verschiedenen kernel machen sind mir noch nicht untergekommen.  

Noch ein mplayer benchmark am RPi für SD 720p mpeg2 in software decode:
498 frames in approx 35 seconds

Bedeutet so um die 14 fps. Leider schon eindeutig zu langsam... Aber auf der software dekoder seite könnte es mit einem gl vo treiber durchaus interessant werden:

What I'm trying to do is use openly gl to do the last step of decoding (colour space conversion) which is about 40 per cent of the decoding process. It might be possible to do motion compensation in opengl too, which is a further 30 per cent saving in cpu use.

I read a paper where someone claimed to do mpeg2 decoding almost fully in an opengl as shader, but there was no method or code examples in any of the papers I've read.

also wenn der opengl vo treiber von mplayer angepasst wurde könnte sich damit durchaus eine Möglichkeit eröffnen.

und weil wir gerade bei benchmarks sind:



Quelle: http://www.loggn.de/raspberry-pi-benchmark-die-beste-sd-karte/

[Jürgen]

Soweit ich weiß, gibt es in MPEG2 keine einzige (De)kompressionsroutine, die h.264 nicht auch enthielte.
h.264 bringt nicht weniger Komponenten mit, sondern definitiv mehr.
Entsprechende Hardware daher ebenso.

Für mich stellt sich das so dar, dass entweder das h.264 Hardware-Codec gezielt gegen Verwendung für MPEG2 gesperrt wurde oder irgendeine Firmware-ähnliche Komponente vorher dafür sorgt.
Jedenfalls muss nach meiner Logik die Hardware technisch grundsätzlich imstande sein, alle Stufen der MPEG2 Dekodierung durchzuführen, sofern man sie richtig füttert.
Hinzu kommt, dass der Chip nicht für den Raspberry Pi entwickelt wurde, und die allermeisten anderen Verwendungen werden MPEG2 sicher erfordern oder zumindest unterstützen.
Aber das Betriebssystem und eventuelle Firmware-Anteile entscheiden darüber, was darauf auch wirklich läuft.
Grundsätzlich kann man davon ausgehen, ältere Formate benötigen stets weniger komplizierten Hardware-Support als neuere.

Das gilt entsprechend auch für Audio.
Allerdings gäbe es dort noch eine weitere Option, digital und RAW durchschieben, statt selbst analog zu wandeln.
In den Grenzen des verwendeten HDMI-Standards, natürlich.

Ich kann mir nicht vorstellen, dass entscheidende Komponenten der Dekodierungs-Steuerung hart im Chip eingebrannt sind, weil das auch den Geräteherstellern zuviele Beschränkungen auferlegte.
Eher geht's, wie gesagt, um das leidige Thema Firmware.

Jürgen

[Dragonix]

Wider erwarten hat heute der DHL Mann geklingelt und mir einen vorbei gebracht
Leider hab ich nun weder eine Speicherkarte noch Zeit, aber ein bischen werd ich damit heut schon noch rumspielen
Falls Ihr Fragen habt, Bilder/was weiß ich sehen wollt, könnt Ihr euch gerne melden!

[mtron]

Falls du mal zeit hast würden mich mp3 decoder benchmarks interessieren.

e.g. für mplayer mit libmad:

Code: [Auswählen]

time ./mplayer -quiet -ac mad -ao pcm:fast:file=/dev/null -vo null -vc null test.mp3
und mit der ffmpeg version des mp3 dekoders:

Code: [Auswählen]

time ./mplayer -quiet -ac ffmp3 -ao pcm:fast:file=/dev/null -vo null -vc null test.mp3
ebenso könnte man bei den mplayer options noch einiges bezüglich Mpeg2 SDTV ausprobieren. kannst du mal vom mplayer build die vo und ao treiber posten?

Code: [Auswählen]

mplayer -vo help -vc help
und für audio:

Code: [Auswählen]

mplayer -ao help -ac help
und dann gegebenenfalls einen mplayer config file basteln (meist unter /etc/mplayer/mplayer.conf bzw. als .mplayer/mplayer.conf)

Code: [Auswählen]

ao=sdl,
ac=mad,
vo=sdl,xv,
framedrop=yes
afm=libmad,
noslices=true
monitorpixelaspect=1
fs=yes
cache=300
font=/usr/share/fonts/SwaRR4nh.ttf
subfont-text-scale=3
menu=no
sws=0
zoom=true
die vo treiber sind vom X window system, also falls du nur auf einem framebuffer unterwegs bist versuche fbdev oder fbdev2 bzw. directfb als vo treiber.

Wie ist denn jetzt der video treiber angebunden? via dkms (Also wrapper a la nvidia/ati binary blobs) oder als reines ko modul?  Grundsätzlich wären auch die standard angaben (lspci -v, dmesg, syslog) interessant

[Dragonix]

Mal schauen

Aber der Reihe nach.
Heut früh dann erst ne SDHC Karte gekauft (SanDisk). Natürlich zu spät gemerkt, dass ich keinen SDHC-Kartenleser hab  ... im Schleppi von einem Bekannten war dann aber einer drinnen, also mal das Debian Image draufgebrannt. Und dann ists eigentlich recht unspektakulär, direkt langweilig - Karte rein, Strom an, fertig. Bootet ohne zu maulen, mit startx kommt eine LXDE Umgebung hoch. Geht alles "einigermasen" flott - am problematischten seh ich hier bislang den Ram: Den vorinstallierten Browser (irgendein Gnome/GTK leichtgewichtiger Browser mit "M" im Namen) + ein Terminal aufmachen und flutsch, schon hat man nur noch 20 MB Ram frei... Nungut, Surfstation solls eh nie werden.

Dann hab ich mich mal dran versucht, das Tastaturlayout zu ändern - für alle nicht Debianer: "dpkg-reconfigure console-data" bewirkt das gewünschte. Dann gibt's aber beim nächsten Hochfahren einen Bug: Er braucht bei zwei "Diensten" sehr lange (http://www.raspberrypi.org/phpBB3/viewtopic.php?f=6&t=5811), Lösung (auch im Thread): "sudo setupcon". Das Problem hängt wohl mit der fehlenden RTC zusammen: Debian verwendet zum erstellen der Keymaps recht langsame Skripte - da die Keymaps dann gepuffert werden, wäre das normalerweise nicht so schlimm. Da aber zu dem Zeitpunkt noch keine Uhr vorhanden ist, werden die Keymaps aber wohl bei jedem Neustarten neu erstellt.

Dann mal mit apt-get update && upgrade alles auf den neusten Stand gebracht, gab hierbei nix weiter erwähnenswertes.

Anschließend hab ich mit apt den mplayer installiert. Dies reicht aber wohl NICHT, um von der Videoengine des R-PI gebrauch zu machen (erstens kann dieser Build des mplayers wohl kein OpenMAX verwenden (Schnittstelle zur Videobeschleunigung) und zweitens muss man, um die Video Enigne überhaupt verwenden zu können, den RAM anders aufteilen (GPU braucht wohl mindestens 128MB RAM hierfür) - soweit bin ich aber dann noch nicht vorgedrungen) [1].

Dann wollt ich mit dem mplayer einfach mal eine mp3 Wiedergeben, und nächstes Problem: Geht nicht! Zum einen: "Could not connect to Socket", dann diverses, dann ein weiteres "socket(): Address family not supported by protocol" - dann viele Infos zur Audio Datei (mplayer halt) und dann vieeele alsa Fehlermeldungen mit einem finalen "Failed to initialize audio driver 'alsa'". Dann probiert ers noch über SDL, scheitert aber genauso. Ich hab mittlerweile rausgefunden, dass der "Audio Test" (hab ihn nicht gefunden) kein Alsa verwendet, sondern auch OpenMAX IL.
Fix: Da der Alsa Audio Treiber noch experimentel ist, wird er nicht geladen - kein Beinbruch wenn man's weiß, also "sudo modprobe snd_bcm2835". Gegen die Socketfehler hilft's aber auch nix, keine Ahnung was der hier überhaupt probiert (Datei ist lokal vorhanden - könnt mir jetzt höchstens LIRC vorstellen). Mal schauen. Hören tu ich trotzdem nix, kann aber evtl auch daran liegen, dass er's versucht über HDMI auszugeben, das kann man über die config Dateie von R-PI/Debian einstellen, mach ich heut aber nichtmehr. Die Wiedergabe hört nämlich sowieso irgendwann einfach so auf (bleibt einfach stehen). Update: Ja, es lag wohl daran, dass R-PI den Ton über HDMI ausgeben wollte. Ändert aber trotzdem nichts daran, dass der alsa Treiber wirklich Buggy ist und die ganze Soundkarte in den Abgrund reißt.



Kurzfristige Ziele: Videobeschleunigung ausprobieren/zum laufen bringen.
Mittelfristige Ziele: LXDE weg, Fluxbox her.
Langfristige Ziele: "Eigenes" Image auf Gentoo Basis (Crosscompile), zumindest wenn ich rausfind wie viele der Treiber nun wirklich im vanilla Kernel sind, auf Patch Orgien hab ich keine Lust. Aber mit Debian werd ich einfach nicht warm   evtl noch Arch ausprobieren.



[1] http://www.raspberrypi.org/archives/592

Benchmarks dauern mir jetzt zu lange... ich geh schlafen   bis morgen


___ 2.6.12
So, hab mich nochmal rangesetzt.
Bekomm desöfteren "DEBUG:handle_hc_chhltd_intr_dma:: XactErr with NYET/ NAK/ACK" und unter diesem Problem http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=7075 leide ich auch. Hoffe mal, mein RPI hat keinen Schlag  
Der erste Fehler trat besonders oft auf, nachdem ich auf einen USB Stick zugegriffen hab/bzw beim Zugriff darauf mit mplayer (<< deswegen gibt's/gab's auch noch keine Benchmarks: Allein das Öffnen (also die Zeit die vergeht, bis mplayer mir verrät welche Decoder er verwendet) dauert ewig!)..
Mitlerweile ist blöderweise auch die Partition voll (das Image hat nur ne 2gb Platte angelegt), kp wie ich die jetzt vergrößere (tune2fs kanns ja glaub blos offline?!)

[ritschibie]

Weil er zu lange auf seinen RaspBerry Pi warten musste, hat ein ungeduldiger Brite auf der Suche nach einer Alternative chinesische Board-Produzenten kontaktiert. Das Ergebnis der Suche ist ein Allwinner-A10-Board, das jetzt für 40 Britische Pfund (ca. 45 Euro) in den Handel kommen soll.

Gooseberry Board

Das als Gooseberry betitelte Board enthält neben dem Allwinner A 10 (ARM-Cortex-A8-CPU mit einer maximalen Taktfrequenz von 1,5 GHz) 512 MB RAM, einen Grafik-Prozessor Mali mit 400 MHz und 4 GB Flash-Speicher. Der Flash-Speicher lässt sich mittels Micro-SD-Karten erweitern. Anstelle eines kabelgebundenen Ethernet-Anschlusses kommt das Board, das auch in Tablet-Computern verbaut wird, mit einem WiFi-Modul, das die Standards 802.11 b/g/n unterstützt.

Über eine HDMI-Schnittstelle werden Monitore und Beamer angesprochen. Tastaturen, Mäuse und andere USB-Geräte lassen sich via Mini-USB-Port und aktivem USB-Hub anschließen. Weitere Schnittstellen sind ein 3,5 mm-Audio-Ausgang, ein aufgelötetes Mikrofon, ein Anschluss für das Netzteil und Taster, um das Board einzuschalten, zu resetten und die Lautstärke zu regeln. Verglichen mit dem Raspberry Pi fehlen die GPIOs und der analoge Video-Ausgang.

Momentan wird das Board mit Android 2.3 ausgeliefert, Android 4 sowie Ubuntu und andere Distributionen, die die ARM-Architektur unterstützen, sollen kein Problem sein. Die Gooseberry-Initiatoren nehmen Interessenbekundungen auf und haben eine erste Gooseberry-Lieferung bestellt, die allerdings nur 10 Stück umfasst. Aktuell sind sie anscheinend dabei, einen Webshop einzurichten, um das Board in den europäischen Handel zu bringen.

Quelle: www.pro-linux.de

[mtron]

sehr gut ist mehr ram & Cortex-A8-CPU aber leider kein Ethernet und nur 1 usb port.

Close but still not there...

[Jürgen]

Finde ich auch.
Gerade ein dann doch recht großes Board sollte nicht mit Schnittstellen geizen.
Und ganz bestimmt werde ich hier für sowas kein dauerhaftes WLAN betreiben.

Mir scheint übrigens auf der Abbildung unten links eine vorbereitete weitere (USB-?)Buchse nicht bestückt zu sein.
Und es sind noch weitere unbestückte Optionen erahnbar, und offenbar auch zwei Flatwire-Slots, wofür auch immer.

Das ändert aber auch nichts daran, dass ich bei solchen Konzepten unbedingt volle Hardware-Unterstützung für h.264 und MPEG2 verlange.
Die Angabe Mali GPU genügt da nicht, um irgendwelche Aussagen machen zu können, denn erstens gibt es diverse Varianten, zweitens handelt es sich im engeren Sinne gar nicht um eine komplette Grafikeinheit, sondern eher um einen 2D/3D Renderknecht, der ganz erheblich von seiner (ARM-)Umgebung abhängt.

[ritschibie]

Auch wenn hier unter den Interessierten keine Begeisterung aufkommt, möchte ich dennoch auf den heutigen, etwas weiterführenden Artikel unter:
http://www.golem.de/news/raspberry-pi-alternative-gooseberry-board-mit-android-1206-92738.html
hinweisen, in dem auch der Link zu einem (noch rudimentären) quelloffenen Treiber für die "Mali"-GPU und der Hinweis steht, dass "Ubuntu" auf dem Board läuft, während es auf dem Raspberry nicht läuft.

[mtron]

ubuntu ist mit einem Cortex-A8 kompatiblen instructrion set kompiliert (=ARMv8). Im RPI ist ein ARMv6 CPU, darum läuft ubuntu auf dem gerät nicht.  

[Jürgen]

Ohne Grafikbeschleunigung würde mir Ubuntu darauf nichts nützen.
Und eine Demonstration von irgendwelchem h.264 Zeugs brauche ich nicht, das glaube ich auch so.

Sollte man aus solch einem Mini-Board einen wirklich sparsamen Ersatz für den üblichen Alltagsrechner erwarten, dann müssten eben die alltäglichen Dinge einwandfrei laufen, wie hemmungsloses und uneingeschränktes Surfen, alle üblichen Audio- und Videoformate samt Flash eingeschlossen, sowie Mailen, Banking, die wichtigsten Office-Aufgaben, Drucken, Scannen usw.
Darf also nicht weniger abspielen können als einer der guten Mediaplayer (WDTV live, Noxon 740 usw.), muss aber zusätzlich als normaler (Linux-)PC fungieren.

Dann könnte nämlich der bisherige Hauptrechner der meisten seiner Aufgaben entbunden werden, sich auf anspruchsvolle Dinge wie Videoschnitt beschränken.
Umkodieren meiner Filme in irgendein Handy-Format ist dabei aber ausdrücklich nicht gemeint...

Bis das gelingt, gehe ich weiterhin genau anders herum vor, versuche den Grundverbrauch meines PC allmählich aber gründlich zu drücken.
Immerhin gelingt das mit modernen Chipsätzen, CPUs und Netzteilen immer mehr, zumal auch meine Erfahrungen mit Energiesparmodi inzwischen deutlich besser werden.

Jürgen