Re: [PD] Raspberry Pi: Loading Samples RAM problem
thanks, cyrille! Gesendet: Montag, 11. November 2019 um 20:05 Uhr Von: "cyrille henry" An: pd-list@lists.iem.at Betreff: Re: [PD] Raspberry Pi: Loading Samples RAM problem Le 11/11/2019 à 19:53, Jakob Laue a écrit : > Okay, > now I found some time to look at Giulios patch and I think I understood it :P (So many $'s in there :P) > So, what actually happens in that patch is that on [loadbang] we read 32768 samples into an array using soundfiler. > Then when the file should be played, we do play the first 32768 samples using [tabplay~] and simultaneously load the rest of the file using [readsf~]. Then, when [tabplay~] is done playing the first bit of the sample, we send a [1( to [readsf~] to start playing the rest of the file. > I don't have any audio pops playing eight samples simultaneously, even using the cheap hdmi-to-cinch-converter as my audio interface (which caused more pops in comparison to the Scarlett USB interface while trying olivers patch). Also, I don't have to adjust Pd's audio settings. I can use the standard settings (44100, 64 blocksize, 25 msec) and I don't get audio pops, which is good. > > But there is one thing that I realised: The wav-files are not played at original speed. They are all recorded in 122 bpm. When I play them with Giulois patch, the samples are played quite slowly, at around 111 bpm. look like the sample are recorded at 48KHz and play at 44100. > In a later version of my sample player, I want to be able to change the bpm/tempo in which the samples are played, so I will need to have some mechanism for changing this. Using e.g. [phasor~] to play samples, this should work, but I don't know if it will be possible to do this using Giulios approach. In the help file of [tabplay~], it says that samples are played with no transposition, so maybe a transposition will not be possible to implement?! On the other hand, it says that [tabplay~] does not have the interpolation-artefacts that [tabread4~] has, which I would have, if I used a [phasor~] approach. if you want to change the tempo, you need to somehow interpolate the samples... best > All the best, Jakob > *Gesendet:* Dienstag, 05. November 2019 um 15:40 Uhr > *Von:* "oliver" > *An:* Kein Empfänger > *Cc:* Pd-List > *Betreff:* Re: [PD] Raspberry Pi: Loading Samples RAM problem > Jakob Laue wrote: > > 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. > > please also consider using even 2048 as buffersize for [ol_sfplay~]. AND > you might want to increase PD's audio delay with the "-audiobuf" startup > flag. > > try "-audiobuf 120" or higher and work your way down from there. > > i remember using this method on a PI2 with an 8 track wav-file and > really had to increase those values to get a smooth playback. > > it worked alright in the end but then i had no video-traffic ... > > in general, use a PI3 if possible > > best > > oliver > > > > ___ > 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
Re: [PD] Raspberry Pi: Loading Samples RAM problem
Ah yes, Martin, that makes sense! :-) Gesendet: Montag, 11. November 2019 um 20:14 Uhr Von: "Martin Peach" An: Pd-List Betreff: Re: [PD] Raspberry Pi: Loading Samples RAM problem On Mon, Nov 11, 2019 at 1:56 PM Jakob Laue <jakkesprin...@web.de> wrote: Also, I don't have to adjust Pd's audio settings. I can use the standard settings (44100, 64 blocksize, 25 msec) and I don't get audio pops, which is good. But there is one thing that I realised: The wav-files are not played at original speed. They are all recorded in 122 bpm. When I play them with Giulois patch, the samples are played quite slowly, at around 111 bpm. If the wav files were recorded at 48000 and played back at 44100 you would get that. (122/111 ~= 48000/44100) Martin ___ 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
Re: [PD] Raspberry Pi: Loading Samples RAM problem
Le 11/11/2019 à 19:53, Jakob Laue a écrit : Okay, now I found some time to look at Giulios patch and I think I understood it :P (So many $'s in there :P) So, what actually happens in that patch is that on [loadbang] we read 32768 samples into an array using soundfiler. Then when the file should be played, we do play the first 32768 samples using [tabplay~] and simultaneously load the rest of the file using [readsf~]. Then, when [tabplay~] is done playing the first bit of the sample, we send a [1( to [readsf~] to start playing the rest of the file. I don't have any audio pops playing eight samples simultaneously, even using the cheap hdmi-to-cinch-converter as my audio interface (which caused more pops in comparison to the Scarlett USB interface while trying olivers patch). Also, I don't have to adjust Pd's audio settings. I can use the standard settings (44100, 64 blocksize, 25 msec) and I don't get audio pops, which is good. But there is one thing that I realised: The wav-files are not played at original speed. They are all recorded in 122 bpm. When I play them with Giulois patch, the samples are played quite slowly, at around 111 bpm. look like the sample are recorded at 48KHz and play at 44100. In a later version of my sample player, I want to be able to change the bpm/tempo in which the samples are played, so I will need to have some mechanism for changing this. Using e.g. [phasor~] to play samples, this should work, but I don't know if it will be possible to do this using Giulios approach. In the help file of [tabplay~], it says that samples are played with no transposition, so maybe a transposition will not be possible to implement?! On the other hand, it says that [tabplay~] does not have the interpolation-artefacts that [tabread4~] has, which I would have, if I used a [phasor~] approach. if you want to change the tempo, you need to somehow interpolate the samples... best All the best, Jakob *Gesendet:* Dienstag, 05. November 2019 um 15:40 Uhr *Von:* "oliver" *An:* Kein Empfänger *Cc:* Pd-List *Betreff:* Re: [PD] Raspberry Pi: Loading Samples RAM problem Jakob Laue wrote: > 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. please also consider using even 2048 as buffersize for [ol_sfplay~]. AND you might want to increase PD's audio delay with the "-audiobuf" startup flag. try "-audiobuf 120" or higher and work your way down from there. i remember using this method on a PI2 with an 8 track wav-file and really had to increase those values to get a smooth playback. it worked alright in the end but then i had no video-traffic ... in general, use a PI3 if possible best oliver ___ 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
Re: [PD] Raspberry Pi: Loading Samples RAM problem
On Mon, Nov 11, 2019 at 1:56 PM Jakob Laue wrote: > > > Also, I don't have to adjust Pd's audio settings. I can use the standard > settings (44100, 64 blocksize, 25 msec) and I don't get audio pops, which > is good. > > But there is one thing that I realised: The wav-files are not played at > original speed. They are all recorded in 122 bpm. When I play them with > Giulois patch, the samples are played quite slowly, at around 111 bpm. > If the wav files were recorded at 48000 and played back at 44100 you would get that. (122/111 ~= 48000/44100) Martin ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi: Loading Samples RAM problem
Okay, now I found some time to look at Giulios patch and I think I understood it :P (So many $'s in there :P) So, what actually happens in that patch is that on [loadbang] we read 32768 samples into an array using soundfiler. Then when the file should be played, we do play the first 32768 samples using [tabplay~] and simultaneously load the rest of the file using [readsf~]. Then, when [tabplay~] is done playing the first bit of the sample, we send a [1( to [readsf~] to start playing the rest of the file. I don't have any audio pops playing eight samples simultaneously, even using the cheap hdmi-to-cinch-converter as my audio interface (which caused more pops in comparison to the Scarlett USB interface while trying olivers patch). Also, I don't have to adjust Pd's audio settings. I can use the standard settings (44100, 64 blocksize, 25 msec) and I don't get audio pops, which is good. But there is one thing that I realised: The wav-files are not played at original speed. They are all recorded in 122 bpm. When I play them with Giulois patch, the samples are played quite slowly, at around 111 bpm. In a later version of my sample player, I want to be able to change the bpm/tempo in which the samples are played, so I will need to have some mechanism for changing this. Using e.g. [phasor~] to play samples, this should work, but I don't know if it will be possible to do this using Giulios approach. In the help file of [tabplay~], it says that samples are played with no transposition, so maybe a transposition will not be possible to implement?! On the other hand, it says that [tabplay~] does not have the interpolation-artefacts that [tabread4~] has, which I would have, if I used a [phasor~] approach. All the best, Jakob Gesendet: Dienstag, 05. November 2019 um 15:40 Uhr Von: "oliver" An: Kein Empfänger Cc: Pd-List Betreff: Re: [PD] Raspberry Pi: Loading Samples RAM problem Jakob Laue wrote: > 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. please also consider using even 2048 as buffersize for [ol_sfplay~]. AND you might want to increase PD's audio delay with the "-audiobuf" startup flag. try "-audiobuf 120" or higher and work your way down from there. i remember using this method on a PI2 with an 8 track wav-file and really had to increase those values to get a smooth playback. it worked alright in the end but then i had no video-traffic ... in general, use a PI3 if possible best oliver ___ 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
Re: [PD] Raspberry Pi: Loading Samples RAM problem
Jakob Laue wrote: 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. please also consider using even 2048 as buffersize for [ol_sfplay~]. AND you might want to increase PD's audio delay with the "-audiobuf" startup flag. try "-audiobuf 120" or higher and work your way down from there. i remember using this method on a PI2 with an 8 track wav-file and really had to increase those values to get a smooth playback. it worked alright in the end but then i had no video-traffic ... in general, use a PI3 if possible best oliver ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi: Loading Samples RAM problem
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" An: "Christof Ressi" Cc: Pd-List 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: https://github.com/pure-data/pure-data/pull/655 with a complement, dispensing to rebuild the whole DSP tree after loading a soundfile: https://github.com/pure-data/pure-data/pull/667 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... Antoine Rousseau http://www.metalu.net __ http://www.metaluachahuter.com/ 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
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 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" > *An:* "Christof Ressi" , 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: > https://github.com/pure-data/pure-data/pull/655 > > with a complement, dispensing to rebuild the whole DSP tree after loading > a soundfile: > https://github.com/pure-data/pure-data/pull/667 > > 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... > > Antoine Rousseau > http://www.metalu.net <http://metalu.net> __ > http://www.metaluachahuter.com/ > <http://www.metaluachahuter.com/compagnies/al1-ant1/> > > > Le ven. 1 nov. 2019 à 14:31, Christof Ressi 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" >> > An: Pd-List >> > 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
Re: [PD] Raspberry Pi: Loading Samples RAM problem
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" An: "Christof Ressi" , Pd-List Betreff: Re: [PD] Raspberry Pi: Loading Samples RAM problem There's already a WIP about a threaded soundfiler: https://github.com/pure-data/pure-data/pull/655 with a complement, dispensing to rebuild the whole DSP tree after loading a soundfile: https://github.com/pure-data/pure-data/pull/667 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... Antoine Rousseau http://www.metalu.net __ http://www.metaluachahuter.com/ 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
Re: [PD] Raspberry Pi: Loading Samples RAM problem
There's already a WIP about a threaded soundfiler: https://github.com/pure-data/pure-data/pull/655 with a complement, dispensing to rebuild the whole DSP tree after loading a soundfile: https://github.com/pure-data/pure-data/pull/667 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... Antoine Rousseau http://www.metalu.net <http://metalu.net> __ http://www.metaluachahuter.com/ <http://www.metaluachahuter.com/compagnies/al1-ant1/> Le ven. 1 nov. 2019 à 14:31, Christof Ressi 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" > > An: Pd-List > > 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
Re: [PD] Raspberry Pi: Loading Samples RAM problem
https://supercollider.github.io/
it consists of an audio server ("scsynth" + a multi-threaded re-implementation called "supernova"), an interpreted scripting language ("sclang") and an IDE ("scide"). It's very different to Pd but it's worth taking a look.
Christof
Gesendet: Freitag, 01. November 2019 um 14:44 Uhr
Von: "Jakob Laue"
An: "Christof Ressi"
Cc: Pd-List
Betreff: Aw: Re: [PD] Raspberry Pi: Loading Samples RAM problem
Thanks to all of you for your quick replies!
I will check out all of your suggestions and @Christoph, looking forward for your worker thread implementations.
I have never heard of Supercollider, would that help my in any way?
Cheers! Jakob
Gesendet: Freitag, 01. November 2019 um 14:31 Uhr
Von: "Christof Ressi"
An: Pd-List
Betreff: Re: [PD] Raspberry Pi: Loading Samples RAM problem
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"
> An: Pd-List
> 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
Re: [PD] Raspberry Pi: Loading Samples RAM problem
Thanks to all of you for your quick replies! I will check out all of your suggestions and @Christoph, looking forward for your worker thread implementations. I have never heard of Supercollider, would that help my in any way? Cheers! Jakob Gesendet: Freitag, 01. November 2019 um 14:31 Uhr Von: "Christof Ressi" An: Pd-List Betreff: Re: [PD] Raspberry Pi: Loading Samples RAM problem 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" > An: Pd-List > 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
Re: [PD] Raspberry Pi: Loading Samples RAM problem
You cannot really "extend" the RAM of a board. You need a more clever way of loading samples. One common approach is to load only the beginning of all the samples in a table, and then whenever the sample is triggered, start by playing back the pre-loaded table, while you start reading the remaining of the file from disk with [readsf~]. Here is the code for such a solution: https://github.com/giuliomoro/dynamic-load-files-Pd 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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi: Loading Samples RAM problem
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" > An: Pd-List > 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] Raspberry Pi: Loading Samples RAM problem
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
