Huuh! Auch bei mir erstmals, auf beiden Geräten, und bei einem sogar mit Lizenzreset. Schönes Wochenende, Uli.
Dafür wurden Dinge für andere Anwendungsfälle abgeführt …
Aber wir sind ja hier im Bereich der Version 6 (oder habe ich mich vertan?).
Andere Audioprogramme auf meinem Rechner wie Wavelab oder Pro Tools haben indes das Windows-Update schadlos überstanden. Warum?
Bei mir war es zum Glück nur der Lizenz-Reset, das Routing hat’s überlebt. Warum auch immer…
Nachtrag: Ich habe Windows 11… Vielleicht gibt es da Unterschiede zu Windows 10…
Die letzte Antwort ist ja nun ne Woche her, aber trotzdem…
Hmm, ich frag mich gerade, nach dem ich mir den Faden hier nochmals durchgelesen habe, ob ich irgendwas falsch gemacht habe.
Bei meinem Senderechner mit mAirList hat nix dazwischen gehauen. Ist bei mir alles an Ort und Stelle. Vielleicht war es auch nur Glück gewesen, das nix passiert ist.
Und warum ein externes Programm dafür nutzen, wenn man es in der Computerverwaltung —>> Dienste und Anwendungen —>> Dienste abstellen kann, das sich der Rechner keine Updates mehr rein leiert?
Weil es nur ein Knopfdruck ist, Updates zuzulassen. Und es gibt wohl auch genug Anwender, die sich mit Windows nicht so gut auskennen.
Das mag durch aus sein, @Stefan_Hillen.
Nach Möglichkeit löse ich sowas für gewöhnlich erst mit den Windows eigenen Bordmitteln und wenn’s dann nicht funktionieren sollte, was durchaus passiert, erst dann greif ich zu externen Programmen.
Inzwischen ist es bei mir so, dass alle Audiogeräte auch dann verschwinden, wenn ich vorher z.B. Wavelab geöffnet hatte.
Antwort erwarte ich keine, da wahrscheinlich Einzelfall, nicht nachstellbar und nicht von allgemeinem Interesse. Ich stelle in diesem Fall einfach die Audigeräte wieder neu ein. Nur mal so als Hinweis.
Irrelevant, da völlig sachfremd.
Damit ich das richtig verstehe: Du öffnest ein Programm (hier: Wavelab) und wenn du danach mAirList öffnest, sind alle Einstellungen der Audiogeräte verstellt?
Lässt sich dieses Verhalten denn auch mit anderen Programmen reproduzieren (Skype, Zoom, StudioLink etc.), die sich evtl. der Soundkarte bemächtigen?
Früher™ war das vereinzelt nicht ausgeschlossen, und zuletzt wurde mir berichtet, dass eine VoIP-Anwendung sich der Mikrofon-Lautstärke in den Windows-Sound-Systemeinstellungen bemächtigt hatte, was auf dem Senderechner natürlich alles andere als lustig war und zu einer abenteuerlichen Fehlersuche führte.
Schuss ins Blaue: Könnte es vielleicht sein, dass du in den Audioenstellungen > WASAPI je Gerät den Modus vielleicht auf “exklusiv” statt auf “gemeinsam benutzt” stehen hast?
Rätselnd: Uli
Steht auf gemeinsam benutzt.
Ansonsten habe ich derzeit keinen Nerv und auch keine Zeit mehr, irgendetwas auszuprobieren. Ich bin zu dem Schluss gekommen, dass ich viel zu viel Zeit vergeudet habe, um hier Verbesserungs-Vorschläge oder auch Bedienungs-Inkonsistenzen zu melden und möglichst exakt zu beschreiben - nur um zu sehen, dass sie auf einer Liste stehen. Auch die Zeit beim Betatest 7 zähle als für mich verschwendet dazu.
Ich habe keine Lust mehr, hier für irgendwas kämpfen zu müssen.
Lieber @calypso60, du müsstest dich bitte entscheiden, ob du dir jetzt helfen lassen möchtest oder nicht.
Dass die Benutzung von Programm A einen Einfluss auf die Konfiguration von Programm B haben soll, klingt in der Tat wenig einleuchtend.
Am ehesten könnte ich es mir noch so erklären, dass Wavelab den ASIO-Modus des RME-Treibers benutzt, und dieser die WASAPI-Geräte irgendwie deaktiviert/löscht und nach Wavelab-Programmende wieder neu anlegt. Das wäre wirklich reichlich haarsträubend, wäre es wahr, und ich hörte zum ersten Mal davon.
Dadurch, dass wir in den Bugreports eine detaillierte Auflistung aller im System erkannten Soundkarten einschließlich ihrer (von Windows vergebenen) IDs, haben, wäre es ein leichtes für uns nachzuvollziehen, welche Änderungen es zwischen zwei Programmstarts gegeben hat. Zumal es ja, so verstehe ich dich, reproduzierbar ist.
Aber wie gesagt, da vermutlich niemand außer dir diese Kombination aus Wavelab und RME und mAirList im Einsatz hat (sonst wäre der Fehler wohl schon berichtet worden), sind wir wohl auf deine Mithilfe angewiesen.
Daher der Hinweis und die Bitte (an alle):
Support ist zeitintensiv, ja, sowohl für uns als auch für den User, dem wir manchmal Schritt für Schritt die benötigten Details aus der Nase ziehen müssen. Das gilt besonders bei Fehlern, die nur in bestimmten Hard-/Softwarekombinationen auftreten, oder wo wir bestimmte Eigenarten von Windows umschiffen müssen.
Deswegen helft uns, indem ihr unsere Rückfragen präzise beantwortet. Und zieht es bitte bis zum Ende durch. Sonst ist es Zeitverschwendung für alle, und ich hätte inzwischen lieber irgendeinen dringend benötigten Feature-Wunsch umsetzen können
Danke, ist angekommen. Tatsächlich werden wir sogar zwei Reports brauchen - einen “vorher” und einen “nachher”. Ich erkläre warum:
Gegen Ende der bugreport.txt
siehst du einen Abschnitt “Playback Devices”. Dieser enthält eine Liste aller von mAirList erkannten Soundkarten - also quasi das, was du auch in der Audiogeräte-Auswahl in der Dropdown-Liste siehst. Bei dir sieht das aktuell so aus:
Playback Devices:
.
NOAUDIO:
BASS:8:0: ADAT (3+4) (RME Fireface UC), SampleRate=44100, BufferSize=500, MixerBufferSize=100, Mode=HardwareMixing, Options=SampleFloat
BASS:10:0: ADAT (5+6) (RME Fireface UC), SampleRate=44100, BufferSize=500, MixerBufferSize=100, Mode=HardwareMixing, Options=SampleFloat
BASS:3:0: ADAT (7+8) (RME Fireface UC), SampleRate=44100, BufferSize=500, MixerBufferSize=100, Mode=HardwareMixing, Options=SampleFloat
BASS:7:0: Analog (3+4) (RME Fireface UC), SampleRate=44100, BufferSize=500, MixerBufferSize=100, Mode=HardwareMixing, Options=SampleFloat
BASS:4:0: Analog (5+6) (RME Fireface UC), SampleRate=44100, BufferSize=500, MixerBufferSize=100, Mode=HardwareMixing, Options=SampleFloat
BASS:1:0: Analog (7+8) (RME Fireface UC), SampleRate=44100, BufferSize=500, MixerBufferSize=100, Mode=HardwareMixing, Options=ForceMultichannel,SampleFloat
BASS:6:0: Digitalaudio (S/PDIF) (High Definition Audio Device), SampleRate=44100, BufferSize=500, MixerBufferSize=100, Mode=HardwareMixing, Options=SampleFloat
BASS:5:0: Lautsprecher (RME Fireface UC), SampleRate=44100, BufferSize=500, MixerBufferSize=100, Mode=HardwareMixing, Options=SampleFloat
BASS:11:0: LG ULTRAWIDE-4 (NVIDIA High Definition Audio), SampleRate=44100, BufferSize=500, MixerBufferSize=100, Mode=HardwareMixing, Options=SampleFloat
BASS:2:0: SPDIF/ADAT (1+2) (RME Fireface UC), SampleRate=44100, BufferSize=500, MixerBufferSize=100, Mode=HardwareMixing, Options=SampleFloat
BASS:9:0: SPDIF coax. (RME Fireface UC), SampleRate=44100, BufferSize=500, MixerBufferSize=100, Mode=HardwareMixing, Options=SampleFloat
WASAPI:{0.0.0.00000000}.{d3a177b5-03d4-43f1-b70e-79365c8c7aa2}: ADAT (3+4) (RME Fireface UC), Mode=Shared, SampleRate=48000, Channels=0, BufferSize=50, Options=-
WASAPI:{0.0.0.00000000}.{dd77333f-19e6-4ad7-9b0c-7d2cd3a74983}: ADAT (5+6) (RME Fireface UC), Mode=Shared, SampleRate=48000, Channels=0, BufferSize=50, Options=-
WASAPI:{0.0.0.00000000}.{4df682b6-b9ff-4b9e-974d-9b74b04eb0e7}: ADAT (7+8) (RME Fireface UC), Mode=Shared, SampleRate=48000, Channels=0, BufferSize=50, Options=-
WASAPI:{0.0.0.00000000}.{afb96bca-cd9b-4046-ada0-0d0b8cd10726}: Analog (3+4) (RME Fireface UC), Mode=Shared, SampleRate=48000, Channels=0, BufferSize=50, Options=-
WASAPI:{0.0.0.00000000}.{5784322d-3595-4c8d-bcd0-f60ad2ad8a1d}: Analog (5+6) (RME Fireface UC), Mode=Shared, SampleRate=48000, Channels=0, BufferSize=50, Options=-
WASAPI:{0.0.0.00000000}.{211f3932-48eb-4ac8-bc48-3ac01b829a30}: Analog (7+8) (RME Fireface UC), Mode=Shared, SampleRate=48000, Channels=0, BufferSize=50, Options=-
WASAPI:{0.0.0.00000000}.{8868f971-d088-4b28-a700-adb8c2b25197}: Digitalaudio (S/PDIF) (High Definition Audio Device), Mode=Shared, SampleRate=48000, Channels=0, BufferSize=50, Options=-
WASAPI:{0.0.0.00000000}.{82e3aaa3-8e9b-40aa-ab2c-f0dc1feba91a}: Lautsprecher (RME Fireface UC), Mode=Shared, SampleRate=48000, Channels=0, BufferSize=50, Options=-
WASAPI:{0.0.0.00000000}.{ffe16f0f-3e2e-468c-86c1-604036f4186f}: LG ULTRAWIDE-4 (NVIDIA High Definition Audio), Mode=Shared, SampleRate=48000, Channels=0, BufferSize=50, Options=-
WASAPI:{0.0.0.00000000}.{4c6615f8-dc7d-4fc4-9f3e-c152c2a3c337}: SPDIF/ADAT (1+2) (RME Fireface UC), Mode=Shared, SampleRate=48000, Channels=0, BufferSize=50, Options=-
WASAPI:{0.0.0.00000000}.{d4eb622f-6973-49e1-8c9e-9f8e2ff8b3fa}: SPDIF coax. (RME Fireface UC), Mode=Shared, SampleRate=48000, Channels=0, BufferSize=50, Options=-
Encoder:
Encoder_Secondary:
Encoder_Player3:
Encoder_Player4:
Encoder_HighPriority:
Nehmen wir uns mal einen Eintrag her, zum Beispiel diesen hier:
WASAPI:{0.0.0.00000000}.{afb96bca-cd9b-4046-ada0-0d0b8cd10726}: Analog (3+4) (RME Fireface UC), Mode=Shared, SampleRate=48000, Channels=0, BufferSize=50, Options=-
Der Teil vor dem letzten Doppelpunkt - WASAPI:{0.0.0.00000000}.{afb96bca-cd9b-4046-ada0-0d0b8cd10726}
- ist die ID, unter der das Gerät in mAirList geführt wird. Wobei für die WASAPI-Geräte die Hex-Zeichen und die GUID in der Mitte die ID sind, die Windows dem Gerät zugewiesen hat: {0.0.0.00000000}.{afb96bca-cd9b-4046-ada0-0d0b8cd10726}
- genau das ist der Wert, der sich ändert, wenn Windows nach eine Update o.ä. die Geräte neu erkennt.
Direkt über den Playback Devices siehst du das “Playback Assignment”. Hier werden jetzt den verschiedenen Programmfunktionen die Geräte zugewiesen - also genau das, was man in den Audiogeräte-Einstellungen festgelegt hat:
Playback Assignment:
.
default=BASS:1:0
Default=NOAUDIO
DefaultPFL=NOAUDIO
Player0_0=WASAPI:{0.0.0.00000000}.{970ed643-7406-4b6b-a6e0-acb206591e9a}
Player0_0_PFL=WASAPI:{0.0.0.00000000}.{970ed643-7406-4b6b-a6e0-acb206591e9a}
Player0_1=WASAPI:{0.0.0.00000000}.{970ed643-7406-4b6b-a6e0-acb206591e9a}
Player0_1_PFL=WASAPI:{0.0.0.00000000}.{970ed643-7406-4b6b-a6e0-acb206591e9a}
Cartwall_OnAir=WASAPI:{0.0.0.00000000}.{970ed643-7406-4b6b-a6e0-acb206591e9a}
Cartwall_PFL=WASAPI:{0.0.0.00000000}.{970ed643-7406-4b6b-a6e0-acb206591e9a}
mAirListDB=WASAPI:{0.0.0.00000000}.{970ed643-7406-4b6b-a6e0-acb206591e9a}
CueEditor=WASAPI:{0.0.0.00000000}.{970ed643-7406-4b6b-a6e0-acb206591e9a}
PFLScreenObject=WASAPI:{0.0.0.00000000}.{970ed643-7406-4b6b-a6e0-acb206591e9a}
MixEditor=WASAPI:{0.0.0.00000000}.{970ed643-7406-4b6b-a6e0-acb206591e9a}
Wie man sieht, tauchen hier diese Geräte-IDs aus der “Playback Devices”-Liste wieder auf. Also idealerweise. Denn wenn Windows die Soundkarten neu erkannt und ihnen neue IDs verpasst hat, dann stimmen die unter “Playback Assignment” genannten IDs natürlich nicht mehr, und du wirst sie unter “Playback Devices” vergeblich suchen. Das scheint hier der Fall zu sein - entweder bin ich gerade blind, oder {0.0.0.00000000}.{970ed643-7406-4b6b-a6e0-acb206591e9a}
fehlt bei den “Playback Devices”.
In einem solchen Fall ist dann die Zuordnung einfach verloren gegegangen. Zumindest bei mAirList 6. Version 7 ist nämlich etwas schlauer und merkt sich zusätzlich zu den IDs auch noch die Namen aller Soundkarten in einer separaten .ini-Datei. Fehlt dann eine ID plötzlich, dann schaut es nach, ob es immerhin ein Gerät mit demselben Namen gibt.
Was jetzt zu tun ist:
-
Einmal alles richtig einstellen.
-
Den Bugreport in diesem Zustand speichern und wegsichern. Achtung: Vor Erzeugen des Bureports mAirList einmal neu starten, denn die Informationen für den Bugreport werden beim Programmstart gecached und ändern sich nicht mehr, wenn man im laufenden Betrieb die Geräte umstellt.
-
Nun das Problem reproduzieren - also ein “Vergessen” der Soundkarten provozieren, meinetwegen durch Starten von Wavelab.
-
Jetzt einen neuen Bugreport speichern - aber ohne vorher die Geräte in mAirList wieder richtig einzustellen.
Am Ende kann man die beiden Reports nebeneinander halten und “Playback Devices” und das “Playback Assignment” vergleichen. Haben sich die IDs der erkannten Geräte geändert? Oder doch das Assignment (aber warum sollte Wavelab in die mAirList-Konfigurationsdateien eingreifen)?
Beides klingt irgendwie unwahrscheinlich; aber die Bugreports werden uns bei der Aufklärung helfen.
Wow.
Beide Bugreports habe ich wie beschrieben erzeugt.
Soweit ich das beurteilen kann, haben sich die IDs der Devices geändert, das Assignment dagegen ist unverändert.
Für mich ist der Fehler nicht “senderelevant”, da er nur auf dem Bürorechner auftritt. Auf dem Senderechner tritt er nicht auf. Dort sind allerdings auch keine anderen Audioprogramme (außer vlc) im Einsatz. Und irgendwann kann ich ja vielleicht auf die v7 umsteigen .
Trotzdem wäre es natürlich interessant, was die Ursache ist.
Ja, sieht ganz danach aus.
Das ist dasselbe “Fehlerbild” wie in den Fällen, wo Windows eine Soundkarte plötzlich neu erkennt. Zum Beispiel nach größeren Updates, oder wenn man eine externe Soundkarte mal an einen anderen USB-Port anschließt als vorher.
Was ist denn zwischen diesen beiden Bugreports genau passiert? Du hast Wavelab gestartet? Mehr nicht?
Ja, mehr ist dazwischen nicht passiert. Da ich weder bei mAirList noch Wavelab ein Update gemacht habe, denke ich, dass die Ursache bei Windows liegt. Darauf deutet auch hin, dass nach einem Windows-Update vorgestern der Fehler nicht mehr reproduzierbar zu sein scheint.
Deshalb schlage ich vor, dass wir das Thema als (vorübergehendes) Windows-Problem verbuchen und an dieser Stelle abhaken. Sollte es nochmals auftreten, melde ich mich.
Letzte Frage dazu: hätte die Version 7, die ich aus bestimmten Gründen noch nicht einsetze, das Problem aus den Bugreports umschiffen können?
Danke und schöne Grüße
Martin
Das ist wirklich ein sehr merkwürdiges Problem, und ehrlich gesagt würde ich der Ursache gerne auf den Grund gehen - einfach um Erfahrung zu sammeln und zukünftig “schonmal davon gehört zu haben”.
Es scheint mir aber recht sicher, dass es nicht an mAirList liegt, sondern eher an Windows oder - noch wahrscheinlicher - am RME-Treiber. Dennoch, ich will wissen, was da vorgeht.
Du startest und beendest also Wavelab, und plötzlich haben die WASAPI-Geräte eine neue ID innerhalb von Windows. Nebenbei: Die IDs kann man auch im Windows-Geräte-Manager ablesen, unter “Details” und dort “Geräteinstanzpfad”:
Auch dort müssten sie sich demzufolge ändern. Wenn du magst, verifiziere das mal.
Auf welche Weise spricht Wavelab denn die RME-Karte an? Über ASIO nehme ich an?
Was passiert mit den WASAPI-Geräten, während Wavelab läuft? Sind die dann überhaupt sichtbar? Siehst du sie in der Windows-Systemsteuerung?
Meine oben schon geäußerte Vermutung ist, dass der RME-Treiber die WASAPI-Geräte komplett “virtuell” trennt, solange er über ASIO angesprochen wird, und sie dann beim “Wiederverbinden” eine neue ID von Windows erhalten.
Wenn das zutrifft, ist das vielleicht ein neuartiges Verhalten des RME-Treibers, das erst mit einem bestimmten Treiberupdate Einzug gehalten hat.
Ja, die Version 7 merkt sich zusätzlich zu den IDs auch noch die Namen der Soundkarten, und wenn die alten IDs verschwinden aber dafür “neue” Soundkarten mit neuen IDs aber denselben Namen auftauchen, dann kann sie es automatisch wieder zuweisen.
Wie schon gesagt, kann ich derzeit, seit dem jüngsten Windows-Update, den Fehler nicht reproduzieren. Deshalb muss ich beobachten, ob er wieder auftritt. Wenn dem so sein sollte, habe ich ja jetzt einige Punkte, auf die ich achten werde.
Deshalb kann ich derzeit auch nicht…
… verifizieren, behalte es aber im Hinterkopf.
Zumindest kann ich folgende Fragen beantworten:
Ja, das ist so.
Zur Zeit habe ich den RME-Treiber 1.1.66.0 v. 16.11.2018, was ja doch etwas alt ist . Aktuell ist lt. RME-Website der Treiber 1.221 vom 17.03.2022. Den sollte ich wohl mal schleunigst installieren…