So in etwa, ja.
Seit v7 gibt es eine Art “Gedächtnis” mit Reparaturfunktion, was in den meisten Fällen auch gut funktioniert. Außerdem kann mAirList auf die Standard-Windows-Audioverbindung zurückgreifen, wenn ein USB-Device die Verbindung verliert und ähnliche Sauereien.
Das ist natürlich nicht immer der Fall, aber es trat wohl besonders häufig bei den Nutzern der beliebten D&R-Hybrid-Pulte auf, also die mit dem integrierten Interface. Da trafen zwei unglückliche Konstellationen aufeinander.
Das ist natürlich nicht exklusiv bei D&R so, sondern überall dort, wo ungebrandete Chips dieser Art zum Einsatz kommen. Wo sich hingegen ein Gerät beim Anschluss namentlich identifiziert (“Branding”), habe ich das noch nicht bemerkt.
So gesehen schließt mAirList damit eine Lücke, die andere zu verantworten haben. Es dient der Anwenderzufriedenheit.
[+] WASAPI: New "Windows Default Device" setting; will automatically follow
when you switch to a different device in Windows sound settings
[+] WASAPI: Automatic recovery when devices are disconnected and reconnected
[+] WASAPI: Newly connected devices can be used without restarting the software
Quelle: https://download.mairlist.com/current/mAirList/v7.4/Changelog.txt
Nebeneffekt: Die Stabilität von mAirList wurde verbessert.
Interessant dabei ist, dass mAirList früher™ über ganze Generationen hinweg ohne diese Probleme funktioniert hat. Es ist also der Preis für den technischen Fortschritt.
Inwiefern solche Erscheinungen auch bei Linux auftreten (um zum Thema zurückzukommen), kann ich nicht beurteilen. Aber wenn man es mit allgemeinen Chips vom Typ “Ich bin ein Audio Codec” zu tun hat, und derer vielleicht sogar gleich mehrere zugleich, gerät vermutlich jedes Betriebssystem ins Stolpern.
Hinzu kommt, dass die Produzenten solcher Devices sicher nicht explizite Treiber bereitstellen.
Das Problem für mAirList ist in dem Fall, für jedes Betriebssystem eine spezifische Lösung zu erfinden und bereitzustellen.