fix(wgc): give the audio write its own breadcrumb instead of the video's

An adversarial review of 4d1a0cc caught this, and three independent passes
landed on it separately: naming the audio write was right, putting it in
encodeStage_ was not.

encodeStage_ is a single slot. Almost all of the video thread's stages -- the
whole DXGI bridge sequence in convertBgraTextureToNv12 and captureDxgiSample --
are set with no MFEncoder lock held; only submitVideoSample's stamp sits under
writerMutex_. So the previous commit's claim that "both stamps are serialized
by the mutex they sit under" was true of the two WriteSample stamps and of
nothing else.

The consequence ran backwards from the intent. writeAudio runs on the
audio-mixer thread, which emits roughly every 10 ms and ends each call by
storing "idle". A video thread wedged in bridge-copy therefore had its
breadcrumb erased within milliseconds, and the watchdog line -- the single
piece of evidence this instrumentation exists to produce -- would have printed
encode_stage=idle for precisely the hang it was added to identify. Worse on
the system-audio configuration than anywhere else, which is the configuration
reproducing #252 most consistently.

One slot per writing thread. encodeStage_ is single-writer again (the video
thread), audioStage_ belongs to the mixer, and the abandoned-step line prints
both. A report showing audio_stage=write-audio next to a video stage stuck on
a bridge call now says the two are contending for writerMutex_, which is a
thing no shared slot could have expressed.

Verified at runtime on the previous commit: a 10-minute DXGI recording
(16,177 frames, gpu_bridge_contended=0) and a 15-second one both stopped
cleanly, so the surrounding path this touches is exercised, not just compiled.

Author: EtienneLescot

electron/native/wgc-capture/src/main.cpp

@@ -1130,8 +1130,15 @@ int main(int argc, char* argv[]) {
                 // abandoned" into something actionable: it names the call the
                 // writer thread is sitting in, instead of leaving the next
                 // report to guess the way issue #252 had to.
+                // Both threads are named, because either can be the one that is
+                // stuck and each has its own slot: encode_stage is the video
+                // writer, audio_stage the mixer. A report showing audio_stage
+                // parked on write-audio while encode_stage sits at a bridge
+                // call says the two are fighting over writerMutex_, which no
+                // single-slot breadcrumb could ever have shown.
                 std::cerr << "[stop-timing] step=" << step << " elapsed_ms=" << stopElapsedMs()
-                          << " phase=abandoned encode_stage=" << encoder.encodeStage() << std::endl;
+                          << " phase=abandoned encode_stage=" << encoder.encodeStage()
+                          << " audio_stage=" << encoder.audioStage() << std::endl;
                 std::cout << "{\"event\":\"stop-timeout\",\"schemaVersion\":2,\"step\":\"" << step
                           << "\"}" << std::endl;
                 std::cout.flush();

electron/native/wgc-capture/src/mf_encoder.cpp

@@ -366,6 +366,10 @@ const char* MFEncoder::encodeStage() const {
     return encodeStage_.load();
 }
 
+const char* MFEncoder::audioStage() const {
+    return audioStage_.load();
+}
+
 int64_t MFEncoder::nextSampleTime(int64_t timestampHns, int64_t sampleDuration) {
     // On `timestampMutex_` and not `writerMutex_`, deliberately. Every caller
     // of this runs under main.cpp's frame lock, and `writerMutex_` is held
@@ -1365,10 +1369,19 @@ bool MFEncoder::writeAudio(const BYTE* data, DWORD byteCount, int64_t timestampH
     // Named too, for the same reason the video write is: this is a synchronous
     // encode holding writerMutex_, so it is a place the process can be stuck,
     // and a watchdog report that only ever names video writes cannot say so.
-    encodeStage_ = "write-audio";
+    //
+    // Its own slot, not encodeStage_. This runs on the audio-mixer thread,
+    // which emits roughly every 10 ms, while most of the video thread's stages
+    // (the whole DXGI bridge sequence) are set outside writerMutex_. Sharing
+    // one slot meant a video thread wedged in bridge-copy had its breadcrumb
+    // overwritten with "idle" within milliseconds, so the watchdog reported the
+    // absence of a stage instead of the call that hung -- the exact opposite of
+    // what the breadcrumb is for, on the exact configuration (#252 with system
+    // audio) it was added to diagnose.
+    audioStage_ = "write-audio";
     const bool written =
         succeeded(sinkWriter_->WriteSample(audioStreamIndex_, sample.Get()), "WriteSample(audio)");
-    encodeStage_ = "idle";
+    audioStage_ = "idle";
     return written;
 }
 

electron/native/wgc-capture/src/mf_encoder.h

@@ -93,7 +93,14 @@ class MFEncoder {
     // writer was never configured for.
     bool usesDxgiInput() const;
     // A breadcrumb, not state: safe to read from another thread at any time.
+    // One slot per writing thread, deliberately. encodeStage() names what the
+    // video-writer thread is inside; audioStage() names what the audio-mixer
+    // thread is inside. A single shared slot cannot do both: most of the video
+    // stages are set outside writerMutex_, so an audio write landing every few
+    // milliseconds would overwrite a wedged video stage with "idle" and the
+    // watchdog would report the absence of the very call it is trying to name.
     const char* encodeStage() const;
+    const char* audioStage() const;
 
 private:
     // Contended is not Failed: the bridge is a two-key handshake and a missed
@@ -156,6 +163,7 @@ class MFEncoder {
     // step overruns. `video-writer-join phase=abandoned` says which thread is
     // stuck; this says which call it is stuck in.
     std::atomic<const char*> encodeStage_{"idle"};
+    std::atomic<const char*> audioStage_{"idle"};
     DWORD videoStreamIndex_ = 0;
     DWORD audioStreamIndex_ = 0;
     bool hasAudioStream_ = false;