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 đ
Da der Client normalerweise vom C&C direkt auf dem C&C Server benutzt wird um den Ton abzuspielen, kommt der bislang ohne eigene UI aus, schliesslich spielt er nur ab, was man im C&C ohnehin sieht.
Ihr seht hier Aussetzer des Netzwerkes alle 15 Sekunden. Das lies sich nur mit einem Reboot fixen und betraf alle Apps auf dem Handy, auch SSH und Ping. Die Aussetzer sind aber nicht neu. Die sind immer mal wieder seit ich das Handy bekommen habe aufgetreten.