Bugzilla – Bug 860
Big delays starting loop-play of very short selections
Last modified: 2018-08-20 11:51:52 UTC
I am guessing there is a connection to bug 545. Disabling the caching of block file contents in memory explains these long delays. One block file, or perhaps two if the selection happens to straddle a boundary between block files, are opened and closed repeatedly while AudioIO::FillBuffers repeatedly appends the selection to fill out a four second buffer. But this problem can be fixed by other means without enabling the cache.
Created attachment 576 [details] Fix bug 860. With this fix, the opening and closing of the block files may happen at most three times, for each filling of the ring buffers (usually four seconds of playback). Not a number of times inversely proportional to the length of the selection. Possibly once for a partial period at the start of the buffer, and once again for a partial period at the end, but once only for all complete periods that fit in the middle.
Thanks, Paul. Equally noticeable for me, Meter Toolbar can show playback for several seconds after Stop is pressed and audible playback ceases. Please don't forget to add the "patch" keyword when you add a patch. Then the bug will show up in a search for patches.
I wrote one possible fix, but now I am contemplating a fix by other means that might help other performance problems such as drawing spectra.
Please see the patch for Bug 900 which fixes this problem by other means, and also improves the performance of spectrograms. I consider that patch to supersede this one.
Comment on attachment 576 [details] Fix bug 860. Paul regards the patch for bug 900 supersedes this patch
On second thought, the patch I made here, while less general, may give better performance improvement for this special problem. But bug 900 removes a large part of this delay and that code also applies to other performance problems.
(In reply to comment #6) Paul wrote: > On second thought, the patch I made here, while less general, may give better > performance improvement for this special problem. But bug 900 removes a large > part of this delay and that code also applies to other performance problems. On Win 7 HDD, 2.4 GHz, 6 GB RAM, the performance increase with the currently obsoleted patch for this bug is dramatic (no perceptible delay starting to loop selection of 1 ms). The same selection takes 1 second to start looping with the bug 900 patch and 3 seconds in HEAD. So, if we go with this patch for this specific delay problem, does the patch for bug 900 need to change?
Gale, if this patch applies, then Mix.cpp and Mix.h can be left out of the other patch for Bug 900, while the benefits for faster zooming of the spectrogram would remain. If the scrubbing project http://audacity.238276.n2.nabble.com/Scrubbing-project-tc7567831.html is committed, then there might be some benefit in leaving Mix.h and Mix.cpp in. Scrubbing might cause less disk access with this patch.
Gale, do you agree that the patch at bug 900 relieves this problem somewhat, though less than this patch.
(In reply to comment #9) > Gale, do you agree that the patch at bug 900 relieves this problem somewhat, > though less than this patch. On the basis of one machine on Windows only (default 100 ms buffer), yes the bug 900 patch relieves the problem somewhat - see comment 7. But even a 1s delay starting playback as observed with the bug 900 patch is much more irritating than no delay. I do not say anything about Mac or Linux yet.
The better fix mentioned in comments above was already made as improvement to the scrubbing engine. I discovered a remaining edge case in which the selection is even shorter than one sample interval -- that was causing a true infinite loop, not just a big delay before starting play. That is fixed here. https://github.com/audacity/audacity/commit/2361121b80695a6989a8fec9fbaae54b20062cf0
Testing on W10 and Mac on r145a54d 05Jul16 With ten samples ther is a tiny noticeable delay - (with 2 or 3 samples there remains a noticeable delay - but this is an edge case - I'm not sure why anyone would want need to lop play such a small number of samples. Same on both platforms
Paul, I am not sure if you are expecting there would still be some performance degradation if loop playing only a few samples. Do you still expect more slowness as number of samples decreases? On slow Ubuntu notebook with pulse, below are the delays starting playing. After pressing Stop the playback meter remains active for the same amount of time and so Audacity is not usable for that time. 5 samples 0.5 seconds 4 samples 1 second 3 samples 3 seconds 2 samples 30 seconds 1 sample 90 seconds But playback and stop is immediate with less than one sample selected. Comparative timings in 2.0.4 in Ubuntu on the netbook are about three times the delay listed above, and the delay becomes 0.5 seconds or more at 20 samples. I'm happy to resolve this Paul, unless you are unsatisfied by the above timings. On Ubuntu 16.04 on faster laptop 2.4 GHz, 2 samples playback is delayed by 3 seconds and 1 sample by 6 seconds, about the same as Win 10 on same hardware.
(In reply to Gale Andrews from comment #13) I'm also getting slow times on Debian, but improved from old Audacity versions and I think that some slowness is probably inevitable. I dare say that further optimisation is probably possible, though I doubt that it is worth the effort (except perhaps as an exercise) - is there is a practical use case for loop playing less than 10 samples?
(In reply to Steve Daulton from comment #14) Even on the Linux netbook I have to get down to less than five samples for there to be a noticeable delay, although that delay is then severe. I think there could be some scientific use case for looping only a few samples but I would expect machines being used for scientific purposes to be modern and fast. Paul hasn't replied to date, so I resolved it WORKSFORME meaning "good enough". If Paul envisages further worthwhile optimisations he can reopen the bug.
