[PD] Interruption of audio / Loading sound into array

[Pierre-Olivier Boulant]

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

-- 


~    Pierre-Olivier Boulant     ~
-o-     www.puffskydd.net     -o-
~   www.flickr.com/pob31/sets   ~
-o-    www.lepixophone.net    -o-