Usability vs UX
Im allgemeinen Sprachgebrauch, selbst in der Industrie, wird Usability und User-Experience oft vermischt. Da wird dann ein UX-Consultant gesucht, der für die reibungslose Nutzung sorgen soll (dabei ist das viel mehr Usability) oder es wird erwartet, dass der Usability-Experte mit einem neuen Farbschema für die Software ankommt (dabei ist das visuelles Design und mehr ein Teil von UX). Tatsächlich ergänzen sich die beiden Disziplinen, aber sie reden nicht über das gleiche und haben unterschiedliche Methoden.
Definitionen
Usability haben wir hier im Blog gerade erst ausführlich definiert. Zu UX gibt es wieder eine Norm, DIN EN ISO 9241-210. Sie ist demnach abhängig von den Reaktionen des Nutzers, seinen Emotionen, psychologischen und physiologischen Reaktionen. Das kann von allem möglichen abhängen: Ja, auch von der Usability der Software, aber auch vom visuellen Design oder mit ihr verbundenen Statusgefühlen. UX ist demnach viel breiter als Usability.
Gleichzeitig passt sie gut in das kleine Stufenmodell, das bei Usability benutzt wird. Effektivität, Effizienz und Zufriedenstellung, die aufeinander aufbauenden Softwarequalitätsebenen. Zu Zufriedenstellung hat Usability nicht viel zu sagen – zu Effektivität schon mehr, vor allem aber zur Effizienz mittels der Dialogprinzipien. UX lebt aber geradezu auf der Zufriedenstellungsebene. Auch hier muss man sich vorher mit den Grundlagen beschäftigt haben. Aber wie dann tatsächlich die Zufriedenstellung erreicht wird, das wäre in meinen Augen der Fokus von UX.
Abgrenzung
Wobei, kurz eingeschoben, das ist kein Nachteil von Usability. Es kommt mehr aus dem Umstand, dass Usability ein klares Methodenset und ein klares Ziel vor Augen hat, während die Ganzheitlichkeit der UX eben auch Beliebigkeit bedeuten kann. Eine Beliebigkeit, die auch dafür sorgen kann, dass ein vermeintlicher UX-Experte sehr wohl Usability-Arbeit macht, womöglich ohne dass er den Unterschied so wahrnimmt wie ich.
Nehmen wir als Abgrenzungsbeispiel Apple. Apple-Produkte werden oft gepriesen für ihre tolle Benutzbarkeit. Gleichzeitig finden sich unzählige Beispiele, in denen das System nicht besonders aufgabenangemessen, die Selbstbeschreibungsfähigkeit gar nicht da ist und die Erlernbarkeit auch fehlt. Natürlich gibt es schlimmere Systeme, aber Apple-Software ist doch voller Usability-Probleme. Trotzdem gibt es eine riesige Gruppe, die Apple-Produkte quasi-religiös verehrt und sie ganz toll findet. Eine Diskrepanz für Usability, da hier Zufriedenstellung von Effektivität und Effizienz abhängt und wir generell fokussiert von einer konkreten Aufgabenerledigung reden. Erklärbar mit UX, wenn dort das visuelle Design, Marketing und Statusdenken mitbeachtet wird.
Doch es geht zusammen
Usability und UX schließen sich nicht aus. In der Praxis werden die Definitionen vermischt, meine trennende Perspektive hier könnte im Laufe der Zeit von immer weniger Menschen geteilt werden. Aber aus Sicht eines Usability-Experten sind die beiden Disziplinen nicht auf der gleichen Ebene. Usability würde mit Nutzertests die effiziente Aufgabenerledigung testen wollen, die weitere Wirkung des Produkts wäre ein per Umfrage abgedeckter Nachgedanke (aber zur Methodensammlung kommen wir noch). UX dagegen würde diese Umfrage zur emotionalen Wirkung ins Zentrum stellen und dann im Zweifel darauf hinwirken, dass das visuelle Design angepasst wird.
Wie XCOM 2 die Schraube anzieht
Wer als Veteran des Vorgängers Enemy Unknown das neuere XCOM 2 spielt könnte sich wundern, wieviel die Entwickler am Spieldesign geändert haben. Eine Änderung insbesondere ist kritisch: Viele Missionen haben eine Rundenzeitbegrenzung. Als ich damals darüber las ging ich sogar davon aus, dass dieser neue Ansatz überhaupt nicht zu meiner Spielweise passen würde. Was stimmt – aber das ist überraschenderweise kein Problem. Stattdessen ist das Rundenlimit eine der Änderungen, die das Spiel noch besser als den ersten Teil machen.
Die Wurzeln: Rundenkämpfe, RPG-Elemente und Basisbau
Es täuscht, aber: Auf den ersten Blick ändert sich nicht viel. Noch immer gilt es die Erde gegen eine Alieninvasion zu verteidigen, nur sind sie diesmal schon angekommen und etabliert. Ihr führt den Widerstand, der den Kampf gegen die Alienherrscher gewinnen und ihre finsteren Pläne vereiteln will.
In erster Linie passiert das in den bekannten Rundenkämpfen. Immer ein kleines Team aus XCOM-Soldaten muss die Siegbedingungen auf den nicht zu großen Karten erreichen. Und das möglichst, ohne dass einer der vier (später auch mehr) geführten Recken stirbt. Das bedeutet: Deckung nutzen, Gegner flanken, geschickt die Sonderfähigkeiten der Soldatenklassen einsetzen, ein bisschen Glück haben und im Zweifel neu laden. Von den Spezialaktionen gibt es bald mehr, erledigte Gegner bringen Erfahrung, bei Levelaufstiegen darf eine von immer zwei möglichen Fähigkeiten erlernt werden. Aber immer erst nach der Mission, nur in der Heimatbasis kann die Beförderung verliehen werden.
Die Basis ist auch sonst ein wichtiges Spielelement. Sind ein paar Räume wie das Forschungslabor schon vorhanden, ist da noch weiterer Platz für Einrichtungen. Beispielsweise für das Psi-Labor, mit dem neue Rekruten mit den übernatürlichen Fähigkeiten ausgestattet werden können, die auch die Aliens immer wieder gegen die Spielertruppe einsetzen. Doch für die Räume braucht es Ressourcen wie auch genug Energieproduktion, zudem müssen fast alle Einrichtungen sowie Ausrüstungsgegenstände erstmal erforscht werden.
Diese Ressourcen gewinnt man durch erfüllte Missionen, aber auch durchs Kontrollieren der Weltkarte. Die Sektoren müssen kontaktiert werden, was Zeit kosten, dann gibt es monatlich Unterstützung. Und auch gibt es immer wieder Ressourcenquellen auf der Karte, bei denen gegen Zeiteinsatz z.B. neue Rekruten oder Intel gewonnen werden können. Meist aber ruft sowieso eine der Missionen.
Die Hauptressource: Zeit
Es gibt also überall etwas zu tun und man hat gerade am Anfang unzählige Optionen. Doch XCOM 2 lässt eben nicht frei die Möglichkeiten auszuprobieren. Stattdessen gibt es immer wieder zeitkritische wichtige Missionen. Das Spiel poppt deren Beschreibungen auf und sagt ganz klar: Du hast im Grunde keine Wahl, du musst jetzt eine dieser drei wählen um eine Aktion der Aliens zu vereiteln oder eine einzelne erfüllen, um Ressourcen zu erhalten.
Vor allem das Avatarprojekt droht da als klar sichtbares Zeitlimit, das sabotiert werden muss. Dafür können Alienforschungseinrichtungen hochgejagt werden. Ironischerweise ist das eine der wenigen Missionstypen, bei denen der Spieler einmal kein Zeitlimit hat. Dafür praktisch in allen anderen: Dann ist z.B. in dem zu kapernden abgestürzten UFO ein Peilsender, der in 5 Runden Verstärkungen anfordern und damit zum Rückzug zwingen wird, sollte er nicht rechtzeitig abgeschaltet werden.
Doch ist dieses Zeitlimit in den Missionen nicht so stressig wie es klingt. Es zwingt zum aggressiveren Vorgehen, klar. Aber zum einen tut das XCOM gut, denn es verhindert das übervorsichtige Vortasten bei dem dann meist minutenlang nichts passierte. Vor allem aber ist das Spiel für diese schnellere Spielweise ausgelegt. Es gibt nicht die große übermächtige Gegnermassen, sondern es sind relativ wenige Aliens auf den Karten unterwegs, die sich zudem in kleine Gruppen von immer etwa drei Gegner aufteilen. Manchmal trifft man mehrere dieser Gruppen in einem Zug, aber meistens können sie nach und nach abgearbeitet werden. Vor allem wenn man nach einer Weile 5 oder 6 eigene Figuren mit guter Ausrüstung und Sonderfähigkeiten führt werden die Missionen beherrschbar.
Die vielen Verbesserungen
So können die vielen Verbesserungen scheinen. Wie klar wurde, dazu zähle ich das Missionsdesign mit seinem Zeitlimit, aber das ist beileibe nicht alles.
Durch die vielen automatisch auftauchenden Missionen gerade am Anfang des Spiels ist der Spieler zwar zuerst sehr unfrei, aber auch geführt. Die Missionen fordern und gleichzeitig sollen ja doch auf der Weltkarte und beim Basisbau längerfristige Entscheidungen getroffen werden. Aber doch wird man nicht überfordert, weil mit den Missionen immer Fortschritt erreicht wird. So verhindert XCOM 2 effektiv, dass die schiere Komplexität zum blockierenden Problem wird. Und der Schwierigkeitsgrad wird gemächlich erhöht, zumindest langsamer als es mir beim Vorgänger vorkam.
Diesem besseren Spielgefühl dienen auch die stärkeren Klassen. Sie alle haben ein klareres Profil mit besseren Spezialfähigkeiten bekommen. Wer dann noch halbwegs fleißig Ressourcen in Soldatenupgrades investiert kämpft nicht mehr als absoluter Underdog gegen die Feinde, anders als im ersten Teil.
Es gibt immer noch einen Heavy und einen Scharfschützen, die immer noch mit schwerem Geschütz bzw. Gewehr die Gegner aufräumen. Dazu kommt diesmal der Ranger mit Schrotflinte und Nahkampfangriff, der sich entweder auf diesen spezialisiert oder auf die Tarnung. Und dann komplettiert auch schon der Spezialist die regulären Klassen, der als Heiler oder als Hacker sehr wichtig geworden ist. Vor allem, dass er als Hacker Roboter besonders effektiv ausschalten oder sogar zeitweise übernehmen kann macht ihn sehr effektiv. Dazu kommt dann noch der Psi-Soldat, der schnell sehr viele sehr starke Fähigkeiten bekommt, dann humanoide Gegner sogar dauerhaft übernehmen kann, garantiert trifft oder Flächenschaden verursacht.
Dazu setzt XCOM 2 den Fokus auf die Inszenierung fort. Die Missionen sind weit davon entfernt wie das Herumziehen kleiner Pixelfiguren zu wirken. Dafür sorgen die vielen Momente, in denen die Kamera in die Nahansicht geht um Aktionen und ihre Ergebnisse zu zeigen. Auch außerhalb der Missionen gibt es viele Zwischensequenzen, besonders wenn eines der Hauptziele erfüllt wurde, in denen auch die Mitstreiter des Widerstands auftreten.
Ein gelungener schmaler Grat
Die geringe dem Spieler mögliche Initiative am Anfang hätte nerven können, das Zeitlimit in den Missionen stressen, die Weltkarte langweilen. Stattdessen fügt sich XCOM 2 zu einer tollen Mischung zusammen, die schlicht nochmal besser funktioniert als der auch schon sehr gute Vorgänger.
Wie knapp das war zeigen die sich wiederholenden Missionen, in denen ein Sender vor den Aliens verteidigt werden soll. Der ist immer auf der anderen Seite der Karte. Ein festes Zeitlimit gibt es nicht, aber manchmal wird er von der ersten Runde an angegriffen. Dann reicht die Zeit höchstens gerade so, rechtzeitig den Sender zu erreichen und die Gegner zu besiegen. Ich schaffte es immer, aber gerade am Ende des Spiels (wenn die Gegner stärker sind) nur durch exzessives Ausnutzen der Quickload-Funktion, um immer optimale Spielzüge zu machen. Selbst dann war es ein paarmal unwahrscheinlich knapp. Und das ist dann nicht mehr herausfordernd spaßig, sondern frustrierend unfair.
Ich kann mir daher sehr gut vorstellen, dass die oft zu lesende Kritik an den DLCs berechtigt ist, dass sie entweder mit weiteren starken Feinden oder mit zu vielen weiteren – und dann durch die unweigerlich ausfallenden verletzten Soldaten nicht mehr gewinnbaren – Pflichtmissionen am Anfang die Balance kippen.
Aber so wie das Grundspiel ist funktioniert die Mischung hervorragend. Und die Linuxversion funktioniert mit sehr wenigen kleinen Macken (wie manchmal etwas etwas spät nachladenden Texturen) ebenfalls sehr gut. XCOM 2 wird mittlerweile im Sale für 4€ auf Steam verscherbelt, das Geld ist es auf jeden Fall wert.
Was ist Usability?
Normalerweise versteht man unter Usability die einfache Benutzbarkeit von Software. Tatsächlich aber hat Usability eine genormte Definition nach DIN EN ISO 9241-11 und ist nach meinem Stand der Grad, zu dem ein Werkzeug in einem bestimmten Kontext bei bestimmten Nutzern eine bestimmte Aufgabe effektiv, effizient und zufriedenstellend erledigt. Da steckt ein bisschen mehr drin als bei der ersten Definition, die die meisten von uns im Kopf haben dürften.
Usability nach Norm
Erstens geht es dann nicht mehr nur um Software, sondern um jedes Werkzeug oder Produkt. Zweitens geht es nicht mehr um generelle Einfachheit, sondern um die Eignung in definierten Anwendungsfällen. Und drittens gibt es nach dieser Definition mit effektiv, effizient und zufriedenstellend Gradmesser der Usability, wobei damit konkret gemeint ist:
- Effektiv kann das Werkzeug die Aufgabe überhaupt erledigen (viele Dinge hämmern)
- Dabei ist es mehr oder weniger effizient (der Hammer hämmert besser als das Telefon)
- Nach dem ganzen ist der Nutzer mehr oder weniger zufrieden, vielleicht sogar sehr, wenn der Hammer super effektiv und effizient war, minimalen Kraftaufwand braucht und gleichzeitig dem Handwerker Komplimente macht.
Bewaffnet mit dieser Definition gibt es gerade in Deutschland eine (kleine?) Industrie, die Fortbildungen anbietet und (normalerweise) Software auf diese Kriterien abklopft. Mein vorheriger Job war genau in dem Bereich – führte mich also vom breiteren Studium der Mensch-Computer-Interaktion (HCI) zurück zu sehr viel konkreterer angewandter Usability, genau was mich an HCI genug fasziniert hatte um es als Master zu wählen.
Hilfreicher: Grundlagen der Dialoggestaltung
Aber von wegen angewandt: Natürlich ist die Definition trotz allem reindefinierten viel zu abstrakt, um damit viel konkretes anzufangen. Um Software zu bewerten geht man daher einen Schritt weiter und schaut sich die Grundlagen der Dialoggestaltung (ISO 9241-110) an:
Aufgabenangemessenheit
Kann die Aufgabe angemessen erledigt werden? Ja, man kann mit Paint eine Doktorarbeit schreiben, aber der Aufwand ist unnötig hoch.
Selbstbeschreibungsfähigkeit
Ist der Zweck jedes Interfaceelements direkt ersichtlich? Typisches Problem hier sind Icons, deren Bedeutung unklar bleibt oder Buttons, die nicht wie Buttons aussehen (Flat-Design!).
Steuerbarkeit
Kann man (z.B. in einem Wizard) wieder zurückgehen?
Erwartungskonformität
Ist alles konsistent mit der Nutzungserwartung? Darüber schrieb ich hier im Blog schonmal bezüglich des prägenden Einflusses des ersten Kontakts mit einem Systems.
Fehlertoleranz
Verzeiht das System Falscheingaben des Nutzers und bewahrt ihn vor solchen?
Individualisierbarkeit
Beispiel Schriftgröße – kann das System an die Bedürfnisse des Nutzers angepasst werden? Hier geht es dann ganz schnell auch um Accessibility
Lernförderlichkeit
Kann der Nutzer die Software erlernen und hilft sie dabei? Markierungen für Tastenkürzel in Menüs gehen z.B. in die Richtung.
Das sind schon besser greifbare Kriterien, mit denen man Software auf der Effizienzebene bewerten kann und dann rausbekommt, welche Probleme sie hat.
Diese Grundlagen wurden übrigens vor kurzem überarbeitet. Unter anderem wurde laut Wiki Benutzerbindung – System ist einladend und motivierend hinzugefügt. Das ist Unsinn, weil es dem Prinzip hinter ihnen zuwider läuft, klar definierbare Eigenschaften von Dialogen auf der Effizienzebene abzudecken und stattdessen der schwer greifbaren Zufriedenstellung oder User-Experience entspricht (zur Abgrenzung von UX und Usability will ich später noch etwas schreiben). Du könntest also an anderen Stellen eine andere Definition finden, solltest die aber ignorieren. Die oben gezeigte ist die richtige.
Testbarkeit, Einstellungssache und Anwendbarkeitsprobleme
Mir ist wichtig etwas zu betonen, was bei den ganzen Definitionen vielleicht nicht direkt klar wird: Usability ist die Antithese zu RTFM. Dieses elitäre Gehabe, das zumindest vor Ubuntu im Linuxumfeld zu finden war und immer noch in einigen Bereichen zu finden sein wird, hat als Kern den Anspruch, dass bei Problemen der Nutzer schuld ist und er sich anpassen muss. Usability gibt dagegen ein Werkzeugset, mit dem man schauen kann wie Software so gebaut wird, dass zumindest die Zielnutzergruppe ihre Aufgabe gut erledigen kann. Was Anleitunglesen nur dann einschließt, wenn es die übliche Praxis der Zielgruppe ist.
Üblicherweise macht man diese Prüfung mit Nutzungstests. Da spielt das ganze "definierter Nutzer, Kontext und Aufgabe" der Usabilitydefinition mit rein. Natürlich kann auch ich mich vor eine Software setzen und gucken, welche Probleme mir auffallen – das ist sogar ein valides erstes Testmittel, mit einer Expertenevaluation finden sich viele typische Probleme. Aber dem Atomkraftwerksingenieur, der normalerweise vor der Software sitzt, dem werden noch ganz andere Dinge auffallen und wichtig sein. Wenn ich also ihn bei seiner Aufgabenerledigung beobachten kann wird viel wahrscheinlicher, dass die wichtigen Probleme auftreten und analysiert werden können.
Hier im Blog hatten wir das auch schonmal in einem schönen Beispiel bei der kleinen Kontroverse um Gimps Umbau des Speicherdialogs, denn dort war der springende Punkt, dass es eben darauf ankommt was die eigentlichen Nutzer während der echten Arbeit davon halten – wobei bei Gimp das eben sehr viele Nutzer mit unterschiedlichen Anforderungen sein können.
Man sieht da ein Problem: Usability nach Normdefinition eignet sich besser für kleinere Nutzergruppen, vor allem für Angestellte in Unternehmen. Wenn ich weiß, dass alle meine Techniker eine bestimmte alte Software beherrschten und grundsätzlich diese X Dinge über das verkaufte Produkt wissen, dann kann ich die Nachfolgesoftware gut mit denen testen. Wenn ich alle Menschen auf der Erde ansprechen will, geht all der definierte Kontext aus der Definition den Bach runter. Als Usability-Experte kann ich dann immer noch mit Tests arbeiten, Konsistenz herstellen und mir Zielnutzergruppen raussuchen, für die meine Software besonders gut funktionieren wird – aber da kommt man immer an die Grenze des machbaren, an der dann schon der kulturelle Unterschied zu groß ist um ihnen allen eine gute Usability zu bieten.
An ähnliche Probleme kommt man, wenn die Software eine schwierig zu definierende Aufgabe hat. Versuch mal, Facebook auf eine einzelne Aufgabenerledigung runterzubrechen.
Manchmal geht das dann schief und Software wird im Auftrag der Designer kaputtsimplifiziert. Etwas einfach zu halten kann helfen möglichst viele mögliche Nutzer nicht vor Probleme zu stellen, kann aber eben auch die Aufgabenerledigung für die anderen (im Zweifel: Die echten und bestehenden Nutzer) behindern. Windows 8 kann man so einordnen. Generell im Zweifel alles, wo Oberflächen für beschränkte Medienkonsumierungsgeräte wie Smartphones und Tablets auf PCs übertragen werden. Aber auch die misslungene Umstellung des Fedora-Installers von einem simplen linearen Wizard auf eine komplizierte Menüstruktur im Namen der vermeintlich zugänglichen modernen GUI schlägt in diese Kerbe
Mehr als eine Norm: Usability für alles
Gut, dass es wirklich nicht nur um Software geht und Usability mehr ist als nur unsympathisch hinter Zahlschranken versteckte DIN-Normen. Das Buch The Design of Everyday Things von Don Norman zeigt das besonders stark. Norman sammelt darin sehr viele Beispiele von Alltagsgegenständen, deren Usability schlecht ist. Tolles Beispiel sind Türen: Schonmal vor einer gestanden und nicht gewusst, ob man ziehen oder drücken muss? Auch das wird zu einer grundsätzlichen Einstellungsfrage: Die meisten Menschen fühlen sich blöd, wenn sie falsch lagen. Dabei ist es doch nicht ihr Fehler, wenn die Tür so gestaltet ist, dass ihre Bedienung unklar ist! Mit den Dialogprinzipien von oben würde man sagen: Die Selbstbeschreibungsfähigkeit war ungenügend.
Ich habe das Buch vor kurzem verliehen und als Fazit zurückbekommen, dass es anfangs sehr gut und überzeugend ist, aber nach eine Weile sich zu wiederholt. Das stimmt wohl, aber es hat auch viele gute Beispiele und bringt bis dahin Usability als Denkansatz gut rüber. Es geht über die Normen hinaus und gibt weitere Erklärungen, was gute Usability ausmacht und Beobachtungen, wie Nutzer Probleme angehen: Hilfreiche Dinge wie mentale Modelle und Seven stages of action.
Usability ist ein relativ weites Feld und HCI ist noch viel weiter. Aber gerade Usability ist faszinierend, weil es so wunderbar anwendbar und hilfreich ist. Und ich empfand immer eine große Anziehungskraft des Begriffs: Als jemand, der damals Software zu schreiben lernte wollte ich doch natürlich auch wissen, wie diese Software für gute Benutzbarkeit gestaltet zu sein hat. Auch heute ist das mein Anspruch.
Doch hier im Blog habe ich nur selten darüber geschrieben, selbst die fast allumfassende HCI-Kategorie ist relativ ungefüllt. Ich habe mir daher vorgenommen, noch etwas mehr über Usability zu schreiben. Vor allem, wie man dieses Konstrukt konkret nutzen kann um benutzbare Software zu gestalten.
Serendipitys Social-Buttons mit Zähler aktualisiert
Hier im Blog läuft das Plugin serendipity_event_social/Share Buttons, das unter den Einträgen per shariff umgesetzte datenschutzfreundliche 2-Klick-Buttons anzeigt. Mit denen kann man den Blogartikel in sozialen Netzwerken wie Twitter und Facebook teilen, aber ohne dass allein durch das Laden dieser Seite deren Code geladen wird. Das verhindert Überwachung.
Die Buttons funktionierten weiterhin, aber der Zähler war hier im Blog kaputt. Shariff hat auch ein Backend, das ich für alle Pluginnutzer auf meinem uberspace laufen lasse. Das Backend holt die Zahlen. Aber hier im Blog hatte ich es auf die falsche URL gestellt, das / am Ende fehlte. Das ist nun korrigiert.
Die Gelegenheit habe ich genutzt, um auch das Backend zu aktualisieren - es lief noch eine ältere Version. Wohl dadurch war die Facebook-API deaktiviert worden, sie ist jetzt wieder an. Das Backend-Update war wohl generell notwendig. Wenn also auch bei euch im Blog der Zähler nicht funktionierte wäre nun ein neuer Test eine gute Idee.
Beim Serendipity-Plugin musste nichts geändert werden, nur die richtige URL habe ich jetzt dokumentiert.
Ich war mir sicher, über das Plugin hier im Blog bereits geschrieben zu haben. Aber ich finde keinen Artikel dazu, nur dass ich vor 9 Jahren schonmal mit shariff experimentiert hatte. Deshalb sei hier noch erwähnt, dass das Plugin mehr macht als nur die Buttons anzuzeigen: Es baut auch das HTML, um das erste genutzte Bild oder eine gesetzte Alternative bei diesen Kästen einzusetzen, die Seiten wie Twitter bauen wenn bei ihnen ein Artikel verlinkt wird. Was ich für ein nettes Feature halte.
Und damit wäre die Vorstellung nachgeholt.
Lärmfilter fürs Mikrofon unter Alsa
Ich möchte hier alsa_rnnoise vorstellen. Aber dafür muss ich erstmal das tolle NoiseTorch erwähnen. Es ist ein Programm, das den Umgebungslärm reduziert der vom Mikrofon aufgenommen wird. Wenn man via dem PC mit anderen Leuten spricht und sie nicht mit beispielsweise dem Tastaturlärm oder anderen Lärmquellen belästigen will ist das praktisch. Und auch wenn man Aufnahmen außerhalb eines isolierten Raums macht könnte es nützlich sein. Ich nutze NoiseTorch während der Arbeit am Laptop für unsere Telefonkonferenzen.
Aber weil es im Kern ein Pulsaudio-Plugin ist funktioniert es für mich nicht am heimischen, mit ALSA eingerichteten PC. NoiseTorch hat auch ein paar Macken, wie die hohe Prozessorlast selbst ohne Sound-Input, die aber an Pulseaudio hängt – was mich darin bestärkt weiterhin kein Pulseaudio zu installieren. Deswegen ist es für mich besonders toll, dass der Entwickler arsen sich die Mühe gemacht hat ein ALSA-Plugin mit der gleichen Kernfunktionalität zu bauen. Eben alsa_rnnoise. Das namensgebende RNNoise ist das neuronale Netzwerk, das auch NoiseTorch benutzt um Lärm wegzufiltern.
Installation
Weder RNNoise noch alsa_rnnoise waren für void gepackt, daher musste ich beides manuell installieren. Was sich zusammen mit der folgenden ALSA-Konfiguration ein bisschen anfühlte wie Linux vor einer Dekade. Aber wer modernen Komfort will könnte sich ja an NoiseTorch mit Pulseaudio halten. Zum Glück beschreibt die jeweilige Readme fast vollständig was zu tun ist.
Stell erstmal sicher, dass alsa-dev installiert ist:
sudo xbps-install alsa-lib-devel
Dann installiere RNNoise:
git clone https://gitlab.xiph.org/xiph/rnnoise.git cd rnnoise ./autogen.sh ./configure make sudo make install
Die Libraries von RNNoise werden so nach /usr/local/lib/ gepackt.
Den Ordner von RNNoise müssen wir bei der Installation von alsa_rnnoise dem Buildsystem mitteilen, ebenso wie den richtigen Ordner für ALSA-Plugins:
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/:/usr/lib/pkgconfig/:/usr/lib64/pkgconfig/ meson build -Dplugin_dir=/usr/lib/alsa-lib/ ninja -C build sudo ninja -C build install
Damit ist das System bereit um ALSA zu konfigurieren. Die Readme schlägt diese Konfiguration vor, die in der $HOME/.asoundrc zu platzieren wäre:
pcm.urnnoise {
type rnnoise
slave.pcm "sysdefault"
}
pcm.rnnoise {
type plug
slave {
rate 48000
pcm "urnnoise"
}
}
pcm.!default {
type asym
playback.pcm "cards.pcm.default"
capture.pcm "rnnoise"
}
Bei mir muss da aber noch das softvol-Plugin dazwischen, da mein t.bone MB 88U sonst zu leise ist, plus eine manuelle dmix-Konfiguration. Daher sieht die .asoundrc bei mir etwas anders aus:
pcm.!default {
type asym
playback.pcm {
type plug
slave.pcm "dmixer"
}
capture.pcm rnnoise
}
ctl.!default {
type hw
card "PCH"
}
pcm.softvol {
type softvol
slave.pcm "hw:Device"
control { name "Softmaster"; card "Device"; }
max_dB 20.0
min_dB -5.0
}
pcm.urnnoise {
type rnnoise
slave.pcm "softvol"
}
pcm.rnnoise {
type plug
slave {
rate 48000
pcm "urnnoise"
}
}
pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm "hw:PCH"
buffer_size 16384
period_time 0
period_size 1024
}
}
Der Filter funktionierte so direkt.
Soundtest
Aber funktioniert er auch gut, lohnt sich der Aufwand? Ich habe ein paar Testaufnahmen gemacht um das einzuordnen. Eingebunden sind unkomprimierte .wav-Dateien, die auf .ogg zurückfallen falls der Browser mit ersteren nicht umgehen kann (mit ffmpeg umgewandelt, maximale Qualität).
Ohne Lärm
Im ersten Test habe ich in einem ruhigen Raum ohne besondere Lärmquelle kurz in das Mikrofon gesprochen. Hier sollte der Filter im Idealfall kaum wahrnehmbar sein, auf jeden Fall sollte er die Stimme nicht abschneiden. Doch hört selbst wie es lief.
Ich fand das Ergebnis gut. Der Raum klingt ein bisschen anders, oder? Aber ich habe nicht den Eindruck, dass es schlechter klingt oder meine Sprache abgehackt wird. Da auch die Prozessorlast nicht hoch war ein erster Hinweis, dass alsa_rnnoise immer anbleiben könnte.
Mit Tastaturlärm
Regulären Lärm wie das Klappern der Tastatur rauszufiltern oder zu reduzieren wäre mir am wichtigsten. So könnte ich guten Gewissens in Gesprächen das jeweilige Programm nicht auf Push-To-Talk stellen. Und wenn sowas funktioniert, dann wird wahrscheinlich auch ein in der Ferne vorbeifahrendes Auto weggefiltert.
Ein gutes Ergebnis! Wenn ich nicht spreche ist die Tastatur weg, wenn ich spreche ist sie leiser. Und sie ist vorher ja sehr laut, gar nicht mal nur das Klicken der Tasten, sondern da wurden auch die Schwingungen des Tisches übertragen. Als ob ich auf die Tastatur hämmern würde, dabei tat ich das gar nicht.
Wenn ich während eines Gespräches mal tippen müsste wäre der Lärmfilter sehr hilfreich.
Mit einem Staubsauger an der Seite
Ich dachte, wenn ich einen Handstaubsauger anmache wäre ich ohne Filter nicht zu hören und mit Filter vielleicht etwas, wobei ich andererseits fürchtete, dass das zuviel erhofft ist. Tatsächlich funktionierte es nicht, aber anders als erwartet.
Die Aufnahme ohne Filter war besser als erwartet, weil trotz des Lärms meine Stimme aufgenommen wurde und sogar verständlich blieb. Mit dem Filter dagegen war zwar der Staubsaugerlärm reduziert, aber war leider auch meine Stimme immer wieder verzerrt. Als ob die Aufnahme übersteuern würde, wobei ich mir ziemlich sicher bin nicht wesentlich lauter geredet zu haben als bei der ersten Aufnahme. Bei solchem extremen Lärm liegt bei alsa_rnnoise wohl eine Grenze, ob es jetzt am Alsaplugin oder am RNNoise-Kern selbst liegt kann ich nicht sagen.
Fazit
NoiseTorch ist derzeit natürlich schon einfacher zu installieren und zu konfigurieren, aber ich sehe großes Potential in der ALSA-Lösung. Sie könnte einfach von Distributionen ausgeliefert werden und wir dann eine Konfigurationsoption davon entfernt sein, automatisch die Sprachaufnahmen aller Linuxnutzer verbessern zu können. Egal ob das Aufnahmen für Podcasts oder VoIP-Gespräche sind. Damit das machbar wird sollte mit Aufnahmen während extremen Umgebungslärms etwas besser umgegangen werden. Andererseits dürfte niemand erwarten bei solchem Lärm gut verstanden zu werden, daher ist das in der Praxis vielleicht ein relativ kleines Problem.
Ich bin gespannt was draus wird. Bei meinem System lasse ich das jetzt einfach erstmal an und schaue, ob es sich bewährt.
