[buffer~: out of memory reading] but the system has lots of inactive memory!

prko's icon

Dear users,

while MAX5 loads audio files into buffer~, it displays the following error:

buffer~: out of memory reading

However, OS X Activity Monitor shows still 1.12 GB of inactive memory.
What is wrong?

Is there no any possibility to display a wave form except using buffer~?

best,
prko

prko's icon

is it possible to connect the buffer of sfplay~ (diskbuffer) with the waveform~?

Peter Castine's icon

How big are the files you are trying to read?

One consideration: for all you may have umpteen terabytes of free memory in your machine, out of a combination of legacy and performance concerns certain objects can only allocate a maximum of 64kB at a time. Other objects may possibly only have this limit depending upon what thread they're in at the time of allocation.

I was not aware that buffer~ had this particular restriction, at least not at instantiation time. Hence the question above.

FTR: On Max 4 this limit was 32kB.

FWIW: I can't replicate your error. Add'l details?

prko's icon

I have tried to load 12 audiofles.
Each files' length is over 10 minutes.

best,
prko

Peter Castine's icon

10" is pretty long for buffer~. Don't forget that MSP is using 32-bits/sample, which in most cases makes the memory requirements twice what an AIFF or WAV file needs on disk. At stereo you're talking >200MB per file. Do the math;-)

Plus, if you've got a waveform~ attached, at some stage MSP has to allocate add'l memory for the visual representation. Dunno if this is enough to make a difference.

I just loaded a 20 minute AIFF into the buffer~ in waveform~.help. No problem (although it beachballed for a bit). But if you want a dozen different buffer~s, each with 10" of audio, you're using a lot more than the 1.1Gig you were talking about earlier.

You might be able to work around your problem by just loading in, say, 30 or 60 seconds from each file, and shifting file position as required by the user. Could be a bit tricky to patch, though.