Why does Looping audio with AudioSampleBuffer tutorial clear buffer on failure to get lock

Development
1

Hello,
I was wondering why does this tutorial return a cleared buffer in getNextAudioBlock when it fails to get the spinlock associated with the audio buffer. The code look like the following (I use it as a reference in my project):

void SamplePlayer::getNextAudioBlock(
    const juce::AudioSourceChannelInfo& bufferToFill) {
  // return buffer data like in:
  // https://docs.juce.com/master/tutorial_looping_audio_sample_buffer_advanced.html

  // safely get the current buffer
  auto retainedCurrentBuffer = [&]() -> BufferPtr {
    // get scoped lock
    const juce::SpinLock::ScopedTryLockType lock(playerMutex);

    if (lock.isLocked()) return audioBufferRef;

    return nullptr; // <- this is returned when lock.isLocked is false, right ?
  }();

  // return cleared buffer if no buffer is set
  if (retainedCurrentBuffer == nullptr) {
    bufferToFill.clearActiveBufferRegion(); // <- this return empty buffer to the caller
    return;
  }

I think I don’t clearly understand the consequences of this race condition handling. To me, the caller would get an empty buffer to play and it would play an audio glitch if there were something in the buffer before.
Is that an edge case that only happen if the lock is used erratically elsewhere, or that someone calls getNextAudioBlock from outside the audio thread and thus is not really something we care about ?