Fedora: Wie man ProjectM kompiliert

Wer wissen will, wie er für Fedora ProjectM kompilieren kann, der soll weiterlesen. Alle die Epilepsie haben, sollten das nicht in Betracht ziehen, das ist übles Farb & Flacker Foo, ich glaube einige der Effekte wollten mir unterschwellige Botschaften aus dem Universum unterjubeln 😉

Erstmal Devkrams installieren

Neben dem, was man als normale C Entwicklungsumgebung sowieso braucht, GCC, AutoMake etc. kommen folgende Pakete zum Einsatz:

glm-devel
libICE-devel
libSM-devel
libXt-devel
mesa-libGLU-devel
libXv-devel
qt-devel
glm-devel
rhash
cmake-data
cmake
qt5-rpm-macros
qt5-qtbase-devel
pulseaudio-libs-devel

einfach mit DNF installieren.

Sourcecode clonen

Den Source bekommt man von GitHub. Dazu macht man sich erstmal ein leeres Verzeichnis ..

mkdir -p Programmieren/git/

.. dann hinwechseln ..

cd Programmieren/git/

… und Source clonen :

git clone https://github.com/projectM-visualizer/projectm.git

Jetzt warten, kann dauern, sind fast 20.000 Bruchstücke die da ankommen. Dann wechseln wir in das Projekt:

cd projektm

und lassen autogen arbeiten:

./autogen.sh

jetzt konfigurieren. Entgegen der Anleitung muß man allerdings extra angeben, daß QT gebaut wird, sonst nix PulseAudio-Version 😉 GLES und Threading kann man, muß man aber nicht machen. Hat den Vorteil das mehr Power rauskommt, denn das schluckt einiges an Leistung. Eine schwache CPU kann da stark von profitieren.

./configure –enable-gles –enable-threading –enable-qt

noch ein make und man ist durch. Mit make install kann man das installieren, aber wer sich das nicht ans Bein binden will, weil üblicherweise gibt es nämlich kein uninstall bei sowas 😀 , der findet z.b. die PulseAudio Version hier ./src/projectM-pulseaudio/projectM-pulseaudio .

Nach reiflicher Überlegung, habe ich dann rm -rf ~/.projectM projectm gemacht 😀 Es war nicht eine brauchbare Visualisierung dabei.

Fedora 28: Planet Crash

Mit Fedora 28 ist es grade, als wenn man in einen Topf Farbe getreten ist und jetzt die Farbe überall verteilt. Egal wo man hinschaut Bugs, Bugs und noch mehr Bugs.

Heute:  ProjectM-PulseAudio

Für alle die ProjectM nicht kennen, das ist ein Audio-Visualisierungs-Plugin, das langweilige Musikabende optisch aufhübschen soll, idealerweise im Takt der Musik.

Scheinbar ist das bei Fedora auf dem absteigenden Ast gelandet, meint, es ist als verweist markiert. Es gibt also keinen Maintainer und Redhat muß selbst ran, und genau da haperts bei Redhat grade. Das Problem liegt in der Speicherverwaltung, was zu einem „Double Free“ Fehler führt. Für Nichtentwickler, daß bedeutet, daß ein Speicherbereich zwei(++)mal freigegeben werden soll. Das ist ein schwerwiegender Programmierfehler und wird besonders oft von C-Entwicklern gemacht, weil das Speichermanagement von C schlicht nicht vorhanden ist. Einem Java-Programm kann das nicht passieren, da die JVM das Speichermanagement komplett übernimmt.

Ich wette Fefe, wüßte jetzt, auf welchem Platz der häufigsten Programmierfehler in C der DoubleFree steht, aber ich kann nur raten. Gefühlt in den Top 3, direkt nach Buffer-Overflow und „Zeiger auf Zeiger verdengelt“ 🙂

Also falls Ihr mit ProjectM rechnet, seid nicht enttäuscht, wenn es nach 5 Sekunden crasht.

Update:

Nachdem ich mit auf Github einen BugReport erstellt habe, stellt sich raus, daß Fedora eine uralte Version zur Verfügung gestellt hat. Es wird dringend dazu geraten, ProjectM selbst zu kompilieren, nur ist das, wie sich zeigt, nicht so einfach. Das Configure Script vermeidet bewußt zu sagen, was ihm zum Ausführen am QT Libs genau fehlt, ohne QT unterdrückt das make einfach mal die Fehler beim Bau von projectM-pulseaudio und sagt am Ende, daß alles fehlerfrei geklappt hat. Natürlich ohne irgendwas brauchbares erstellt zu haben.

Das kann man zwar nicht direkt als Bug bezeichnen, zeigt aber auf, wo da wohl das Problem seitens Redhat liegt, eine aktuelle Version zusammen zu häkeln.

Aus der Schmunzelecke von Bugzilla

Für Euch mal was zum Schmunzeln, das erlebt man auch nicht so oft, daß sich der Maintainer bei den Bugreportern dafür entschuldigt, in den Urlaub gefahren zu sein 😉

--- Comment #3 from Zdenek Dohnal <zdohnal@redhat.com> ---
Hi,

thank you for reporting the issue! I'm deeply sorry for inconvenience, I pushed
the update without cross checking if new net-snmp is already in the stable (I
wasn't able to add hplip to net-snmp update) and I went on vacation after that.
You can install previous version from koji for now
https://koji.fedoraproject.org/koji/buildinfo?buildID=1163784 .

Der Fall stellt sich so dar:

Der Maintainer von hplip, hat als Abhängigkeit net-snmp drin und haut sein Update ins Stable Repo, ohne zu checken, ob den auch die Version von net-snmp im Stable ist, die er braucht. Wars nicht, also hat DNF zu Recht rumgeheult, daß es nicht updaten kann, weil gibt es nicht ja nicht im Repo, was das Paket so braucht. Das kommt übrigens öfters vor, als man denkt. Sind halt alles nur Menschen 😀 Aber die Entschuldigung im Bugtracker ist ein Unikum 😀

Falls Euch das auch mal unterkommen sollte, ich hab die neue Version von net-snmp dann im UPDATES-TESTING Repo von Fedora vorgefunden und ein : dnf –enablerepo=updates-testing update net-snmp* hats dann gelöst. Da müßt Ihr dann natürlich die Euch fehlende Abhängigkeit benutzen, nicht net-snmp 😉

g-dbus-error-quark,4

Nein, das Blog hat keinen technischen Fehler 🙂 „g-dbus-error-quark,4“ ist die Fehlermeldung von Gnome-Disks, wenn man auf eine Kingston 64 GB SD Karte ein Image kopieren möchte, aber Gnome-Disks was dagegen hat 😉

„Fehler: g-dbus-error-quark,4“

Weihnachten ist durch und da muß man natürlich mal seine Geschenke ausprobieren. Also lud ich ein Raspbian Image runter und wollte auf die neue Kingsten 64 GB SD Karte schreiben. Das Laufwerke Tool von Fedora sollte das aus dem FF können, kann es aber nicht. Es gibt nur die Fehlermeldung „… dbus.. freedesktop … did not reply.. g-dbus-error-quark,4“ aus und semmelt intern gleich mal dergestalt ab, daß die GUI geleert wird 😀 Ein Fall für Bugzilla 😉

Jetzt bringt uns Bugzilla natürlich keine Hilfe, also müssen wir was anderes probieren:  „fdisk -l“ listet uns alle Geräte auf, die man Partitionieren und damit potentiell ein Image draufschreiben könnte. Der SD Cardleser des Laptops hat dann /dev/mmcsd0 als Devicenamen ausgewiesen. Jetzt kann man mit fdisk keine Images auf Platten oder SD Karten schreiben, also brauchen wir noch so einen Dino unter den Linuxkommandozeilentools: dd .

Die Anwendung ist dann recht einfach: „dd if=~/Downloads/DeinPi.img of=/dev/mmcsd0 status=progress bs=10MB

Eine Weile später ist das Image dann anstandslos auf die Karte geschrieben und so man ein Raspbian ist, bootet es auch von der Karte \o/

 

LAHA jetzt auch auf Raspberry PI

Jetzt ist es also passiert, die LAHA Multiroom HomeAudio-Lösung läuft auf der Zielplattform Raspberry PI.

Was war jetzt LAHA nochmal?

Kurzform: Damit kann man Audio an mehrere Endgeräte streamen … verteilen, so daß es überall im Gleichklang erschallt. Hervorgegangen ist das aus einer einseitigen Wette mit den Heise Redakteuren, das man das auch ohne Bäng & Teufelschen Co. mit OpenSource hinbekommt : LAHA – Netzwerklautsprecher mit Linux . Wie sich herausgestellt hat, geht das auch, nur leider nicht ganz so wie anfangs geplant. Das es trotzdem geht, bedeutet natürlich einige Einschränkungen oder Umstellungen.

PulseAudio

Wenn man PulseAudio mit einem römischen Gott vergleichen wollte, wäre es Janus, der Gott mit den zwei Gesichtern. Auf der einen Seite ist PulseAudio echt super einfach, z.b. beim Abnehmen des Sounds vom Player und dem ins Netz stellen, auf der anderen Seite könnte ich dem Entwickler auch gern mal eins reinwürgen, weil die interne Latenzkontrolle Ihren Job nicht macht. Da letzteres nicht sauber klappt, könnte man auf AlsaPlay ( aplay ) ausweichen, aber das benutzt, sobald PulseAudio da ist, richtig geraten, PulseAudio als Backend, womit die Latenzfalle wieder da ist … ächtzzzz. Man hats nicht leicht mit der OpenSource-Plattform 🙂 Es nutzt ja auch nichts, daß es Open-Source ist, wenn bei so komplexen Dingen wie PulseAudio Modulen/Programmen zwar der Source lesbar ist, aber auf 1000 Zeilen Code genau 2 Kommentare kommen und dazu grober C UnFoo getrieben wird.

Das Raspberry PI

Nachdem Android und der lokale PAPLAY Backend soweit waren, daß man darüber was abspielen konnte, ohne das es gleich sofort zusammenbrach, war gestern das Raspberry PI dran. Eine genervte Viertelstunde brauchte es schon um das RasPI Image auf die 64GB SD zu bekommen, dazu morgen mehr, aber am Ende war das Pi dann doch kooperativ, bis .. ja bis PulseAudio installiert wurde 🙁 Das lief zwar auf dem PI und mit den nötigen Zusatzprogrammen war das auch nett, aber, und das ist entscheidend, die PI Devs haben der PulseAudio-Welt den Hardwarehack vorenthalten, mit dem Sie den Sound auf den Kopfhöreranschluß umlegen. Ums kurz zu machen, solange PulseAudio installiert und aktiv ist, geht das nicht über die Kopfhörerbuchse, sondern immer über HDMI raus, egal was die Oberfläche sagt.

Da gab es natürlich nur eine Lösung: Back to the Roots aka. PulseAudio wieder löschen, rebooten und Alsa als Backend benutzen. Wenn man dann dem PI erzählt, daß es den Kopfhörer nehmen soll, dann geht das auch.

Der Stand der Dinge

Wir haben jetzt also PI Playback und das auch synchron mit dem Desktop PC und Android. Android ist auch so eine Krankheit für sich, aber das nur neben bei. Es gibt schon Beweisvideos, allerdings war es bislang für Filmaufnahmen zu dunkel, Ihr müßt Euch nicht mehr gedulden, unten ist ein Video mit 4 Geräten zusehen. Damit Ihr Euch schon mal ein Bild davon machen könnt, wie das funktioniert, hier selbiges aus der LAHA Präsentationsfolie :

Der Aufbau von LAHA als Flußdiagramm

So war das bis gestern angedacht, nun muß der RasPi Teil aber auf ALSA als Backend umgebaut werden, weil PulseAudio ja nicht kann 😀