hi
we are trying to have a few minutes long pix_delay but we are getting errors. it should be somewhere between 3 and 5 mins.
In my linux laptop, a pix_delay with an argument around 4000 crashes PD after 1 min. But a pix_delay with 3000 as argument works fine.
some quick tests
- pix_delay 3000. works fine
- pix_delay 3500. crashes as the object is created ONLY if the GEM
window is open
- pix_delay 4000. crashes around one minute after the object creation
any suggestions? I attach the patch I am using for testing but it is simple and I cannot see anything weird in it.
thanks
enrike
AFAIK it's limited to the amount of RAM you have, so maybe adding RAM might help. Have a look at the memory usage to test this assumption.
On 19.07.2018 12:10, enrike wrote:
hi
we are trying to have a few minutes long pix_delay but we are getting errors. it should be somewhere between 3 and 5 mins.
In my linux laptop, a pix_delay with an argument around 4000 crashes PD after 1 min. But a pix_delay with 3000 as argument works fine.
some quick tests
- pix_delay 3000. works fine
- pix_delay 3500. crashes as the object is created ONLY if the GEM
window is open
- pix_delay 4000. crashes around one minute after the object creation
any suggestions? I attach the patch I am using for testing but it is simple and I cannot see anything weird in it.
thanks
enrike
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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%
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?
og., 2018.eko uztren 19a 12:16(e)an, Max igorleak idatzi zuen:
AFAIK it's limited to the amount of RAM you have, so maybe adding RAM might help. Have a look at the memory usage to test this assumption.
On 19.07.2018 12:10, enrike wrote:
hi
we are trying to have a few minutes long pix_delay but we are getting errors. it should be somewhere between 3 and 5 mins.
In my linux laptop, a pix_delay with an argument around 4000 crashes PD after 1 min. But a pix_delay with 3000 as argument works fine.
some quick tests
- pix_delay 3000. works fine
- pix_delay 3500. crashes as the object is created ONLY if the GEM
window is open
- pix_delay 4000. crashes around one minute after the object creation
any suggestions? I attach the patch I am using for testing but it is simple and I cannot see anything weird in it.
thanks
enrike
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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
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?
yeah RAM usage is around 38% before opening PD
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.
ok thanks! I will have a look into that
-
enrike -
IOhannes m zmoelnig -
Max