@johnwbyrd I have never looked at the source code, but I run a live performance with Pd....... 30 input channels, 8 out..... with live mixing and using [readsf~] for up to 15 minute backing tracks, and I have never had Pd hang even momentarily.
I use extended for that although I doubt the [readsf~] implementation is different.
However, I use windows7....... and is it possible that Pd and the OS treat disk access slightly differently on other systems? I doubt that.
[readsf~] requires an "open" and a "start"...... so it is not forward looking as it might be in an audio editor. However if you program the "open" in advance.... or even at load, then the start is instantaneous (in ram) and you can emulate an instant player.
If Pd is stumbling during playback..... look elsewhere for the problem....... not in [readsf~]......
A multi-GHz processor with rapid disc access should not have problems with audio or Pd...... they use a paltry fraction of the resources available.
Yes..... Pd prioritises audio..... like all programs that use audio.... over video, screen drawing...... everything. So if your patch is struggling in any way you could see the Pd gui stumble.
Check thoroughly your audio and latency settings.... any mismatch with the capabilities of the soundcard could cause what you are seeing.
More here about setting up your computer for audio......... https://forum.pdpatchrepo.info/topic/10125/audio-and-video-why-do-i-have-problems ..... with a link to a good read for problem solving!
You often just need to tell your OS to do as instructed......"and I mean it!"........... Otherwise it prefers to go and peruse it's Facebook page for likes!
Maybe, otherwise, use FL studio or something similar.
Programs written specifically for audio application will have been written in assembly language and be more appropriate for your purposes.
Communication with Pd is usually facilitated through at least midi or OSC messaging.