Hi,
This seems to have been debated several times. It's one of those recurring subjects. If I had only one wish for Pd it would be to have a non blocking/low priority [soundfiler] alternative.
I have the same trouble as mentioned. I have no graph for the tables, it's not a GUI issue. I thought the problem would go away with a faster disk, I switched from a rather fast laptop HDD to an SSD. No luck, not even the slightest improvement. The problem does seem to go away with a speedier CPU even-though the processor is not under a real strain from the rest of the patch. The bottle neck here is CPU crunching speed. This would mean for me either changing computer or changing my sound card for just little drop outs or switch to Live and M4L. :( Loading more stuff at the beginning is just not an option, I have already a lot loaded and I don't want the restriction of only playing with predetermined stuff.
I had to increase Pd's latency to 300ms to get rid of this on a Core2duo 1.6GHz processor and split the different files into short mono files which restrict the number of elements in each sound bank I'm loading. As this patch is a random sample player running in auto it's not so important if there is some latency, I'm more concerned with the length restriction. More bugging is the MIDI latency that follows the sound latency. It really makes things awkward because you have to either be very slow and patient when moving the controls (it can break the MIDI connexion with looping even if I patched something that tries to prevent that) or split the MIDI subpatch into a separate patch and have net-send/receive on both sides.
Most people loading stuff for sample players already handle the restricted access to the tables being loaded. As long as something happens at the end of the loading (output of the file length) it's ok, we know when loading starts and finishes.
Sorry if I sound raunchy. It's one hassle I have with Pd and my coding knowledge being what it is I can't do more than rant. :)
Cheers Pierre-Olivier
On 04/11/2011 11:26, katja wrote:
By coincidence I noticed an svn commit access request from Damian Stewart, back in 2008, where he proposes to 'implement multithreaded [soundfiler] read' (http://lists.puredata.info/pipermail/pd-dev/2008-12/012447.html). What has become of this? Is there any code from this project?
[readsf~] and writesf~] are threaded, they operate in a child process. I guess it could not be otherwise? Because they do not intend to read all samples at once. Looking at the code in d_soundfile.c, I can understand why the whole of Pd should not be multithreaded. It is a lot of overhead. But [soundfiler~] read is another exceptional case indeed, it needs carefully scheduled loading if it is not to cause buffer underruns elsewhere. Such loading in portions would also mean the whole audiofile is not immediately available in memory. Therefore, the result would somehow be equivalent to the '[readsf~]-in-an-upsampled-patch' trick. But, like Charles pointed out, it is not trivial to find an optimum. I agree Pd should better do this in C.
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list