Bugzilla – Bug 1797
Scrub/seek fails to produce sound output on projects longer than 13.5 hours
Last modified: 2021-01-30 17:35:30 UTC
On Windows: for projects of 14 hours or more when trying to use scrubbing or seeking, a) the green play-head triangle in the Timeline disappears when the mouse is moved to scrub/seek b) and no sound output is produced. For projects of 13 hours or less scrub/seek works fine (I have not bisected further to determine the precise cut-off point) This errant behavior appears to be independent of the zoom level in play. This also occurs when the Transport menu scrub commands are used rather than the scrub ruler On Mac: Hear the behavior is slightly different. For a start projects of 14 hours seem to scrub seek fine. But for longer projects (I worked with a 40 hour one) a) the green play-head triangle in the Timeline does not disappear b) when the cursor is moved within half an hour or so of the green triangle the scrubbing/seeking works - and scrubbed/seeked sound is produced c) however when the cursor is moved further from the geen play-head triangle the the sound output ceases d) for scrubbing in c) the play-head remains static (it's meant to) e) but for seeking in case c) the green play-head triangle moves while the cursor is within the 30 mins or so range - but once moved further away not only is there no sound but the green play-head triangle remais static and does not move f) moving the cursor back to with in 30 mins or so range of the green play-head triangle will however caused the scrub or seek to recommence On Linux: I cannot test this - but I assume "All" on the basis of the other two platforms
Note that for the Windows testing I tested on: 1) My new W10 laptop with the SSD (app and project files on SSD) 2) My new W10 laptop with the SSD (app on SSD - project files on 1TB spinning metal disk) 3) My older slower W10 laptop with spinning metal disk In all three use cases the cut-off remained between the 13 hour and 14 hour mark - so the cut-off appears to be independent of disk speed or processor power.
I don't know if this has any bearing at all - but in related testing I tried Studio Fade Out on the 14-hour project - and got the error message >"Selection too long for Nyquist code >Maximum allowed selection is 2147483647 samples >(about 13.5 hours at 44100Hz sample rate." hmmmm 13.5 hours ...
(In reply to Peter Sampson from comment #2) And further bisecting on the W10 14 four project indicates that the cutoff point at which the scrub/seek no longer works is indeed around the 13.5 hour mark.
13.5 hours at 44100Hz sample rate is the maximum number of samples that can be represented as a signed 32-bit integer. As Nyquist is a 32-bit application, this length limitation is intended, and while the error message is not infallible, it provides protection against overflow for at least some Nyquist plug-ins. In the case of this bug 1797, comment 3 seems to suggest that we are using an int somewhere that we should be using a 64-bit sampleCount.
This appears to be working correctly in Audacity 3.0.0 7aa264 on Linux. As Peter mentioned "slightly different behaviour" on MacOS, I'm marking this as must test all OS.
(In reply to Steve Daulton from comment #5) Now tests OK on W10 with Audacity 3.0.0 6c44b4f
(In reply to Steve Daulton from comment #5) Testing on macOS 11.1 Big Sur with Audacity 3.0.0 6c44b4f This now appears to work fine on Mac as well - I tested with a 40-hour mono track and then made a 40-hour stero track from that - all fine.
