Bugzilla – Bug 1910
Enh: Jerky meters, waveform and Timer Record Progress dialog in 2.3.0 on some PCs
Last modified: 2018-08-20 11:45:18 UTC
Testing on a fix for Bug #42 (with a test group of 7 of whom 5 have reported back) has revealed two testers for whom Recording and Timer recording shows visual jerkiness in the meters, waveform and Timer Record Progress dialog. For both of these users this does not happen on 2.2.2 For the first user Wayne (Forum id FL Coast) this only happens on his older lower powered PC (originally Vista upgraded to W7 and later to W10). It does not happen on his new more powerful PC or his wife's PC with 2.3.0 alpha Detailed report from Wayne to follow in this thread. The second user (Emerogork on the Forum) reported: >Observed that the Progress bar, Lapsed time. >Remaining time updated intermittently, not predictably. He did not comment on waveform or meters. Three other users have tested the potential Bug #42 fix - none of them has reported such jerkiness. I do not observe such jerkiness with Recording or Timer Recording on any of my PCs with 2.3.0 alpha, or of course 2.2.2 - so WORKSFORME I recall no reports of such jerkiness on the Forum from any 2.3.0 alpha users
Report from Wayne (FL Coast) 1) When recording with version 2.3.0-alpha the VU meters and waveform are very jerky (erratic) in their advancement. This worsens slightly when using the Timer Record. Playback of the recorded material sounds fine. When recording with version 2.2.2 the VU meters and waveform flow smoothly. 2) The elapsed time was slow updating. It would update every 2 to 11 seconds. (i.e. the counters in the progress dialog) 3) Under “Options” “After Recording completes” “Exit Audacity” would hang on the “Save Project” dialog box until clicked. The first two items would also happen even if you were just recording without the timer. I replaced my antiquated desktop recently and the new desktop has Windows 10 Pro, and Audacity Version 2.2.2 Record Timer worked without issues. So the problem was isolated to my laptop with Windows 10 Home. The System: HP Pavilion dv9825nr Notebook PC Intel Core 2 Duo CPU T9300 @2.50 GHz 4 GB Ram Windows 10 Home Version 1803 (This is an upgrade from Windows 7 when Windows 10 first came out) Windows Defender Programs I have running at time of recording Internet Explorer running YouTube video Audacity Background items running at time of recording Realtek HD Audio Manager Windows Defender The hard drive is internal Toshiba 1 TB 7200 RPM. Running 2.3.0 while recording an existing file from the hard drive to 2.3.0 it is not as jerky as with YouTube running, but is still detectable, a 2 second jump every so often. Running record with nothing else is open the wave bar is still jerky even though it is not painting anything. With Drop Out Detection disabled the results were the same as if it were enabled.
This may be related to Bug #1886 Sluggish behaviour caused by the large time taken to draw the Track Control Panel
We have had no such jerkiness reports from Mac or Linux users as Far as I recall.
Tested this on out ultra-low-spec Samsung notebook and I actually see an improvement in 2.3.0 over 2.2.2 Spec: Intel Atom CPU N550 1.5GHz 2.00GB RAM 32-bit W10 Disk 232GB used 139Gb free 92,8GB With 2.2.2 with Timer Record the timers in the progress dialog do not update at all. With 2.3.0 alpha the Timer Record progress dialog does update albeit erratically. In the test at: 5, 7, 15, 27, 30, 33, 42 seconds ... For both I see a slightly more jerky response of the meters and waveform than I am used to seeing on my very high spec SSD PC - but perfectly usable meters and waveform and somewhat expected for such a low-grade PC
(In reply to Peter Sampson from comment #4) Repeated these same tests on the low-spec Samsung notebook but this time using my Edirol UA-1EX external soundcard with anolg input from FM radio. Test results same as in Comment #4 => the external soundcard makes no difference.
I ran Timer Record tests on the low-spec Samsung today with: 1) waveform scrolling turned off 2) dropout detection turned off 3) both turned off I all 3 use cases I get the same result: a) 2.2.2 => no update of the progress timers b) 2.3.0 alpha => sporadic update of progress timers I also note that with 2.2.2 it fails to stop the TR after the stop request is confirmed in the dialog, carrying on with the timed recording necessitating a force quit from the Task Manage. But 2.3.0 alpha does honor the Stop. Having looked at the waveform update on both this slow low-spec notebook and my high-spec laptop, I observe that although the waveform update is a bit jerky on the notebook - it is also jerky on the high-spec laptop, updating in about half-second chunks or so rather than smooth scrolling (and this is true of both pinned and un-pinned recordhead. I therefore conclude that in respect of this bug (on my low-spec notebook at least) that 2.3.0 behavior is actually an improvement over 2.2.2 - and not the regression that we originally thought from the two reports from our TR testers.
*** STEPS UPDATED *** And also made into an Enhancement request. (for smoother behaviour on lower powered hardware).
I believe this is much improved by the fix for Bug 1886. I could get 'old low powered PC' behaviour by TR with 16 tracks on a fast PC. Now that is so much improved that I think this bug can be closed, so marking DEVEL - FIX MADE on the basis of the Bug 1886 fix. Note that potentially we could do even better, but I don't think it merits the extra work given how well it behaves now.
(In reply to James Crook from comment #8) Testing with 16 stereo tracks on my hi-spec W10 laptop, the update f the TR progress counters is much smoother - but does still miss the occasional second - but only one second and only occasionally - I think I would regard this as acceptable. I will try on my low-spec notebook later.
Wayne reports much improved behaviour on low-powered Atom processor. I think we can close this.
