On 3/10/19 12:50 AM, michael strohmann wrote:
> 1.) the fact that error messages postet to the console started to use much
> more RAM
use "-stderr"
gamsdr
IOhannes
signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at
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
omg, i was violating all netiquette do-nots.
please forgive me.
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.
unfortunately the raspberry has limited RAM….
i was unsing a 2sec delay
On 3/9/19 5:13 PM, oliver wrote:
>
> are you completely sure ? even if you are, maybe reading & playing an
> arbitrary short soundfile consisting of a 2 hertz sinus at low volume
> every 10 seconds might make sure that the amp REALLY never goes to sleep.
>
or just use an [osc~ 2] instead.
the
extract from readsf~-help.pd:
> You must open the soundfile in advance (a couple of seconds before you'll
> need it) using the "open" message.
>
this will allow readsf~ to fill its buffer before the actual reading begins.
Le sam. 9 mars 2019 à 16:56, michael strohmann a
écrit :
> on rpi /
michael strohmann wrote:
on rpi / stretch / pd-46 || ESI UJ6 Audiointerface…
sometimes the first half second of audiofiles (4 channel) gets swallowed
i am using
[t b b]
| |
[1( [open audiofile.wav(
| /
[readsf~ 4]
my first bet was that the amplifier goes into sleep mode and needs
on rpi / stretch / pd-46 || ESI UJ6 Audiointerface…
sometimes the first half second of audiofiles (4 channel) gets swallowed
i am using
[t b b]
| |
[1( [open audiofile.wav(
| /
[readsf~ 4]
my first bet was that the amplifier goes into sleep mode and needs time to wake
up. but i
