1
0
mirror of https://github.com/cookiengineer/audacity synced 2025-07-25 08:58:06 +02:00

Disable part of the drop-out detection...

... The part that checks the previously unused statusFlags argument of
audacityAudioCallback can make zero-length labels.  I did provoke this into
happening repeatably on macOS using a debug build, zero buffer length in device
preferences, and a busy CPU running other programs, within just two minutes of
recording.

But close zooming in on the label, and listening, revealed nothing obviously
wrong, no click in the playback.  So I consider that a false positive.

But the part of the drop-out detection that would make nonzero length
labels, because the other AudioThread is lagging in its writes to disk --
this part remains.  Yet I have not yet provoked this into happening.
This commit is contained in:
Paul Licameli 2018-01-15 19:29:45 -05:00
parent d2749068f1
commit b0690a2a5c

View File

@ -5153,10 +5153,12 @@ int audacityAudioCallback(const void *inputBuffer, void *outputBuffer,
if( inputBuffer && (numCaptureChannels > 0) )
{
// The error likely from a too-busy CPU falling behind real-time data
// is paInputOverflow, but let's check the other input error too
// is paInputOverflow
bool inputError =
(statusFlags & (paInputOverflow | paInputUnderflow))
(statusFlags & (paInputOverflow))
&& !(statusFlags & paPrimingOutput);
// But it seems it's easy to get false positives, at least on Mac
wxUnusedVar( inputError );
size_t len = framesPerBuffer;
for(unsigned t = 0; t < numCaptureChannels; t++)
@ -5173,7 +5175,8 @@ int audacityAudioCallback(const void *inputBuffer, void *outputBuffer,
// enough from mCaptureBuffers; maybe it's CPU-bound, or maybe the
// storage device it writes is too slow
if (gAudioIO->mDetectDropouts &&
(inputError || len < framesPerBuffer) ) {
(//inputError ||
len < framesPerBuffer) ) {
// Assume that any good partial buffer should be written leftmost
// and zeroes will be padded after; label the zeroes.
auto start = gAudioIO->mTime;