New issue
Advanced search Search tips

Issue 622319 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Apr 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Consider counting currentFrames by render quanta instead render frames

Project Member Reported by rtoy@chromium.org, Jun 22 2016 
Currently, the currentFrame counts by frames (duh!) and is incremented by 128 (a rendering quantum) after each rendering.  

Consider changing this to count by rendering quanta instead.  Then the counters can hold 128 times more data.  While not important on 64-bit builds of chrome, there is (was) a bug filed on windows with a 32-bit build that behaved incorrectly because the frame counter overflowed after about 1 day. (With a sample rate of 48 kHz, a 32-bit counter will overflow in just over 24 hours).  If we change the counter to count in render quanta, this extends the overflow time to 128 days.

Comment 1 by rtoy@chromium.org, Jun 23 2016 

This would mostly work, but the current AudioParamTimeline code depends on being able to work with sample frames so that sampling of the automations is done correctly.

I think it's possible to make AudioParamTimeline support this, but it's a fair amount of work.

Comment 2 by rtoy@chromium.org, Oct 20 2016 

See  issue 415310 .

Comment 3 by rtoy@chromium.org, Apr 26 2017

Status: WontFix (was: Available)
WontFix.  Making this work for AudioParamTimeline would mean using 64-bit integers there to hold the frame counters, which makes AudioParamTimeline slower.
►

Sign in to add a comment