Skip to content

js: finish initialization when audio is already running - #314

Merged
hajimehoshi merged 1 commit into
ebitengine:mainfrom
kumagi:codex/js-running-ready
Oct 9, 2026
Merged

hajimehoshi merged 1 commit into
ebitengine:mainfrom
kumagi:codex/js-running-ready

Conversation

@kumagi

@kumagi kumagi commented Oct 9, 2026

Copy link
Copy Markdown
Contributor

What issue is this addressing?

None

What type of issue is this addressing?

bug

What this PR does | solves

When an AudioContext starts in the running state (for example, where autoplay is allowed), initialization still waits for a user gesture. Mark this initial state as resumed and use the existing initialization gate, which continues to wait for AudioWorklet module setup before closing ready.

Validation: real headless Chrome with autoplay allowed and the actual Oto WASM build timed out waiting for ready before the fix and completed without a gesture afterward. A suspended real AudioContext continued waiting, and the existing gesture resume path completed initialization. This does not change the handling of programmatic Resume or later suspend/resume transitions.

Native macOS builds and internal package race tests passed, as did Windows 386/amd64/arm64 and WebAssembly cross-builds. The full macOS suite fails AudioQueueStart and then times out in TestSetBufferSize on both the unchanged upstream and this checkout; macOS vet reports the same pre-existing driver_darwin.go unsafe.Pointer warning.

@hajimehoshi
hajimehoshi merged commit 22cb115 into ebitengine:main Oct 9, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants