OK.. So I look forward to seeing it!
Le ven. 1 nov. 2019 à 17:45, Christof Ressi christof.ressi@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" antoine@metalu.net *An:* "Christof Ressi" christof.ressi@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://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
Le ven. 1 nov. 2019 à 14:31, Christof Ressi christof.ressi@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" oliver@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
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
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" oliver@klingt.org *An:* Kein Empfänger *Cc:* Pd-List pd-list@lists.iem.at *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
On Mon, Nov 11, 2019 at 1:56 PM Jakob Laue jakkesprinter@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
-
Antoine Rousseau -
Christof Ressi -
cyrille henry -
Jakob Laue -
Martin Peach -
oliver