fix: keep scheduled audio when a clip ends during an export - #66
Open
moneymaker-ux wants to merge 1 commit into
Open
fix: keep scheduled audio when a clip ends during an export#66moneymaker-ux wants to merge 1 commit into
moneymaker-ux wants to merge 1 commit into
Conversation
During an export the OfflineAudioContext renders behind the frame loop, by up to a second of samples. When a clip ended, forwardAudioDecoder called AudioDecoder.reset(), which stops every scheduled AudioBufferSourceNode at the context's current time. That cut the part of the clip the audio thread had not rendered yet: 40-1000 ms per clip in audio-only exports, 10-60 ms in MP4 exports. In offline modes the decoder now only releases its decoding state when the clip ends. The scheduled buffers already end at the clip's trimEnd, so they stop at the clip's out point on their own. Realtime playback still stops immediately. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AybThRmRHP14dmvwixan1h
|
@moneymaker-ux is attempting to deploy a commit to the Diffusion Studio Team on Vercel. A member of the Team first needs to authorize it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #65.
During an export, the
OfflineAudioContextrenders up to a second behind the frame loop. When a clip ends,forwardAudioDecodercallsAudioDecoder.reset(), which stops every scheduledAudioBufferSourceNodeat the context's current time. That cuts whatever part of the clip the audio thread has not rendered yet:Change
AudioDecoder.release(): drops the decoding state (iterator, first/last buffer) and leaves already scheduled nodes alone.reset()=release()+ stopping the nodes, so its behavior does not change.forwardAudioDecodercallsrelease()when the clip is not playing.renderDataalready truncates every scheduled buffer attrimEnd, so the buffers end at the clip's out point, andonendedremoves them.reset(): seeking and pausing stop immediately, as before.Verification
Each project was exported 3× as audio only (
.ogg, opus) and 3× as MP4. Each export was compared with the expected audio in 10 ms windows.4a652f5+ fix)4a652f5: ogg 120–970 ms lost per clip, mp4 20–50 msOn the 36 s project, each clip's level in the export matches the source within 0.04 dB with the change, so nothing plays past a clip's end either.
npm run lint: no new warnings.npm run check: fails inpackages/assets/src/browser.tswith TS2339 (showSaveFilePickermissing onWindow). It fails the same way onmainwithout this change.