ok, had a quick look…
for me, I could see when it failed, it was being killed… but unfortunately i couldn’t see what was killing it.
(unfortunately, we cant install gdb on the current OS,so I cant see the stack trace to get more details)
it could either be a segv fault, or it could be pd watcher is killing it due to not responding.
but honestly, I suspect the underlying issue is exceeding processor/hardware limitations, and its just not failing elegantly (with decent error messages)
your allocating 10 x 1 mins of audio buffer, but Im pretty sure @oweno has said in practice they got 5-6 minutes(*)?
so I think its going to run out of memory, which i think along with the indeterminate initialisation you have, is probably why its fairly randomly crashing.
PDs error checking is not great, so Id suspect one of the mallocs is failing ‘quietly’ and then something is trying to right in the memory region regardless.
not sure , why it sometimes it appears to work… id have said perhaps swapping, but afaik there is no swap configured (inappropriate for audio use), or perhaps this is related to a pd mem issue (see below)
(*) ok, I will say here, I don’t know why the available ram is so low, 10 minutes, even if using 32bit floats (as pd does i believe) is only 1.68mb (EDIT: see below, misread this) , the organelle is reporting 216mb free … so its a drop in the ocean really.
but to take this further, Id have to do some experimentation to see if PD is ‘exploding’ the size (so a PD issue) , of a more general linux/pd issue where the process is restricted in ram usage. unfortunately thats a bit time consuming to do properly - which i dont have at the moment.
EDIT: im a bit confused by your tables, although they have a size parameter (100), the size reported in the properties is still 2470129… so give we have 40 of them, and they are 4 bytes each … thats 376Mb which is too much.
so id suggest perhaps checking that size is really used from startup, i.e. PD doesn’t do something silly like try to allocate the sizes, and then later free them to reduce in size…
perhaps set them all to 0 in properties, and then use a variable passed in as arguments, so its easy for you to change without loads of typing .
I think your usb audio setup is probably overly optimistic,
i doubt your going to get 8 channels input and 10 channels of output with a buffer of 6 msec, (~270 samples) - I doubt the organelle has the throughput on usb nor the processing power.
(lets bare in mind the organelle was designed for 2 ch I/O at 4ms (176 samples) on an internal bus)
I assume you are also sending midi over this usb, so thats also extra data on top of your usb for audio.
sorry, as i say without gdb, not a lot I can see about exactly where its crashing, so all I can say is I think its too cpu and memory heavy, and PD is just coping with this poorly. (crashing)
Ive seen this with Orac, once you go over a certain cpu load, PD/arch linux start having really issues - this is partly because we run PD with realtime priority i.e. its CPU usage starts affecting system services.
as its hardware specific, Im sure it works on other hardware, so ive no opportunity to test on something else.
I dont have time to install it, on my upgraded linux image for organelle. (which is on the back burner at the moment) which would give me gdb.
what I would suggest is start hacking the patch back, less loopers (so less memory) and less IO channels, and higher buffer sizes - perhaps cut it back to the minimum, and then build it back up slowly.
this will hopefully let you find the ‘practical’ rather than theoretical limit of the Organelle.
of course, all just my opinion, about how Id tacked it.
if you really believe these are not the issues, your other cause of action is still similar, cut back the patch to find the ‘offending’ code that is blowing up.
