From c400406a40c4f839982a4ef97b1bd047fbc3e1b9 Mon Sep 17 00:00:00 2001 From: Sam Clegg Date: Tue, 29 Apr 2025 10:30:13 -0700 Subject: [PATCH] Fix manual triggering in test_audioworklet_emscripten_locks At least under chrome it seems that the main thread doesn't run at all until the first few frames have been produced. --- test/webaudio/audioworklet_emscripten_locks.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/test/webaudio/audioworklet_emscripten_locks.c b/test/webaudio/audioworklet_emscripten_locks.c index 8191704561441..20471eced5f63 100644 --- a/test/webaudio/audioworklet_emscripten_locks.c +++ b/test/webaudio/audioworklet_emscripten_locks.c @@ -46,6 +46,18 @@ double startTime = 0; bool ProcessAudio(int numInputs, const AudioSampleFrame *inputs, int numOutputs, AudioSampleFrame *outputs, int numParams, const AudioParamFrame *params, void *userData) { assert(emscripten_current_thread_is_audio_worklet()); + + // Produce at few empty frames of audio before we start trying to interact + // with the with main thread. + // On chrome at least it appears the main thread completely blocks until + // a few frames have been produced. This means it may not be safe to interact + // with the main thread during initial frames? + // In my experiments it seems like 5 was the magic number that I needed to + // produce before the main thread could continue to run. + // See https://github.com/emscripten-core/emscripten/issues/24213 + static int count = 0; + if (count++ < 5) return true; + int result = 0; switch (whichTest) { case TEST_HAS_WAIT: