Category Archives: Java

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 😀

Wie man in Java die lokale IP ermittelt

Posted on by

Da das Ermitteln der lokalen IPs über alle Interface angeblich Voodoo ist, hier mal eine Lösung ohne Voodoo 🙂

import java.net.InetAddress;
import java.net.NetworkInterface;

                try {
 			Enumeration networkInterfaces = NetworkInterface.getNetworkInterfaces();
 			while (networkInterfaces.hasMoreElements()) {
 		    	     NetworkInterface networkInterface = (NetworkInterface)networkInterfaces.nextElement();
 		    	     Enumeration ips = networkInterface.getInetAddresses();
 		    	     while ( ips.hasMoreElements() ) {
 		    		// InetAddress ipa = (InetAddress)ips.nextElement();
 		    		String ip = ((InetAddress)ips.nextElement()).toString();
 		    		ip = ip.replaceAll("/", "").replaceAll("%.*$","");
 		    		... HIER mit der IP was machen ... 
 		    	      }
 			}
 		} catch (Exception e) {
 			e.printStackTrace();
		}

Eine kleine Anmerkung dazu. Das ist ja der Cast auf InetAddress, es werden an der Stelle aber IPv4 und IPv6 Objekte zurück gegeben, die sich eben ohne Cast-Fehlermeldung nur als InetAddress verarbeiten lassen. Wenn Ihr wissen wollt, was es ist, ohne eine RegEx über das Ergebnis zu legen, lest einfach die Klasse des Objekts aus:

InetAddress ipa = (InetAddress)ips.nextElement();
log( ipa.getClass().getName() );
String ip = ipa.toString().replaceAll("/", "").replaceAll("%.*$","");

Anstatt getName() kann man auch getSimpleName() oder getType() benutzen, ganz wie es Euch gefällt.

Alternative:

		Enumeration<NetworkInterface> networkInterfaces = NetworkInterface.getNetworkInterfaces();
		while (networkInterfaces.hasMoreElements()) {
		   	NetworkInterface networkInterface = (NetworkInterface)networkInterfaces.nextElement();
		   	
		   	for (InterfaceAddress address : networkInterface.getInterfaceAddresses()) {
		   	    String ip = address.getAddress().toString();
	   		    int netmask = address.getNetworkPrefixLength();
	   		    log( netmask + ip );
		   	    ip = ip.replaceAll("/", "").replaceAll("%.*$","");
	   		}
		}

Da bekommt man auch gleich die Netzwerkmaske mit, ist wohl der bessere Weg 🙂

Signieren von npm Paketen

Posted on by

Zur Einleitung eine kleine Geschichte zu einem Projekt, daß ich mit einem unserer Kunden umgesetzt habe. Da das Projekt mangels Benutzer jüngst eingestellt wurde, ist wohl die Floskel „Es war einmal…“ angebracht 🙂

Die Geschichte von Lord Uglify

Also.. Es war einmal .. ein tolles webbasiertes Firmenspiel für das jede Menge Javascriptcode erzeugt wurde, weil es ja im Browser zu spielen war. Nun sollte das ellenlange Javascript eingedampft werden mit „Uglify“ einem node.js Tool zum Schrumpfen und Verschleiern von Javascriptcode.

Nun sollte jemand Uglify irgendwo installieren und es dafür benutzen. Das war der erste Fehler. Nachdem Node.Js aus dem Repository installiert wurde, tat es natürlich nichts sinnvolles, denn Uglify hat wie so viele andere Node.js Programme, einen Abhängkeitsbaum, der milde betrachtet, bis zum Mond reicht. Mit NPM, dem Node.Js Paketmanager, kann man die Abhängkeiten befriedigen, glaubten wir zumindest. Das war Fehler Nummer 2. Denn die Abhängigkeiten von den Abhängigkeiten der Abhängigkeiten von den Abhängigkeiten der Abhängigkeiten von den Abhängigkeiten die keine Ende nehmen wollten, brauchten geschlagene 30 Minuten sich zu installieren. Na gut, jetzt wird es ja wohl endlich starten. Das war der dritte Fehler.. allerdings dann auch der letzte, weil ich keinen Bock mehr hatte mich von so einem Witzprogramm verarschen zu lassen.

Ich habe dann einfach „jsmin“ genommen: klein,schnell,effektiv,läuft überall, keine Abhängigkeiten und einfachst zu bedienen. Kurzum, ein Programm wies sein sollte.

Was hat das jetzt mit dem Signieren von Paketen zu tun ?

Tja, wie man oben lesen kann, sind Node.js Programm extrem modularisiert, sprich, mal eben selbst was schreiben ist praktisch nicht, weil man erst mal jede Menge an Paketen installieren muß. Im Gegensatz zu Java, wo eine Fülle von Klassen mitgeliefert werden, kommen die Pakete per NPM ins Projekt rein.

Diese Pakete sind nicht signiert, die von Java zwar auch nicht, aber die kommen ja auch aus einer definierten Quelle gleich mit. Signieren ist im NPM auch nicht vorgesehen. Daher hat jemand in Australien ( Details bei Heise ) gemeint, er müßte das ändern und hat ein Signaturtool für Node.js Pakete gebaut.

Die Begründung war, das neulich diverse Pakete aus dem NPM Repo auf merkwürdige Art verschwunden sind, zwischenzeitlich durch gleichnamige Pakete ersetzt wurden, um dann funktional mit den früheren Paket  zu kollidieren, sprich, was anderes zu machen, als das Original.

Da jeder Pakete in das NPM Repo laden kann, würde das Signieren also den Prozess mit den Paket-Abhängigkeiten sicherer machen, weil wenn sich so ein Vorgang wie eben beschrieben passiert, würde ja die Signatur nicht mehr passen und dem Entwickler würde dann auffallen, daß da gerade was schief läuft. Nun, das mag sein.

Das eigentliche Problem

Das eigentliche Problem löst das natürlich nicht: 100 Abhängigkeiten im Projekt, und den von den Entwicklern hat noch nie einer gehört. Ob die da Schadcode einbauen oder nicht, kann man nicht an der Tatsache einer gültigen Signatur erkennen.
Alles was dieses Signaturen bieten, ist ein Verwechslungsschutz, das aber auch nur, wenn der lange verschollene Author doch nochmal gefunden wird 🙂

Ich halte das für nichts, was man an die große Glocke hängen sollte, denn das hier kann man damit nicht vermeiden:

https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

Es lohnt sich bis zum Ende zu lesen, weil Ihr sonst einen falschen Eindruck von der Sache bekommt. Wenn Ihr damit fertig sein, hier ein Zitat von „blog.fefe.org“ unser aller Weltverschwörungsguru 😉 passend zum Thema :

„[l] Ein Einsender kommentiert die Webfrontend-Warnung:

  • lass‘ uns als kleine Veranschaulichung, wie breit und tief die Güllegrube npm sein kann, eine Webanwendung anfangen. Natürlich mit Angular und dem aktuellen Standard-Build-System @angular/cli:

    $ npm i @angular/cli
$ node_modules/.bin/ng new webkid --directory=.

    Das Ergebnis ist ein Skeleton mit einer Hello-World-Seite und:
    31 direkten Abhängigkeiten
    974 Abhängigkeiten insgesamt
    305 MB in node_modules

    Davon sind 158 Pakete Duplikate von bereits installierten Paketen mit einer anderen Versionsnummer. Bei so vielen Abhängigkeiten ändern sich die Zahlen natürlich schnell, also am besten sofort anfangen mit dem Audit!“

    “ [Ende des Zitats]  Aufgrund der Struktur von Fefes Webseite, müßt Ihr selbst den „Wed Jan 10 2018“ suchen 😉

 

Dem Kommentar kann man sich nur anschließen. Keine Signatur der Welt macht das irgendwie sicherer!

Davon ab, keine Ahnung wie jemand auf die Idee kommt, dafür zu Entwickeln. Da braucht man ja Stunden um anzufangen. Leute nehmt was vernünftiges, nehmt Java. Eclipse auf. Neues Javaprojekt aufmachen und einfach losschreiben 😉

Java kommt übrigens leer mit knapp 105 MBye aus 😉 und das wäre dann auch für alle Projekte und nicht PRO Projekt 😀

Quelle: heise.de – Open Source Tool zum Signieren von npm Paketen veroeffentlicht