Le 2011-11-04 à 11:50:00, Roman Haefeli a écrit :
The problem with the '[readsf~]-in-an-upsampled-patch' approach is that you cannot know how fast you can do it without interrupting audio. Also you cannot really fine-tune it since you can only set it to a speed to any power of two. Ideally, a threaded [soundfiler] would load the file as fas as possible in the background without interfering with Pd's main process and then it would output a bang when done.
Even if you do tune one [readsf~] to load at an appropriate speed, you need global control to figure out how many [readsf~] can run at once and how much upsampling you have to do on each. Then you really need to make this an abstraction (or a set thereof) because this coordination is getting too complex for copy-paste.
Blechmann-and/or-Grill's solution was to make a queue like this :
static struct t_sfqueue { t_sfprocess *begin; t_sfprocess *end; pthread_mutex_t mutex; pthread_cond_t cond; } *soundfiler_queue;
Where each t_sfprocess saves soundfiler messages for later, remembering the content and destination... and also the next-pointer for making a linked-list.
So, this means that there is only one soundfiler running at a time, which might be faster on the hard disk or not. Depends on which hard-disks they are on and whether they're cached and stuff. It's hard to get smart about it, but running only one soundfiler thread isn't a bad idea.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC