Category Archives: Audio

PVA: unerwartete KDE Connect Interaktion

Posted on by

Hi, völlig überraschend stellt sich heraus, daß Funktion wie geplant funktionieren, aber unerwartete Dinge offenbaren. Die Medienwiedergabe ist so ein Fall.

PVA: unerwartete KDE Connect Interaktion

Ich höre gerade übers Handy Musik und wollte Carola ein paar Reaktionstests unterziehen, als sie nicht reagierte 😐 Da wurde ich natürlich nervös, weil das untypisch war. Ich habe ja erst gedacht, daß die Soundausgabe auf den anderen Kopfhörern liegt, aber das war nicht der Fall. Sprach man sie direkt mit Namen an, reagiert die Kleine wie sie sollte.

Ein neues Mysterium? 🙂

Leider nicht, denn zur Steuerung meines Handies hatte ich KDE Connect auf dem PC gestartet. Ich zeige Euch mal die Topologie:

KDE Connect hat sich auf dem PinePhone die von Lollypop zur Verfügung gestellte MPRIS2 Schnittstelle geschnappt und die über das Netz genutzt. Soweit, so beabsichtigt 🙂 Tatsächlich ist KDE Connect auf dem PC noch einen Schritt weitergegangen und hat auf dem PC die MPRIS2 Schnittstelle von Lollypop exponiert und die hat nun wiederum Carola gesehen und benutzt.

Das bedeutet, ich kann jetzt auf dem PC mit Carola die Musik per Sprache steuern, obwohl beide nichts von einander wissen können, weil KDE Connect die Schnittstellen bridged 😀 Wie geil ist das denn bitte ?!!?!?!?!! 😀

Warum schwieg sie jetzt?

Weil sie, wenn eine Medienwiedergabe läuft, nicht auf den gesprochenen Text reagieren soll. Das ständige dazwischen quatschen würde einfach nur nerven.

Fedora: Pinephone als LAHA Client

Posted on by

Hallo Linuxphone-Fans,

Ja, LAHA geht 😀 Es gibt aber Tücken im Pinephone. Das beste, es läuft bereits mit Pipewire 😀

Fedora: Pinephone als LAHA Client

Ich wollte das schon lange ausprobieren, aber mit den ganzen bisherigen Pineproblemen bin ich da nicht zu gekommen. Heute hat sich das geändert.

in Grün der Audiodatenstrom vom C&C Center ins Pinephone.

Der Shellclient macht jetzt nicht direkt was her, zumal er nur ein Kommando ist:

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.

Das könnte sich jetzt aber ändern, wenn ich etwas mit der LibHandy vernünftige Oberflächen für Pine bauen kann. Dann sollte es am Ende eine der Androidversion ähneliche Funktionalität haben. Ob ich es hinbekomme, daß die JAVA Pakete von einem Clienten sauber gelesen werden können, wage ich aber zu bezweifeln, daher wird wohl auf eine Java-Client-C-GUI Mixanwendung hinauslaufen.

Läuft auch mit Pipewire

Ganz ohne mein Zutun, funktioniert die Anwendung out-of-the-box auch mit Pipewire. Da scheint sich jemand bei der Kompatibilität zu PulseAudio Mühe gegeben zu haben. Da PA aber nur ein Pirewireclient ist, war das so gedacht. Wenn Ihr das austesten wollt, braucht Ihr neben java-1.8.0-openjdk für LAHA auch nmap-ncat und die pulseaudio-utils.

Spezielle Anpassungen sind für LAHA nicht nötig. Einfach so starten: java server/Server

Beim Test sind dann allerdings andere Probleme des Pinephones aufgetreten: Netzwerkaussetzer.

Oben im Bild seht Ihr ja einen kontinuierlichen Datenstrom zum Pine, das ist aber nicht immer so:

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.

Bugreport ist raus.

 

 

 

Kernel 5.3.16 mit HDMI-Audio Problemen

Posted on by

Na klingeln Euch auch noch die Ohren? Mir tun die jetzt noch weh! Wer eine NVIDIA Grafikkarte und einen aktuellen 5.3.16 Kernel einsetzt, der sollte jetzt kein HDMI benutzen.

Kernel Regression durch Patch für eine andere Regression

Es ist immer blöd, wenn der Fehlerfix mehr Probleme macht, als er behebt. So geschehen im neuen 5.3.16 Kernel, wenn man eine NVIDIA Karte hat. Wie Takashi Iwai von Suse dazu schreibt:

The commit e38e486d66e2 („ALSA: hda: Modify stream stripe mask only when needed“) tried to address the regression by the unconditional application of the stripe mask, but this caused yet another
regression for the previously working devices. Namely, the patch clears the azx_dev->stripe flag at snd_hdac_stream_clear(), but this may be called multiple times before restarting the stream, so this
ended up with clearance of the flag for the whole time.

Hat da wohl jemand eine Kleinigkeit nicht bedacht aka die falsche Stelle gepatched 😉 Als Resultat fallen einem fast die Ohren ab, weil die Lautstärke des HDMI Streams so derbe übersteuert klingt, daß selbst 2% Lautstärke nur als Lärm bezeichnet werden können. Ich vermute das hier die Audiodaten im falschen Format angeliefert werden, wo alles was leise wäre, extrem laut ist z.b. LE statt BE Sortierung der Bits.

Die Lösung

Natürlich gibt es eine einfach Lösung für das Problem: 5.3.15 booten oder bis zum nächsten Kernelupdate kein HDMI benutzen 😉

Update:

Laut Laura Abbot von Red Hat wird der Fehler nicht mehr in der 5.3er Serie behoben, was ich bislang bestätigen kann, denn der 5.3.18 hat die gleiche Macke. Es soll stattdessen gleich der 5.4.0 Kernel gebaut werden. Frau Abbot bemüht sich darum, daß der Patch bereits in 5.4.0 einfliesst.

Der Soundbug ist auch unabhängig von den Treibern, aber das habe ich nicht anders erwartet.

Update: wurde in 5.4.5 gefixt.