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 😀

LAHA und die Latenzfalle

Kleines Update zu LAHA, dem Multiroom Sound und PulseAudio.

Stand der Dinge

Wie man es drehen und wenden will, die fertigen Tools zum Abspielen von PCM Sound haben alle irgendeine Macke.

PAPLAY benutzt PulseAudio. Das ist praktisch ein Todesurteil für eine stabile Latenz.
APLAY   benutzt Alsa, das defaultmäßig … PulseAudio benutzt. Siehe erstens 🙂
*JACK*  nun Jack möchte gern alleine tätig sein, ohne Konkurrenz. Fällt auch aus.

Da APLAY und PAPLAY per Default einen PA Stream zum Abspielen benutzen, haben beide in der Form das gleiche Problem: Die Audiolatenz des Playstreams steigt mit der Zeit an. d.b. alle anderen Geräte müßten mitwandern. Blöd nur, das Androids gar keine Latenzwanderung haben und selbst wenn Sie es hätten, wäre das eine blödsinnige Lösung. Jetzt fragt Ihr Euch natürlich: was labbert der da? Da muß man jetzt weiiiiiit ausholen.

Also, wenn man mit PAPLAY Sound ausgibt, geht PAPLAY zum PAServer und sagt dem, das DER eine Latenz wählen soll. Das macht der dann auch, nachdem die ersten Daten geflossen sind und die pegelt sich mit 16Bit Stereo und 48000″hz“ bei rund 1,9s ein. Richtig gelesen 1,9 Sekunden. Nach 40 Minuten sind wir bei knappen 5 Sekunden, wenns dumm läuft. Wenns gut läuft bei 2,4s . Das entscheidet PA selbst, ich nehme an, nach internen Fehlberechnungen aller gestarteten, gestoppten, bewegten etc. Streams die auf dem System drauf sind. Ich hab es noch nicht im Source gefunden. Es ist eigentlich das Ziel eines Audioservers die Latenz niedrig zu halten, aus irgendeinem Grund, ist dem PA-Latenzalgorithmus das egal.

Wenn man jetzt denkt, daß der Befehl ja eine OPTION für die gewünschte Latenz hat und sich schon freut, daß die dann ja als Ziel eingehalten wird .. ähm ja, also wie soll ich das Schreiben ohne verklagt zu werden??? Lieber nicht, hier ein Beispiel: 500ms angegeben, Latenz beginnt bei 320ms und wandert pö-â-pö so Richtung 500ms, durchbricht den Median, und verschwindet alsbald jenseits von Gut und Böse im Sekundenbereich.

Wenn man auf die glorreiche Idee kommt, da das anzugeben, was der Algo vorher selbst ausgerechnet hat, dann bekommt man nicht 1,9s , nö, mehr so 1s+- und dann kommt das gleiche Spiel wie vorher bei 500ms.
Ja, man könnte jetzt die PAPLAY-Routine kapern, den anderen Geräten die Latenzen mitteilen und denen somit zu einem Sync verhelfen. ABER.. die Latenz wird ja immer größer, was bedeutet, daß bei jedem neuen Sync mehr Zeit vergeht, bis man was hört. Also auch mal 5 Sekunden schwarzes nichts. Das ist hochgradig Inakzeptabel.

Bugreports sind raus, werden nicht helfen, weil (C) endet 2006 . Sieht nicht so aus, als wenn da wer dran arbeitet.

Kommen wir zu ALSA

APLAY kann ALSA-Devices direkt ansprechen. Warum nutzen wir dann nicht APLAY, statt PAPLAY ? Gesagt, getan. Versuchts mal, viel Glück dabei. Das geht mit etwas Glück genau einmal und auch nur auf einem Device, aus das PA grade nichts ausgibt. Ist auch klar, weil PA ja ALSA als Unterbau hat. Wir erinnern uns, daß PAPLAY 1,9s Latenz hatte. APLAY, wenn man ein Device findet, das geht, hat 0ms und das Startdelay ist nicht ganz so funktional, wie sich APLAY das wünscht aka. auch buggy. ABER, 0ms sind cool, weil Android auch 0ms haben kann, ohne dabei drauf zu gehen. Der Lesezugriff für Netzwerkdaten für „16 Bit Stereo 48k“ auf einem Android liegt bei 1ms. d.b. nimmt man ALSA als Player und bekommt das Device frei, hat man eine echt geile Latenz von 1-2ms und das hört man nicht!

Der Resync

Jetzt gibt es allerlei Hürden, die man umschiffen muß. Androids fliegt das eigene Multitasking um die Ohren, da fängt der Ton dann an zu stottern. Vorwarnung : keine. Gegenmaßnahmen: derzeit unbekannt.Das funktioniert auf dem Desktop etwas besser.

Bei 0ms Latenz ist der Resync instant, da könnte man versucht sein, einfach pauschal alle paar Sekunden mal helfend durch einen Socket.close();Socket.connect() einzugreifen. Könnte klappen, muß nicht.Ist aber eine Option, wenn der Wiedergabetask das nicht merkt. Geheimtip: Vorsicht vor doppelten Daten im AudioBuffer. Vergleicht mal, ob Ihr nach dem connect()+read() einen Teil davon schon habt und schmeißt den raus.

LAHA

Unser ControllCenter steuert jetzt bereits beliebig viele Devices, kann Audiostreams von laufenden Apps kapern, z.b. MPV, FireFox etc. , hat diverse Backends zum Abspielen auf dem Desktop, könnte verschiedene Musikplayer als Quelle nutzen und damit auch Last.FM, Spotify etc. realisieren. Er verschiebt Metadaten, findet neue Geräte im Netz, erlaubt Endgeräten mit Screen ihn fernzusteuern und hat bereits erfolgreich ein Handy als Drahtloskopfhörer für Videos laufen gehabt. Dank MPVs negativer Latenz und der frei einstellbaren Endgeräte Latenz, kann man alles perfekt ausrichten 🙂

Wir sind also auf dem richtigen Weg. Ob das allerdings vor Weihnachten 100% zuverlässig läuft, kann ich nicht garantieren. Trotz des ganzen Frustes mit den Bugs der Anderen, hat das Projekt endlich mal wieder Spaß beim Programmieren beschert. Und das ist doch, weswegen man es tut, oder nicht 😀

Multi-Netzwerk-Lautsprecher mit Linux

Wer den kleinen Rant über die selbstverschuldete Unselbstständigkeit der Heise-Redakteure gelesen hat, und aufmerksam am Ball geblieben ist, dem seit hiermit mitgeteilt, daß ich die geäußerte Drohung wahr gemacht habe 🙂

War jetzt nicht so richtig schwer

Ich habe ein Latenzgleiches Playback von QMMP an 3 Abnehmer realisiert – mit Bordmitteln!

PulseAudio-LautstärkenkontrolleDa ich natürlich nur begrenzt Rechner habe, habe ich als Abnehmer auch die Lokalen Audioschnittstellen benutzt (oben im Bild)  um die Latenzgleichheit zu testen.

Ein Laptop im WLAN diente als Kontrolle und es klappt bislang 1a 🙂

Ich werde jetzt wohl eine Steuersoftware bauen, die die nötigen Befehle kennt und Einstellungen bereitstellt, aber das ist kein Hexenwerk mehr, sondern reine Fleißarbeit.

PulseAudio und WLAN-Technik aus der POST-Avengers Ära machen es möglich.

Android ist schneller

Eine Probe mit Android als Abnehmer war auch erfolgreich, aber nicht synchron. Liegt vermutlich an dem kleineren Buffer der App im Vergleich zum PC-Programm. Da ich den Sourcecode habe… 😀 Ich muß da eh ran, also kein Aufwand.

@Heise: Told you so! OpenSource rulz.

Schaut mal in einige Wochen rein, obs was nettes zu Weihnachten für Euch gibt 😀

Falls einer eine praktikable Idee hat, wie man ein Fabrikneues Raspi in ein WLAN ohne Tastatur und Monitor bekommt ( WPS-Taste z.b. ) dann findet Ihr im Haupt-Impressum eine Kontaktemailadresse.

Kleine Anmerkung

Für Videos abspielen braucht man einen Player wie MPV mit dem man die -2900ms Audio/Videoversatz ausgleichen kann.