Comment 18 for bug 1777480

If the caching reader is not able to provide the requested samples in time the only consequence should be a short moment of silence produced by 0 samples. Subsequent samples should arrive in time as the reader catches up. This caching issue shouldn't affect the timing in any way, i.e. play time in the engine should pass regardless of which samples are actually provided by the reader at a certain position. The reason why the engine only polls twice for the sample range (non-blocking) and then continues processing to stay in time.

Of course, by jumping around within the track you will very likely see those cache misses. But I suppose it is unlikely that there is any direct causal relationship between those cache misses and the timing issues. There actually would be timing issues only if the engine decided to block and wait for those samples indefinitely.

I've never noticed any audible artifacts caused by cache misses.