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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
