Time Stretch and PV_PlayBuf and PV_RecordBuf Ugens

I’m having some problems with this code. When i run it, the servidor out. this is what I get:
-> Synth('temp__13' : 1000) /b_alloc: memory allocation failed Buffer UGen: no buffer data

for expample i evaluate this code:

~fftsize = 8192; ~hop = 0.25; ~win = 0; f = Buffer.alloc(s, b.duration.calcPVRecSize(~fftsize, ~hop));
and i get this:

/b_alloc: memory allocation failed

What is the result of this expression? This will show how much memory it’s trying to allocate.

hjh

Excuse my ignorance. The result of evaluating that expression is 36828003.0. Does it mean that it exceeds the allocated memory?

That should be about 147MB, which on modern systems shouldn’t be outrageous. I had wanted to rule out a bad value for the number of frames, and I think that’s now properly ruled out.

So it isn’t clear to me why that is happening. In principle, sclang is issuing a b_alloc command for a size which should be about 147MB, and for some reason the malloc() call is failing. But modern systems have 30, 60, 120 times that much memory – should be plenty of headroom. (My phone has 60 times that much RAM.) So there must be some other cause, and to be honest, I don’t have a good guess what that might be.

hjh

I did a little more poking around.

Buffer memory is allocated by the C function zalloc() – meaning that Buffers are not subject to s.options.memSize.

In theory, it could use as much memory as you have in your system up to 2GB because internally it’s capped to a long int. In practice – https://www.quora.com/Why-does-malloc-fail

It means that malloc (a C function that allocates memory) has failed - ie returned NULL. That could occur for a number of reasons:

  1. Your process has reached the limit of the amount of memory it is allowed to allocate
  2. Your system is unable to allocate any more memory - even though in theory your process has not exceeded it’s allocation.
  3. The internal stuctures that malloc uses to allocate and free memory has been corrupted, due to a buffer overflow or similar.
  4. There is sufficient free memory available to be allocated, but it is fragmented such that the requested memory cannot be allocated in a single chunk.

There might be other reasons too - but I have seen all of those in my career.

Of those, #3 is extremely unlikely. #4 is possible, but also unlikely unless you have a very small amount of memory and not much swap space (e.g. embedded device). #2 … doesn’t explain much? Like, maybe reboot? :laughing: #1 may be interesting – is there some configuration active in your system that limits a process’s memory use? (E.g. “ulimit” in Linux.)

What system are you running? How much RAM does that machine have?

Going back to something concrete: I can reproduce the error message by providing a negative buffer size. That was actually my first theory – if calcPVRecSize were returning such a large number that it became a negative 32-bit integer, then it would fail.

b = Buffer.alloc(s, 2 ** 35, 1);

-> Buffer(0, 34359738368.0, 1, 48000.0, nil)
/b_alloc: memory allocation failed

But 36828003.0 is nowhere near big enough for that. … ??? 26 bits, well below 31. (EDIT: Memory allocation in bytes would be this * 4 – but that’s still within the range of positive 32-bit integers.)

Last-ditch on that: Can you do this, to confirm the message that the server is receiving?

s.dumpOSC(1);

~fftsize = 8192; ~hop = 0.25; ~win = 0; f = Buffer.alloc(s, b.duration.calcPVRecSize(~fftsize, ~hop));

hjh

Al evaluar este código, obtengo lo siguiente:

[ "/b_alloc", 4, 36831235, 1, 0 ]

Ok, thanks.

36831235 * 4 (sizeof(float)) = 147324940, which is well within range.

Does it fail every time? Or only after allocating several buffers successfully? (Bc I notice the buffer number is 4, so some buffers had been used before and not released.)

In any case, I don’t see anything in SC’s source code to cause this problem. It’s using a signed long int, whose positive numbers can go up to 2**31 - 1 = 2147483647, 2 billion more than your number. So that part is OK. Then the 147324940 gets passed to the standard C zalloc function, and the OS is returning a “nope, can’t do it.” So I think it’s an issue specific to your system or its configuration. (I did try allocating a buffer of the same size in samples, and it’s no problem on my system.)

How much RAM do you have? How much swap space?

hjh

Also, which operating system?

Mac ventura ok M1 is The operative System

Ok, and: How much RAM do you have? How much swap space?

Does it fail every time? Or only after allocating several buffers successfully?

hjh