Bugzilla – Bug 2472
Windows: Initial dropout when recording.
Last modified: 2020-08-29 11:01:38 UTC
This may be the same bug as 1857, but now with clear steps to reproduce. This behaviour is 100% repeatable, even though I have a fast SSD.
Testing on W10 woth Audacity 2.4.2 3b71d1f I cannot reproduce this om my HP Envy laptop with SSD - WORKS-FOR-ME
Like Peter, I'm unable to make this happen either, so I tried varying the steps and noticed something else that's odd. With a clean config 1) Start Audacity (it's not maximised) 2) Change the Host in the Device toolbar from MME to WASAPI 3) Generate a 30s chirp (it's mono) 4) Click at about 15s 5) Click record button It didn't create a new stereo track as in the original steps and appended the new recording to the chirp track. The default for "Record on a new track" is disabled, so I would think that that it should have appended even using the original steps. Why does changing the device host change things???
(In reply to Leland Lucius from comment #2) > Like Peter, I'm unable to make this happen either Forgot to mention that I tried it using an SSD and a good old spinner. Even modified the steps a bit to use a thumb drive, but could not reproduce.
Peter - requesting you try it again with released 2.4.1. The reason is that released 2.4.1 was built by me using MSVC 2017, whereas Leland's and the GitHub builds are built with MSVC 2019.
Remember that there is an alpha-only command "Detect Upstream Dropouts" at the bottom of the Tools menu and it defaults on. Do the symptoms persist for you when you turn that off?
Re Comment 5 No dropout is reported, and no label is produced, if I disable 'detect upstream dropouts'.
(In reply to James Crook from comment #4) >Peter - requesting you try it again with released 2.4.1. Done - and I still cannot reproduce this - WORKS-FOR-ME on 2.4.1
So this appears to be an intermittent problem, involving "upstream" dropouts only, maybe detecting them spuriously. "Upstream" dropouts create labels of zero duration and they mean that the portAudio thread that consumes sample data from the sound hardware is falling behind. Whereas the downstream dropouts are of non-zero duration and mean that the thread that writes samples to disk is falling behind. Maybe we should disable upstream dropouts? Or ignore them as possibly spurious, only if they occur in the very first invocation of the audio callback during a recording?
I still can't reproduce this on my W10 Pc with latest alpha Audacity 2.4.2 456177a
And I cannot replace this on my Zurich PC (HP Probook 256 SSD) with 3.0.0 Testing on W10 with Audacity 3.0.0 5bc3ae6
(In reply to Peter Sampson from comment #10) "cannot replicate" that is (darn autokorrekt)
Testing back in Manchester with latest alpha Audacity 3.0.0 58adb94 on W10 Home Version 10.0.18363 Build 18363 I still can never replicate this - always WORKS-FOR-ME
Not seeing it in either release or debug with current build(s).
This may have been unknowingly fixed by other work
