Abgebrochene Audioabnahme: erneutes Session-Mute während Fall 2
Keine vollständige Vierfallabnahme. Der eingefrorene Build Playtest-v29-1-flow-qa mit Quellcommit 82aef7d1a87c1d5d73d54a748ec3f18e3b609ad2 blieb unverändert. Der Wrapper hob mit ausdrücklicher Freigabe ausschließlich die belegte Stummschaltung seiner eigenen Windows-Spielsession vorübergehend auf. Er brach nach zwei Aufnahmen ab, als diese Session erneut stumm war. Finale und Controls wurden nicht gestartet.
Windows-Session und Wiederherstellung
Alle Beobachtungen betreffen den eigenen Player PID 33256, dieselbe EXE und dieselbe Session-Instance …|1%b33256. SessionVolume blieb 1.0. Der Standard-Renderendpoint blieb in den Snapshots aktiv, mit MasterVolume 0.8 und MasterMute false.
| Zeitpunkt UTC, 13.09.2026 | Beobachtung | Beleg |
|---|---|---|
| 02:19:14.080243 | Originalzustand: Mute true, Player lebt | Original |
| 02:19:14.094344 | Eigene Lease setzt ausschließlich Session-Mute false | Temporär |
| 02:19:24.225795 | Nach Befreiungsaufnahme: Mute false | Nach Fall 1 |
| 02:19:25.792671 | Vor Aufnahme 5-3: Mute false | Vor Fall 2 |
| 02:19:35.996105 | Nach Aufnahme 5-3: Mute true | Nach Fall 2 |
| 02:19:36.018772 | finally setzt Original-Mute true und bestätigt true; Player lebt noch |
Restore |
Die Lease führte zwischen ihrem Unmute und dem späteren Restore keinen weiteren Setter aus. Wer oder was die Session in diesem Intervall erneut stummschaltete, ist nicht nachgewiesen. Die Beobachtung allein erlaubt weder die Zuordnung zu einer Nutzeraktion noch zu einem Enginefehler. Der Wrapper überschrieb den unbekannten Zwischenwechsel nicht. Nach dem Restore beendete er nur seinen eigenen Player; der reguläre Restore-vor-finish-Pfad wurde in diesem abgebrochenen Versuch nicht erreicht.
Vorhandene Aufnahmen
Beide WAVs enthalten 9.99 Sekunden, 44.1 kHz Stereo und je 999 QPC-Pakete. Die separate Auswertung der vorhandenen Daten ergab 100 % Szenarioabdeckung, keine Paketfehler und keine Fullscale-/Near-rail-Samples. Dies sind Messbefunde zu diesen Dateien, kein persönliches Hörurteil.
| Fall | PCM-Befund | Aufnahme und SHA-256 |
|---|---|---|
| 2-3 Befreiung, Standardmix | Positives Signal durchgehend; Peak 0.222534, Sieg/Crossfade-RMS 0.056316, ruhiger Nachklang-RMS 0.037150. 39/39 fallbezogene Checks bestanden. | WAV, 6be3e21bec3683524b2325161b3c7666ad981463c125c996abb10f77e2691604 |
| 5-3 Zerstörung, Maximalmix | Positives Signal vor und nach dem Sieg; Peak 0.557434, Sieg/Crossfade-RMS 0.117519. Letztes positives 10-ms-Fenster bei Go +5.435 s, danach Dither. | WAV, 50673866914ee1dc79822f6c2eb9416cdc77dfe6419a950e0684812e687aaa34 |
Der Sieg von 5-3 liegt laut nativem QPC bei Go +1.2622902 s. Der PCM-Abbruch folgt diesmal ungefähr 4.18 Sekunden später. Er fällt somit nicht erneut exakt mit dem Siegcallback zusammen. Im ursprünglichen Vierfallversuch 20260913-035626-e1ae26ee lag der Ausfall ungefähr beim zweiten Sieg; aus dieser früheren zeitlichen Nähe lässt sich keine feste Ursache ableiten.
Die zweite Aufnahme blieb im Originalmanifest wegen des anschließenden Session-Mute-Abbruchs als recording erhalten. Ihre Abschluss-/WAV-/Pakethashes wurden vom Wrapper nicht mehr finalisiert. Die separate Teilanalyse berechnet deren tatsächliche Hashes und behält die vier entsprechenden Manifest-/Abschlussprüfungen als fehlgeschlagen bei; zusätzlich fällt das ausreichend lange positive Nachklangfenster aus. Sie meldet ausdrücklich fourCaseAcceptance: false, passed: false. Keine Quellaufnahme oder ursprüngliche Evidenz wurde nachgebessert.
PCM-Zeitverlauf, Originalmanifest, Playerlog. Der Standardverifier-Bericht weist den unvollständigen Lauf ab und enthält keinen Vierfallpass.
Lesprüfung und verwendeter Toolstand
Die Suche in Assets, Tools und ProjectSettings fand keine weiteren direkten CoreAudio-SetMute-Aufrufe außerhalb der eigenen Lease. Die Setterdeklarationen des lesenden CoreAudio-Helfers werden dort nicht aufgerufen. Keine Aufrufe von AudioSettings.Reset, StopAudioOutput oder StartAudioOutput wurden gefunden. muteOtherAudioSources ist 0. Produktions-Fokus-/Pausehandler greifen nur ohne automatedCheckActive; die Audio-QA aktiviert dieses Flag und runInBackground. Andere stumme QA-Modi sind nicht Teil dieses Playerstarts. Diese Quellprüfung erklärt den unbekannten Windows-Sessionwechsel nicht und ersetzt keine Engineinstrumentierung.
Der native Versuch verwendete OwnedQaAudioSession.cs mit SHA-256 713bed1909328d6c019d1d1b992f7054c3b2713bfdb4c0c9a367b8680bee9ba7. Dieser Stand prüft genau eigenen Process-Handle, PID, Startzeit, EXE, S_OK/exklusive Session und Instance vor dem Unmute sowie vor/nach jeder Aufnahme. Der konkrete Abbruch erfolgte erst nach erfolgreicher Eigentumsprüfung wegen Mute true.
Nach dem Ende des Versuchs wurde um 02:21:57.863231 UTC zusätzlich derselbe S_OK-/PID-/Instance-Guard direkt vor dem Restore-Setter eingefügt. Neuer Toolhash: 2a0f5352f7adc04ac2771571d70c17a58dc4f1d5aa671148228300eb91c7a4f9. Diese spätere enge Toolkorrektur wurde unabhängig gelesen; sie ist kein Bestandteil der bereits gelaufenen Aufnahme und löste keine weitere Serie aus. Spielquellen, Build und Freeze blieben unverändert.
Abschließende reine Werkzeugprüfung: C#-Kompilierung des finalen Helpers und PowerShell-AST-Parse der beiden Wrapper sowie des lesenden Sessionhelfers bestanden. Dabei wurden keine COM-Audiosession, kein Player und keine Aufnahme gestartet.