You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
renderFrames only collects audio from the first tab, so short clips can be missing with concurrency > 1 #20
After rendering, renderFrames reads window.__RENDIV_AUDIO_SOURCES__ from pages[0] only. Each tab has its own window, and an <Audio> only registers in the tab that rendered a frame where it was mounted. So if a clip only mounts on frames that other tabs rendered, it isn't collected and silently drops out of the mix.
Since every tab pulls frames from the same queue, each one ends up rendering roughly every Nth frame (N = concurrency). In practice that means it mostly hits clips whose <Sequence> is shorter than the concurrency. Longer clips almost always get mounted in the first tab at some point too.
With renderFrames({ ..., concurrency: 2 }), tab 1 renders frame 0 and tab 2 renders frame 1. On master (6d6aca2) the returned audioSources only has a.mp3.
Reading the map from every page and merging by key fixes it. The keys are already content-based, so duplicates collapse on their own. That's in #27.
Activity