General guidance around server memory allocation please

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

General guidance around server memory allocation please

lea nicholson
I am generating notes from a virtual keyboard on an iphone/touchOsc setup and this is triggering synths in SC which are derived from a variant of the "help_SPE1" synthdef used in the Understanding Streams, Patterns and Events tutorials. 

As far as I can see at maximum I end up with about 30 synths active at any one time and these contain some 500 ugens (in total, not individually).

I occasionally get "exception in realtime: alloc failed, increase server's memory allocation (e.g. via ServerOptions)" error messages.

What would be a sensible increased value to apply here?

I understand that the default is 8192 kilobytes, so are we talking double that? quadruple that? I.e. what kind of orders of magnitude increase are meaningful in this context? In particular what is the minimum value that is likely to get rid of my problem? (Bear in mind that it is generally some considerable period of time before I get this error message - half an hour, forty minutes or more). The computer I am using has 8GB of memory.

Thanks





  
Reply | Threaded
Open this post in threaded view
|

Re: General guidance around server memory allocation please

Josh Parmenter
I usually set mine to 32768. This is the memory pool that delay UGens and that sort of thing pull from. I’d keep it below gigabytes (personally), but I can’t think of a reason you couldn’t get into that range if needed?

You can set it to larger pretty safely, depending on your needs.

Best,

Josh

> On Feb 6, 2018, at 1:10 PM, [hidden email] wrote:
>
> I am generating notes from a virtual keyboard on an iphone/touchOsc setup and this is triggering synths in SC which are derived from a variant of the "help_SPE1" synthdef used in the Understanding Streams, Patterns and Events tutorials.
>
> As far as I can see at maximum I end up with about 30 synths active at any one time and these contain some 500 ugens (in total, not individually).
>
> I occasionally get "exception in realtime: alloc failed, increase server's memory allocation (e.g. via ServerOptions)" error messages.
>
> What would be a sensible increased value to apply here?
>
> I understand that the default is 8192 kilobytes, so are we talking double that? quadruple that? I.e. what kind of orders of magnitude increase are meaningful in this context? In particular what is the minimum value that is likely to get rid of my problem? (Bear in mind that it is generally some considerable period of time before I get this error message - half an hour, forty minutes or more). The computer I am using has 8GB of memory.
>
> Thanks
>
>
>
>
>
>  


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|

Re: General guidance around server memory allocation please

Nathan Ho
In reply to this post by lea nicholson
On 2018-02-06 13:10, [hidden email] wrote:
> I am generating notes from a virtual keyboard on an iphone/touchOsc
> setup and this is triggering synths in SC which are derived from a
> variant of the "help_SPE1" synthdef used in the Understanding Streams,
> Patterns and Events tutorials.

hi lea,

the main thing consuming memory in that synthdef is going to be those
allpass delays:

4.do({ out = AllpassN.ar(out, 0.05, [0.05.rand, 0.05.rand], 4) });

if we're running at 48kHz, the delay line memory size for each AllpassN
is 0.05s = 2400 samples, or 4096 because we round up to the next power
of two. 4096 samples * 4 bytes per sample * 8 copies of AllpassN = 128kb
for each running synth. (hope i did the math right...) it's not hard to
imagine that you can run out of RT memory with dozens of running synths,
especially if you've modified this.

in this case, you can save a lot of memory and CPU by moving this series
allpass network to a separate effect synth. it will sound a little
different because the doneAction is prematurely truncating the decay
tail.

i expect this optimization will solve the problem completely, but you're
also free to double or quadruple the memory size if you plan on using
many delay lines.

furthermore, ugens like BufDelay* and BufAllpass* allow you to use a
Buffer for the delay line memory. Buffers don't eat into real-time
memory, but you are responsible for allocating and freeing them. you
probably don't want a situation where you're allocating and freeing a
Buffer for every synth though -- the entire point of real-time memory
allocation in the first place is that it's fast.


nathan

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|

Re: General guidance around server memory allocation please

lea nicholson
In reply to this post by lea nicholson