Linux und die Anker Soundcore Life A1 In Ear Bluetooth Earbuds

Normalerweise wenn man Gerätewerbung macht, setzen Blogs einen Affiliatelink und möchten gern an der Werbung verdienen, hier geht es nur um die Frage „Wie laufen denn die Anker Soundcore Life A1 mit Linux?“ 😉

Linux und die Anker Soundcore Life A1 In Ear Bluetooth Earbuds

Als ich vor 7 Wochen die Ear Buds gekauft habe, war ich mir nicht sicher, ob es die Richtigen waren, oder ob die Schmalen, die wie In-Ear-Kopfhörer ohne Kabel aussehen, besser wären. Aber bei dem Preis von 49 € incl. Versand bei Ebay  konnte man nicht so viel falsch machen und die Tests für die Buds waren auch gut. Normalweise kosten die ~90 € , also ein Schnäppchen und das direkt von Hersteller 😀

<unbezahlte Werbung>  Guter Sound, Handsfreemode, Headsetfunktion, lange Spielzeit von 9h, 3 komplette Ladevorgänge per Gehäuse und nur 49 €. Wer noch keine Anker A1 hat: Kaufen! Kaufen! Kaufen! </unbezahlte Werbung> -> Link zur Produktbeschreibung bei Geizhals <-

Das erste System das ich ausprobiert habe, war zwar Android, aber da liefen die sofort. Da meine anderen Linuxgeräte durch die Bank Bluetooth deaktiviert haben, mußte ich dort BT erstmal aktivieren und ggf. Blueman nachinstallieren. Warum Blueman wichtig ist kommt am Ende.

Die Inbetriebnahme bei Linux

Natürlich fängt man mit dem Koppeln der Geräte an. Das ist leicht, denn nach dem Rausnehmen aus dem Ladegehäuse gehen die Buds sofort in den Kopplungsmodus und sind sichtbar. Alles was man machen muß ist nach neuen Geräten in der Nähe suchen und dann verbinden. Klappt das nicht sofort, dann einfach wieder ins Gehäuse tun und nochmal rausnehmen.

Auf dem Surface mit Gnome war es in Sekunden erledigt, nachdem BT wieder im System aktiviert wurde. Falls Ihr neugierig seid, weil ohne laufendes BT der Hack des Controllers nicht geht, was sicherer ist, denn auch BT Controller kann man hacken, weil die Firmware Lücken hat. Da spielt es keine Rolle was es für ein OS ist.

Die Soundqualität war sofort super. Jetzt müßt Ihr wissen, daß die Buds zwei Betriebsmodi haben, einmal für Musik und einmal als Headsetersatz. Im Musikmodus hab Ihr Stereo CD Qualität auf den Ohren, mit einer leichten Latenz von ~1s . Die Latenz merkt man nur, wenn man ein Spiel spielt oder einen Film sieht. Sonst fällt es nicht weiter auf.

Linux ist echt clever, aber nicht clever genug 😉

Wenn man mit den angeschlossenen Buds in eine Videokonferenz geht, dann schaltet Pipewire sofort in den Headsetmodus um. Ja, richtig gelesen, Pipewire/PA regeln das alleine, weil die Videokonferenzsoftware ( Jitsi Meet via Firefox ) dem Audiosystem mitteilt, daß es einen Voicestream liefert. Coole Sache, außer Ihr seid zuversichtlich, daß Musik hören und Videochats schon zusammen funktionieren werden. Was soll ich sagen, tun sie nicht 🙁

Wenn man (noch) Musik hört und die Konferenz anfängt springt der Audiotreiber zwischen HQ Mode (Musik) und Bi-Directionalem Headsetmodus hin und her. Man versteht nichts mehr, weil andauernd die Verbindung abbricht, weil sie neu ausgehandelt wird.

Lösung: Musik ausmachen.

Ich weiß ja nicht, wie Eure Videokonferenzen so ablaufen, aber bei Linux am Dienstag, ist morgen übrigens wieder soweit, werden auch mal Medieninhalte mit Ton gezeigt, weil wir zeigen ja Linuxprogramme im Einsatz 😉 In dem Augenblick werden Eure Buds unbrauchbar, weil Pipwire/PA dabei versagt die Situation zu erkennen und halt nur im Headsetmodus zu operieren. Da wünscht Ihr Euch den Kabelkopfhörer zurück.

Und sonst so?

Mit dem Fedora Pinephone gabs anfangs Probleme, da brach die Verbindung laufend zusammen. Sehr, sehr viel öfter als tolerierbar war. Aber dank den Fedora Pipewire Maintainerteam und einem bereits bekannten Patch für das Problem, war das recht schnell gelöst. Allerdings müßt Ihr Euch daran gewöhnen, daß mit BT Kopfhörern immer mal eine Unterbrechnung drin ist: Intergalaktische Störfelder, Ampeln, Sender für Autonomes Fahren, Gammablitze… sucht Euch was aus 😉

Da das i.d.R. nur 0-1x pro Stunde passiert, ist das nicht so tragisch. Nerven tun so Intermezzos wie Matrixbenachrichtigungen auf dem Android oder Anrufe, da ist nämlich der Sound weg. Auf Linux ist das anders, weil das da alles Musikstreams sind, die kommen gleichzeitig rum, soweit das auszuprobieren war.

Auf dem Pinephone gabs dann auch das Problem, daß der BT Scanner im Gnome-Control-Center nicht funktionierte, weil der ganze Tab abgesemmelt ist .. OOM 😉 Da half dann BlueMan  bzw. bluetoothctl  in der Shell. Blueman hat auch das nette Feature, daß es die Datenstrombandbreite vom und zum BT Gerät anzeigt.

Getestet habe ich auf drei Geräten mit Fedora Rawhide ( F37/38 )  und Fedora 35. Auch mein BTloser Desktop PC spurte entsprechend… ups… sagte ich BTlos? Naja, dank USBIP war auch der PC in der Lage mit den Buds zu sprechen 🙂  Ich sehe gerade, den Linux am Dienstag Vortrag muß ich doch glatt mal hier in Schriftform posten 🙂 Auch wenn das wegen dem einfacheren Transport des BTControlers wünschenswert gewesen wäre, mit einem Pinephone kann man das nicht machen, da wird Bluetooth nicht via USB eingebunden, sondern über den DeviceTree im Kernel. Zum Glück gibt es Laptops 😉

 

 

 

 

Pinephone: alle RPMs im PVA Repo

Wer Carola auf seinem Fedora PC installiert hat, hat vielleicht schon davon gehört, daß es ein REPO bei Linux-Am-Dienstag.de gibt: http://repo.linux-am-dienstag.de/pva.repo
modemmanager-agps-1-1.aarch64.rpm
pathdiscover-1-1.aarch64.rpm
phosh-antispam-1-2.aarch64.rpm
Man kann sich da auch die PVA RPMs ziehen, die neueste Version mit dem IMAPSync läuft 1a auf dem Pine, auch wenn x86_64 dran steht 😉

Pinephone: NHEKO angetested

Mir war langweilig, da habe ich Nheko, ein Matrix Client installiert via RPM aus dem Fedora Repo, kurz für Euch angetestet und gleich noch ein paar Tipps parat.

Pinephone: NHEKO angetested

Es war Zeit Nheko mal wieder anzutesten, weil ich einen Matrixclienten brauche, der nicht rückwärts schreibt, keinen immensen Platz verbraucht und die CPU nicht zu 100% auslastet beim Telefonieren(so wie Firefox 🙁 ).

Nheko hat in der Zeit seit meinem letzten Test viel verbessert. Da wäre die Telefonie, die E2EE (Ende-Zu-Ende-Verschlüsselung) und das Handling von Spaces zu nennen. Klappt alles, wenn clevererweise in den EInstellungen als ersten den Touchscreenmode aktiviert.

Allerdings gibt es auch ein „kleines“ Problem 🙂 Das UI Scaling findet leider nicht bzw. falsch statt. Statt den Screen kleiner zurechnen, wenn in der Desktopumgebung ( DE ) Phosh 200% UI-Scaling aktiviert ist, damit man an alles ran kommt, wird das z.Z. noch nicht beachtet. (Hat vermutlich keiner getested 🙂 ).

Damit man sich anmelden kann, muß man erstmal in den Phosh-Einstellungen für den Bildschirm das Scaling auf 150% oder 100% setzen. 150% ist ein guter Kompromiss, weil man so die Hürde Loginscreen überwinden kann, ohne sich eine Lupe holen zu müssen 😉

Danach geht es mit 150% UI-Scaling ganz gut zu bedienen. Es war etwas merkwürdig, daß man swipen muß um einen „Bereich“ wie z.b. einen „Space“ oder „alle Räume“ zu erreichen, statt da einfach auf den Namen zu klicken, aber man kommt drauf… irgendwann 😉

E2EE funktioniert

Als ersten wird man daran erinnert, daß man ja jetzt die neue Client-Session verifizieren muß, war mit Hilfe der Emoticons gut klappt. Allerdings sah es optisch noch nicht ganz rund aus, was aber kein Problem darstellt. Auch wurden noch einige &amp; HTML-Codes im Fenster/Requester Titel nicht umgewandelt, aber auch das ist ein rein optischer Fehler.

Was ich sagen kann ist, die E2EE funktioniert. Die Entwickler weisen daraufhin, daß die Implementierung im Securitycontext ungeprüft ist, also unsicher implementiert sein könnte. Da wirds es wohl Zeit für ein kleines Croudfunding für den Code-Auditor.

Es klingelt \o/

Full-Featured Matrix Clienten können ja auch Audio- und Videoanrufe managen. Das habe ich natürlich sofort ausprobiert und das Ergebnis war im erwarteten Maß funktional. Reine Audioanrufe funktionieren, wobei Ihr wissen solltet, daß der erste Anruf immer etwas länger braucht, als die nachfolgenden. Das scheint nicht am Clienten zu liegen, sondern am Tunnel- oder Synapseserver selbst. Auf Android mit Element oder Schildichat dauert es beim ersten mal auch länger.

Bei Videoanrufen habe ich nicht mit einem Erfolg gerechnet, was auch prompt nicht geklappt hat. Das liegt aber nicht an Nheko, sondern an der Art und Weise wie man auf dem Pinephone auf die Kamera zugreift und das funktioniert nicht. Im Firefox übrigens zur Zeit auch nicht mehr. Ob das am Kernel liegt, oder gstreamer oder sonst eine Systemkomponente kann ich nicht sagen. Müßte man mal debuggen.

Angerufen werden funktioniert auch, dummerweise kann man den Call auf den Lockscreen nicht annehmen, auch wenn man einen Hinweis sieht. Ich empfehle den Post von Guido Günther auf dem Gnome-Blog zu lesen, die bauen da gerade ein Pluginsystem für den Lockscreen, so daß man da alles mögliche tun kann. Wozu man dann noch den Lockscreen braucht, verstehe ich allerdings nicht so ganz 🙂 In letzter Konsequenz wäre der überflüssig, wenn alle Apps da Ihren Kram machen können.

1% CPU Last

Ich habe gerade mal nachgesehen, im Leerlauf kommt Nheko auf einem Core auf 1% Last. Das ist echt klasse!

Ich habe da auch mal alle GPU Tricks aktiviert im nheko.desktopfile:

Exec=env LIBVA_DRIVER_NAME=v4l2_request LIBVA_V4L2_REQUEST_VIDEO_PATH=/dev/video0 LIBVA_V4L2_REQUEST_MEDIA_PATH=/dev/media0 nheko %u

Sofern Nheko Hardware Rendering kann, reduziert das oben den Stromverbrauch noch mehr. Ich habe auch das Gefühl, es startet jetzt schneller.

Fazit: sehr brauchbar, wenn der UI-Scale-Faktor korrekt beachtet würde 🙂