Re: [PD] Raspberry Pi: Loading Samples RAM problem

Tue, 05 Nov 2019 05:23:57 -0800

Okay,
finally I found some time to try some stuff out. First, I gave Olivers examples a try.
I made a patch with eight [ol_sfplay~] objects to simulate my sample player and tested this patch on my old Raspi 2
and also a Raspi 3. I also tested two different audio interfaces: a Scarlett 2i4 USB audio interface and a HDMI-to-CINCH-Converter running on the 2835 ALSA driver.
The best result was achieved by the Raspberry Pi 3 with the Scarlett audio interface. I used
- block length of 64 from Pd's preferences
- buffersize of 512 and 1024 for [ol_sfplay~]
 
I have no pops and Pd does not freeze.
 
When I use the same configurations with the hdmi-to-cinch-converter and alsa, I get audio pops.
 
When I use the same configurations with the Raspi 2, I get audio pops, even using the Scarlett interface and the Raspi "freezes" somehow. 
It continues to play the eight samples, but my ssh and vnc connections break.
 
Both Raspis are running with the same SD-card, so I conclude that the faster processor of the Raspi 3 and also the use of different audio interfaces have an impact on the audio pops. In terms of the audio interface, I don't understand why.
 
Next, I will have a look at Giulios suggestions:-)
 
Cheers, Jakob
 
 
 
Gesendet: Freitag, 01. November 2019 um 19:07 Uhr
Von: "Antoine Rousseau" <anto...@metalu.net>
An: "Christof Ressi" <christof.re...@gmx.at>
Cc: Pd-List <pd-list@lists.iem.at>
Betreff: Re: [PD] Raspberry Pi: Loading Samples RAM problem
OK.. So I look forward to seeing it!
 
 
Le ven. 1 nov. 2019 à 17:45, Christof Ressi <christof.re...@gmx.at> a écrit :
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
_______________________________________________ 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