----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: katja katjavetter@gmail.com Cc: pd-list@iem.at Sent: Friday, November 4, 2011 12:21 PM Subject: Re: [PD] Interruption of audio / Loading sound into array
Le 2011-11-04 à 11:26:00, katja a écrit :
By coincidence I noticed an svn commit access request from Damian Stewart, back in 2008, where he proposes to 'implement multithreaded [soundfiler] read'
But (multi)threaded [soundfiler] had already been implemented in 2005 (or 2004 ?) by Tim Blechmann.
This and other things didn't get accepted by Miller's branch. In the end, Blechmann decided to become a SuperCollider developer and apparently has stopped using pd.
His threaded [soundfiler] is not in 0.43 either.
Well if it works it should go into Pd-extended 0.43. But if it goes into Pd-extended 0.43, who will maintain it if there are bugs?
-Jonathan
[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.
No, they could read it with a single thread, but it would be bad for latency, because the process could be blocked while waiting for the harddisk, and on top of that, the non-blocking mode (of read/write) usually doesn't work for ordinary files (when I tried, it only worked on pipes and sockets and perhaps some other things, but not ordinary files).
Looking at the code in d_soundfile.c, I can understand why the whole of Pd
should not be multithreaded.
Look for a branch named devel_0_39.
I don't find anything named like « threaded soundfiler » in the sourceforge tracker, so, it's possible that it hadn't submitted. But that might have been already the time at which we started to doubt that things submitted in the tracker forms were likely to be accepted.
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.
If [readsf~]-in-an-upsampled-patch is really a good trick, I dare Miller to publish it as an abstraction with pd, which would be called soundfiler2.pd or similar.
But no abstractions at all are provided with pd, except demos in the tutorials. Which is weird for software in which most users rely heavily on abstractions.
| 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