# readerSource-\>setLooping(false) causes audio play back to stop

**URL:** <https://forum.juce.com/t/readersource-setlooping-false-causes-audio-play-back-to-stop/65418>\
**Category:** General JUCE discussion\
**Created:** [March 5, 2025, 8:44pm UTC](https://forum.juce.com/t/readersource-setlooping-false-causes-audio-play-back-to-stop/65418 "2025-03-05T20:44:01Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![smp](https://avatars.discourse-cdn.com/v4/letter/s/f9ae1b/32.png) [@smp](https://forum.juce.com/u/smp)\
**Post date:** [March 5, 2025, 8:44pm UTC](https://forum.juce.com/t/readersource-setlooping-false-causes-audio-play-back-to-stop/65418/1 "2025-03-05T20:44:01Z")

</div>

If I set readerSource-\>setLooping(false) and the audio file has already looped the audio play back stops. Is this a bug or am I misunderstanding how setLooping works? If it is a bug is there a workaround?

There was discussion about this around seven years ago but I don’t see anything more recent.  
I believe I’m using the latest version of JUCE.

Thanks,  
Stephen

---

<div class="post-metadata">

**Author:** ![bellarmine-head](https://avatars.discourse-cdn.com/v4/letter/b/cc9497/32.png) [@bellarmine-head](https://forum.juce.com/u/bellarmine-head)\
**Post date:** [September 24, 2026, 12:31pm UTC](https://forum.juce.com/t/readersource-setlooping-false-causes-audio-play-back-to-stop/65418/2 "2026-09-24T12:31:32Z")

</div>

It’s a bug. The problem is that the value of `nextPlayPos` gets higher and higher on each play-repeat, whereas it should reset to zero when starting again.

The `getNextReadPosition()` and `getNextAudioBlock()` methods get away with it because of their use of the modulo operator (the `%` symbol). But as soon as looping is switched off, the modulo operator is no longer applied, and you end up with a crazy high value for `nextPlayPos`.

A few ways to go, imo:-

- fix in `AudioFormatReaderSource` and submit a PR
- raise an issue on GitHub and ask the core team to fix
- write your own version of `AudioFormatReaderSource` with the fix, and use that instead.

I wrote my own version of `AudioFormatReaderSource` in order to better control looping between user-set start/end loop points, and in doing so found and fixed this bug in my version. The code looks like this:-

```cpp
juce::int64 RomplerAudioReaderSource::getNextReadPosition() const
{
#if false
    // original
    return looping ? nextPlayPos % reader->lengthInSamples
        : nextPlayPos;
#else
    // new code, to stop 'nextPlayPos' advancing higher and higher forever
    if (!looping)
    {
        return nextPlayPos;
    }
    else
    {
        if (nextPlayPos < reader->lengthInSamples)
        {
            return nextPlayPos;
        }

        nextPlayPos = nextPlayPos % reader->lengthInSamples;
        return nextPlayPos;
    }
#endif
}

```

Two extra things to do:-

1. Mark field `nextPlayPos` as `mutable` in the header file, otherwise `getNextReadPosition()` won’t be able to update it.
2. Change `getNextAudioBlock()` to set `readFrom` by calling the now-correct `getNextReadPosition()` method, instead of repeating the computation.

--

_I’m not saying that the above is the best solution. But it’s a hacky fix that works in my private version of AudioFormatReaderSource. Perhaps a better way is to wrap-around nextPlayPos just after incrementing it._