Alo Looper Memory Leak Where?

Using MOD devices Troubleshooting
#1

A number of my pedalboards uses the ALO Looper quite heavily. On some boards I have three instances of it. This has historically worked well, but recently I seem to be getting a number of crashes as the memory use goes up and up after every reopening of a board containing such loopers.

For example, using the board (and this being the current board in the system after power is attached to the mod dwarf)

I get:
image

Now just clicking on “Pedalboards Library” and clicking on the same board again to reload it I get:
image

Now just reloading it again, I get:
image

And again
image

And again
image
(Here it seems to have plateau’d).

In all the cases above, I did nothing, just reload the board in the browser.

Now choosing a virtually identical board (except no ALO Loopers)

image

Nothing changed (whatever seems to have been in memory is still in memory)

Now I unplug the mod dwarf, then plug it back in (with the same board with no ALO Loopers in it)

image

Now choosing it again from pedalboard library and reloading

image
Its pretty much the same.

Now again:
image

And again
image

And again
image

Therefore it doesnt seem there is anything in the other plugins causing this leak.

For reference, the other settings used on both boards are:
image

However, when I look in the code for the ALO Loooper

It seems to look ok from a memory point of view.

There is:

static const size_t LOOP_SIZE = 2880000;
...
//and in the insantiation function
self->recording = (float *)calloc(LOOP_SIZE * 2, sizeof(float));

	for (int i = 0; i < NUM_LOOPS; i++) {
		self->loops[i] = (float *)calloc(LOOP_SIZE * 2, sizeof(float));
		self->phrase_start[i] = 0;
		self->state[i] = STATE_RECORDING;
	}
type or paste code here

(which is obviously alot 2880000 * 14 - as well as a few other callocs, yet that all seems to be freed in the cleanup function)

static void
cleanup(LV2_Handle instance)
{
	log("Cleanup");

	Alo* self = (Alo*)instance;

	for (int i = 0; i < NUM_LOOPS; i++) {
		free(self->loops[i]);
	}
	free(self->low_beat);
	free(self->high_beat);
	free(self->recording);
	free(self);
}

So what could be causing this build up of memory.

I really hope I can solve this since the ALO looper is built into the way I use the mod dwarf - but recently I have had a crash on stage.

So if anyone can suggest any leads as to what might be going wrong that would be great. Also, could you see if you can reproduce the memory build up in the first board?

#2

The Alo Looper is a beta plugin, which means that it can be prone to issues.
With this disclosure in mind, since you didn’t have it before, have you, by any chance, updated the MOD OS before this started to happen?

#3

Thanks for getting back.

Regarding the time of update of the MOD OS - I think I just do the updates when they get notified. Here is the current state
image

What might complicate this is that I bought a second-hand mod to complement my existing unit, and have done the “Reboot and Update” process a few times between them. Possibly the first time I did that (around April time) I began to notice more frequent crashes (although this has gone together with me making ever more complicated pedalboards and so could be just coincidence)

This is the details of the second board, which seem identical (just dsp load higher because of different pedalboard)

image

Re-looking at the ALO looper code, the only place that looks a bit suspicious is in the reset() function

self->loop_samples = self->loop_beats * self->rate  * 60.0f / self->bpm;

	if (self->loop_samples > LOOP_SIZE || self->speed == 0) {
		self->loop_samples = LOOP_SIZE;
	}

LOOP_SIZE * 2 * sizeof(float) is the size ofthe initial calloc allocations (the 2 representing stereo I think).
This line suggests that its possible the number of samples being written could outnumber the initial allocation.

In the mod os, if any plugin was doing that, would one of the consequences be the failure to free memory between loading of different pedalboards?

The only other symptom of something going wrong, I’ve seen, is when constructing the second (no alo looper) board, which involved deleting the 3 alo loopers on the original one, there was a very long timelag (>10 seconds), between clicking the bin icons to delete them, and the deletion actually taking place.

Ive also had the "Bug: " toasts come up a few tijmes (in other occasions of adding plugins to boards with high memory use)

#4

My first question is: does the same behaviour happen with both of your MOD Dwarf devices?

That may pretty much be the source of the issue.
I know for a fact that the ALO uses temporary memory, while (for example) the Looperlative LP3 uses storage memory. This makes the second more efficient. Looperlative LP3 was released together with the introduction of the File Handling system on the MOD platform and, behind the scenes, what it does is to record an audio file and store it in the storage of the device. That’s why you have theoretically an infinite loop time.
From here, I take two more questions:

  • 1st (and the obvious one): since the Looperlative LP3 is in stable support and considering that you even have the Basic version, which is free. Wouldn’t that be a suitable replacement for the ALO Looper in your use case? (I personally would also recommend it, despite the amount of work, which I understand).
  • 2nd: When you turn off and turn on the device again, it frees up your RAM, correct?

I believe yes. It seems in everything, the memory would just free up after a reboot (and I’m somehow already answering my own question).

A last brainstorming question: If you load a pedalboard without the ALO Looper and then load again a pedalboard with the ALO Looper, doesn’t that free up the memory?

#5

Thanks very much for this - it really helps me understand.

Yes - the other dwarf also has this build up of ram usage over time. The more I think about it, I think its because recently that I have tried more ambitious pedalboards (with three ALOs in it) - and this is what has made the problem really noticeable (with frequent crashes).

I would like to use something like Looperlative LP3- but the thing which I really loved about the ALO looper is that it doesnt require any use of feet. Rather than using a pedal to start recording, and then again to stop it, the ALO just “arms” a loop, and when an audio threshold is reached starts recording, and then when the time limit is reached, say 4 bars, it stops recording. Therefore there is no footwork synchronization involved. Moreover it has a wonderful UI solution to the problem of mis-recorded loops. You just switch the loop off and then on again within one second (in practice double clicking it) to re-arm the emptied loop. If @looperlative could do a “footless” (or “footloose”) version of his plugin (given that he has solved the audio storage issue) with the same sort of functionality, I’d pay money for it!

Your point about Looperlative LP3 using storage memory - is that the reason each Looperlative LP3 instance on a pedalboard has to have a different number set for it?

Regarding

* 2nd: When you turn off and turn on the device again, it frees up your RAM, correct?
Yes, it just goes back to its normal state

Regarding
A last brainstorming question: If you load a pedalboard without the ALO Looper and then load again a pedalboard with the ALO Looper, doesn’t that free up the memory?

In my experience (I’ll need to verify this) but it just seems to persist in memory. In the example in the first post, RAM had got to 79%, then I opened a virtually identical pedalboard (except for no ALO loopers) and it remained at 79%. What I havent tried is: board with loopers/board without loopers/board again with loopers.

Anyway, thanks very much for the help with trying to understand what is going on. Maybe for now, I just need to use a max of 2 ALO loopers per pedalboard, and have some monologues ready for moments when I need to reboot on stage. I might also see if I could make a looper based on ALO which might be massively reduced in scope: i.e. one mono loop only per plugin with duration only settable by bar multiples

#6

To be honest with you, in my setups, I normally use a single instance of the LP3, but I’m almost certain that, if not the only reason, it’s certainly one reason for that number.

If you manage to rule that out, it would be awesome to understand what can be done (if on the plugin side or something on the MOD OS). I believe it will free up; otherwise, the problem could appear with other plugins as well. But I also didn’t test this out.

You’re welcome :slight_smile: I’m happy to brainstorm this with you.

:rofl: That’s always handy to have a few.

#7

Thanks again @jon for providing such food for thought. Based on your suggestions

I’ve created 4 pedal boards -

  1. Big Muff Only
  2. Big Muff + 1 ALO Looper (2 bars)
  3. Big Muff + 2 ALO Loopers (2 bars each)
  4. Big Muff + 3 ALO Loopers (2 bars each)

Powering on the mod dwarf in (0)
image
Navigating to (1)
image
Navigating to (2)
image
Navigating to (3)
image
Navigating back to (0)
image
Navigating to (1)
image
Navigating to (2)
image
Navigating to (3)
image
Navigating to (0)
image
Navigating to (1)
[weirdly this time taking long time to load]
image
Navigating to (2)
image
Navigating to (3)
image
Though I paused here an it crept up 2% while there
Navigating to (0)
image
Navigating to (1)
image
Navigating to (2)
image
Navigating to (3)
image

nAlos   %Ram
0          24
1          24.3
2          38.1
3          63.1
0          51.5
1          51.5
2          56.1
3          63.1
0          56.2
1          51.5
2          53.8
3          63.3
0          58.4
1          51.5
2          56
3          63.1

However if I think go back to 0, then 1, then 0 again I get

image

so some memory reduction does happen. Now I’ll reboot and to the same cycle but without the 3 alo board.

nAlos   %Ram
0          24
1          24.3
2          38.2   (creeps up to  42.5 after a couple of minutes but stabilizes there)
0          40.2
1          44.4
2          53.9  (am pausing again but seems to be stable)
0          51.6
1          49.3
2          53.9
0          49.3
1          49.3
2          53.9  (seems to stabilize here)
3          63.1  (went on to 3 by accident - this is the result)

Now just alternating between 0 and 1

0          24.1
1          24.6
0          24.1
1          31.3
0          24.9
1          35.6
0          28.7
1          35.5
0          33.3
1          37.9
0          35.5
1          40.1
0          35.5
1          40.1
0          37.8
1          40.1
0          37.8
1          40.1

Stabilizes at 40

Now just to experiment with repeated reloadings of the 1/2/3 boards after rebooting on the zero board

0 24
1 24.7
1 31.2
1 37.8
1 40.1
1 40.1
1 40.1
0 37.8

REBOOT

0 24
2 24.7 started bit crept up to 28.8 after pause
2 38.2 but crept up to 42.5
2 53.9 but stayed there
2 53.9
2 53.9
2 53.9
0 51.6

REBOOT

0 24
3 24.7 started but crept up to 31.1
3 45.5 started but crept up to 51.8
3 63.2 started and stabilized
3 72.3 started and stabilized
3 72.2 started and stabilized
3 72.1 started and stabilized
0 70
3 72.3

Anyway, summing all this up it seems what I can conclude are

  1. No matter how many ALO loopers are on a board, some process of persistent memory increase seems to take place
  2. However it seems to stabilize at a certain point, If 1 ALO, there seems to be a 16% ceiling (memory for the same non ALO board has gone up 16%). If 2 ALOs, there seems to be a ~27% ceiling, and for 3 ALOs its a ~46% ceiling
  3. Going back to a non-alo board, after an alo-board, does reduce the memory use, this reduction does not persist when returning to an ALO board
  4. At certain moments there seems to be a very slow creeping - (i didnt measure the time by recollection seemed to be about 1% every 4 or 5 seconds). I didnt interact with any of the boards (changing parameters, performing, playing) at all, so I dont know what caused that.

Is there something happening at the mod OS or the plugin-host level which limits memory encroachment by a wayward plugin?

Its only recently that I have been experimenting with successive 3 ALO boards and this probably explains why I have managed to play continuously on 3 occasions for between 30 minutes and an hour (involving 8-10 pedalboards) . The ceiling factor seems to mean that though the leaking was taking place, it didnt involve crashes.

Is there a pattern here that might be explicable either by some likely issue in the code - or could it be solved at the plugin-host/os level?

One thing I havent checked - is if there is any interaction with other memory hungry plugins.

Going back to the code

static const size_t LOOP_SIZE = 2880000;

This is multiplied by 14 (6 loops, each stereo, (x2), plus the stereo recording buffer, + some memory for the audio pips) that makes around 40 mb memory allocation each instantiation. Is there a limit on what any plugin can use?

#8

It seemed to me, by quickly reading the levels, that you were reporting with different loads, that when you load multiple times boards with ALO, it clears the memory from the last one, but if the previous was “stuck,” it doesn’t clear it anymore.

…or it clears the memory of a single instance but “forgets” the others (this one may also be the reason for that number that we were talking about on the LP3… although the memory type usage is different on both plugins, this could be an issue).

I don’t think so. Otherwise, for example, a plugin like NAM with a really heavy model would not even be possible to load.

In your place (and as I can understand that you have coding skills), I would try to fix the code of the plugin where you consider it may create issues (experiment a bit…as any time when we code or make music :slight_smile: ), and build it and install it on your MOD Dwarf and see what happens.