as far as i could follow your conversation, readsf~ seams to be a threaded soundfiler.
but: doesn't readsf~ play back and soundfiler write sounds into buffers? i don't know much about the source code of these two objects, but to me they seem to be quite different objects. ...well, i hope that i am wrong :-)
Your're not wrong. soundfiler loads files into arrays (and thus has to read soundfiles faster than realtime), readsf~ plays soundfiles in realtime (and is threaded, whereas soundfiler [in the 'normal' pd version] is not).
The fact that an 'ideal' soundfiler would write a complete file in no time into an array makes it so difficult to code. In pd every action performed by an external (that is not threaded) has to fit into one dsp cycle (i.e. usually 64 samples = the blocksize). Reading a soundfile usually takes longer, that's where the dropouts come from. And the longer the file the longer the dropouts...,
well, what about reading the data to a temporary array that is completely independant from the pd dsp process and when the complete file has been read, it is copied to the destination array. would that be a possible way?
tim