[PD] pix_delay limits

[IOhannes m zmoelnig]

On 2018-07-19 12:32, enrike wrote:
> thanks, I just checked and I am not sure how to understand the results
> 
> - pix_delay 3000 happily goes up to 83% RAM and stays there once the
> delay is full
> - pix_delay 4000 crashes when the RAM reaches 43%

are there other consumers of memory?

> could it be that pix_delay 4000 requires more RAM than the available BUT
> it only crashes after a while when the system or PD realises that there
> is not enough RAM?

Pd doesn't know anything about that.

however, with modern OS, you can overcommit memory, that is, you can ask
for more memory than is actually available, and the OS will happily give
you a handle to that (non-existant) memory, hoping that by the time you
want to use it, some other processes have already released their memory
claims.
you might well experience this.

you can check the size required to store your image data with roughly:
 <numframes>*<width>*<height>*<depth>
with <depth> being 4 for the typical RGBA pixes (the default on linux
and w32) and 2 for YUV (the default on macOS, iirc).

if you don't care about alpha, you could convert the pixes to YUV before
sending them to [pix_delay] using the [pix_yuv] object, possibly
reducing memory load by 50%.

also, these days i'll usually suggest using [pix_buffer] to build your
own delay-line.
it allows you fine-grained control over pre-allocation of the images, as
well as images of varying size and is generally more flexible.

fgamsdr
IOhannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180719/019bdd00/attachment-0001.sig>