<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Okay,</div>
<div>now I found some time to look at Giulios patch and I think I understood it :P (So many $'s in there :P)</div>
<div>So, what actually happens in that patch is that on [loadbang] we read 32768 samples into an array using soundfiler.</div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div><br/>
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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>All the best, Jakob</div>
<div>
<div style="margin: 10.0px 5.0px 5.0px 10.0px;padding: 10.0px 0 10.0px 10.0px;border-left: 2.0px solid rgb(195,217,229);">
<div style="margin: 0 0 10.0px 0;"><b>Gesendet:</b> Dienstag, 05. November 2019 um 15:40 Uhr<br/>
<b>Von:</b> "oliver" <oliver@klingt.org><br/>
<b>An:</b> Kein Empfänger<br/>
<b>Cc:</b> Pd-List <pd-list@lists.iem.at><br/>
<b>Betreff:</b> Re: [PD] Raspberry Pi: Loading Samples RAM problem</div>
<div>Jakob Laue wrote:<br/>
> Okay,<br/>
> finally I found some time to try some stuff out. First, I gave Olivers<br/>
> examples a try.<br/>
> I made a patch with eight [ol_sfplay~] objects to simulate my sample<br/>
> player and tested this patch on my old Raspi 2<br/>
> and also a Raspi 3. I also tested two different audio interfaces: a<br/>
> Scarlett 2i4 USB audio interface and a HDMI-to-CINCH-Converter running<br/>
> on the 2835 ALSA driver.<br/>
> The best result was achieved by the Raspberry Pi 3 with the Scarlett<br/>
> audio interface. I used<br/>
> - block length of 64 from Pd's preferences<br/>
> - buffersize of 512 and 1024 for [ol_sfplay~]<br/>
> I have no pops and Pd does not freeze.<br/>
> When I use the same configurations with the hdmi-to-cinch-converter and<br/>
> alsa, I get audio pops.<br/>
<br/>
please also consider using even 2048 as buffersize for [ol_sfplay~]. AND<br/>
you might want to increase PD's audio delay with the "-audiobuf" startup<br/>
flag.<br/>
<br/>
try "-audiobuf 120" or higher and work your way down from there.<br/>
<br/>
i remember using this method on a PI2 with an 8 track wav-file and<br/>
really had to increase those values to get a smooth playback.<br/>
<br/>
it worked alright in the end but then i had no video-traffic ...<br/>
<br/>
in general, use a PI3 if possible<br/>
<br/>
best<br/>
<br/>
oliver<br/>
<br/>
<br/>
<br/>
_______________________________________________<br/>
Pd-list@lists.iem.at mailing list<br/>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" target="_blank">https://lists.puredata.info/listinfo/pd-list</a></div>
</div>
</div></div></body></html>