[PD] swallow the first bit of audiofile

michael strohmann itsnotfair9 at gmail.com
Sun Mar 10 00:50:13 CET 2019


aha, 
so i will raise the buffer-size for [readsf~] and see what happens.
i never suspected readsf~ to be responsible for the dropout in the beginning, since initially it all worked very well.
only now after the system is runnin 24/7 for couple of month, those drops seem to occur more frequently.
maybe the SD is getting old and slow 


more noise:
the patch is really quite simple, i just want to play back a couple of 4 channel audiofiles, triggered by sensors or via network.
there is only one sf running at a time, and nothing else going on apart from listening to network and reading from GPIO and serial.
the puredata uses around 6 % of CPU and 2 % Memory on the RPi B+
in the past i had stuttering and skipping audio which i attributet to 
1.) the fact that error messages postet to the console started to use much more RAM 
2.) netsend related problems that froze pd
( i hope i got rid of those issues)
i’ve set the BlockSize 512 or 2048 but this does not seem to have an effect.
the soundfiles use around 1GB of memory. (the rpi B+ got 1GB ram)



> On 09 Mar 2019, at 22:49, IOhannes m zmölnig <zmoelnig at iem.at> wrote:
> 
> On 3/9/19 9:46 PM, michael strohmann wrote:
>> i would have expected that it would probably take longer to look for and read the sound file but not that the playback does not start at the beginning.
>> 
> 
> well, we really only know what is happening from what you tell us what
> you are observing.
> e.g. it is unclear whether the entire audio engine stalls (e.g. other
> sounds that are supposed to play back at the same time stutter as well),
> or whether the 0.5 seconds are just skipped.
> 
>> 
>> i was unsing a 2sec delay between [open soundfile.wav( and [start(  would it help to delay even longer???
>> 
> 
> not without also raising the buffer-size for [readsf~].
> 
> 
>> unfortunately the raspberry has limited RAM….
> 
> well, since i have no clue how many audio files you want to play back
> (and how large they are), it is hard to suggest anything meaningful.
> 
> gfdsra
> IOhannes
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list






More information about the Pd-list mailing list