This is a behavior that might be better done another way, but I guess calling it a "bug" makes sense to the average person. Feel free to move this, or merge (etc.) if this has been mentioned before. (I did a quick search and couldn't find a similar thread.) This behavior is part of Reaper for Windows 64-bit as well as Reaper for Linux 64-bit.
While moving the playback loop start point, if playback is at (or near enough) the loop end point, Reaper has to keep changing the audio buffer as the loop start point is re-positioned. This results in a glitch (lots of xruns and high RT CPU). It's worse if the audio buffer is large, since Reaper keeps trying to "fill the buffer" as the loop start point's position changes.
Reaper will also make a very slight glitch if you move the loop end point while playback is approaching it, but it's very quick and not really bad.
I request considering adding an option in preferences which is something like
"if loop start point is currently being moved, start the next loop cycle using the previous loop start point to avoid playback glitches". Or to have some kind of tolerance which will only allow buffering during start loop point changes to happen within 1 second / 1 "buffer size" (whatever makes sense) but not smaller increments.
Here's a thread for reference, in which someone was being annoyed and confused by the current behavior. There are 2 videos showing the behavior. He was using a buffer of 4 periods x 528 samples, so it's really bad. I was able to replicate the behavior even at lower buffer size settings as long as I was moving the loop start point just as playback was nearing the loop end point.
https://forum.cockos.com/showthread.php?t=222442
Loop point behavior: suggested change to avoid glitches
Linear Mode
