Fix manual triggering in test_audioworklet_emscripten_locks

[sbc100]

At least under chrome it seems that the main thread doesn't run at all until the first few frames have been produced.

This fixes the test failures I've been seeing while working on #24190

[sbc100]

@cwoffenden

[dschuff]

LGTM as a workaround to make the test work. Maybe we should file a bug to track investigating whether this is the desired behavior?

[cwoffenden]

I guess all the audio tests have this problem, though none interact with the main thread (until they're finished).

It's a changed behaviour in Chrome, so certainly worth investigating why.

[sbc100]

@juj, when you designed the audio worklet API did you imagine this kind of thing being possible? Is it even valid (in the audio worklet API) to block on the main thread in this way?

[sbc100]

I guess all the audio tests have this problem, though none interact with the main thread (until they're finished).

It's a changed behaviour in Chrome, so certainly worth investigating why.

I was able to reproduce in both chrome stable and chrome unstable (137) and chrome stable (135)

Are you still unable to reproduce ?

[sbc100]

Perhaps this test is simply not valid. From https://html.spec.whatwg.org/multipage/worklets.html#worklets-motivations and note "Are thread-agnostic. That is, they are not designed to run on a dedicated separate thread, like each worker is. Implementations can run worklets wherever they choose (including on the main thread)."

[cwoffenden]

Are you still unable to reproduce ?

I ran it easily 10+ times today in each browser without problem, and countless times during development on many browser/OS combinations.

Perhaps this test is simply not valid.

[snip]

Interesting point from the spec, and perhaps instead of the main thread a worker should be used? For our use, we don't interact with the main thread like this, it's AW and other threads.