the threaded soundfiler implementation is cool, but it could be greatly simplified with the worker thread API.
 
also, there wouldn't be a need to have a dedicated thread for each object (which doesn't scale very well), and message passing would be done with a lock-free command FIFO (no mutex locking!)
 
Christof
Gesendet: Freitag, 01. November 2019 um 17:30 Uhr
Von: "Antoine Rousseau" <anto...@metalu.net>
An: "Christof Ressi" <christof.re...@gmx.at>, Pd-List <pd-list@lists.iem.at>
Betreff: Re: [PD] Raspberry Pi: Loading Samples RAM problem
There's already a WIP about a threaded soundfiler:
 
with a complement, dispensing to rebuild the whole DSP tree after loading a soundfile:
 
The latter has some impact on CPU load: it significantly lightens normal [tabread]/[tabwrite] usage (no more need to reacquire the array each time), but adds a bit of load for setting it to another table. It also adds a bit of load for DSP-table objects at each DPS-block beginning (to check the table pointer is still valid). I had started to gprof the change, but I didn't go through with it...
 
 
Le ven. 1 nov. 2019 à 14:31, Christof Ressi <christof.re...@gmx.at> a écrit :
another trick is to use [readsf~] in an upsampled subpatch.

BTW, I have ideas for adding a worker thread to Pd (similar to Supercollider), which would help solving a lot of Pd's realtime-safety issues. I want to do that in the next couple of weeks when I have more time.

Chrisotf

> Gesendet: Freitag, 01. November 2019 um 14:21 Uhr
> Von: "oliver" <oli...@klingt.org>
> An: Pd-List <pd-list@lists.iem.at>
> Betreff: Re: [PD] Raspberry Pi: Loading Samples RAM problem
>
> Hi,
>
> try to use "soundfiler" to read only chunks of your files. so it's
> actually more a "harddisk"-streaming method.
>
> have some example patches here:
>
> mind, that this will be obviously limited by the read-speed of your SD-card.
>
>
> best
>
> oliver
>
>
>
>
> Jakob Laue wrote:
> > Dear list,
> > i have a little problem with my raspberry pi..
> > I have built an eight-track sample player patch that runs on a raspberry pi.
> > When the patch loads, it initially loads all the samples it finds in
> > /home/pi/SamplePacks/SamplePack1, SamplePack2 etc..
> > into RAM using the standard approach:
> > - create two tables for each sample
> > - read data into tables with [read -resize table1 table2(
> > Afterwards I use [soundfiler] and calculate the frequency for [phasor]
> > and so on and so forth.
> > The patch works when I load a total amount of 500 gb into RAM.
> > Today I tested to load 9 GB of samples and the result (obviously) is the
> > pi crashing.
> > I have tested on a raspberry pi 2 and a raspberry pi 3. Both pis only
> > have 1 GB of RAM so it's obvious that problems arise trying to load 9 GB
> > of samples.
> > Do you have any hints or ideas how I could solve this problem? Loading
> > from disk while performing is not an option (I think) because of audio pops.
> > Do you know any ways to extend the RAM of the pi?
> > Maybe you know of some other small boards like beagle or so that have
> > more RAM than a pi.
> > Thank you very much! Jakob
> >
> >
> > _______________________________________________
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> >
>
>
> --
> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
> /////////////// http://pendler.klingt.org //////////////
> \\\\\\\\\\\\\\\ http://oliver.klingt.org  \\\\\\\\\\\\\\
> ////////////////////////////////////////////////////////
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>



_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to