buffer~ size maximum

Quote: Emmanuel Jourdan wrote on Tue, 22 May 2007 23:49
----------------------------------------------------
> On 22 mai 07, at 18:08, Mattijs Kneppers wrote:
>
> > When I make a buffer~ with an initial length of 86,400,000 ms (1
> > day), there doesn't seem to be a problem.
>
> Really� it crashes here on my MacBookPro (thanks�).

This doesn't crash on my MacPro 2,66 Quad, Max 4.6.3, OS 10.4.8. It also doesn't change anything to the amount of used memory. What happens to the memory charts in your activity monitor?

>
> > This translates to 86,400 x 44,100 = 3,810,240,000 samples x 16
> > bits = 7,6 GB of memory, right? I'd expect my memory monitor to go
> > off the charts, but that doesn't seem to be the case..
>
> it's worse: 86,400 x 44,100 = 3,810,240,000 samples x 32 bits (it's
> floating point values) = 15,240,960,000 octets. (> 15 GB).

Ah, of course.

So there is a difference in memory management between a MacBookPro and a MacPro?

Mattijs

On 23 mai 07, at 10:19, Mattijs Kneppers wrote:

>

Thanks again for the precision, I tried

And this one crash, on PPC and on Mactel.

Cheers,
ej

Quote: Emmanuel Jourdan wrote on Wed, 23 May 2007 16:41
----------------------------------------------------
> On 23 mai 07, at 10:19, Mattijs Kneppers wrote:
>
> >

Sorry, forgot the name.

>
> Thanks again for the precision, I tried
>
>

Am I going crazy?

Mattijs

Quote: Emmanuel Jourdan wrote on Wed, 23 May 2007 22:45
----------------------------------------------------
> On 23 mai 07, at 17:57, Mattijs Kneppers wrote:
>
> > crashes here, too. But this one doesn't:
> >
> > #P newex 201 262 141 196617 buffer~ allaudio 86400000 2;
>
> So you're going to multiply that again by 2 :-)
>
> > Am I going crazy?
>
> No� It just that it crashes in some cases. Anyway, the main problem
> behind that is that no matter what, this is not gonna work, because
> the buffer's way too long.

Yep. I was particiularly amazed that creating a buffer with a big size doesn't affect the displayed amount of free memory in my activity monitor.

> I would suggest some other strategy
> involving sfrecord~/sfplay~ instead.

In fact the reason why I stumbled upon this was that I was hoping for a way to resize the buffer~ while keeping its contents intact. This doesn't seem to be possible at the moment.

But then it suddenly looked like it was possible to create a buffer~ with a very big size without actually reserving the memory, maybe until you actually write something in it (?). So I figured this might be a solution for my problem..

Mattijs

Just did some more checking and it -is- strange that

does reserve about 600 MB of memory, which is visible in the activity monitor, but

doesn't reserve anything, or at least I don't see anything change in the activity monitor.

Could you confirm that?

Cheers,
Mattijs

Mattijs Kneppers wrote:
> Just did some more checking and it -is- strange that
>
> #P newex 35 50 126 196617 buffer~ allaudio 3600000;
>
> does reserve about 600 MB of memory, which is visible in the activity monitor, but
>
> #P newex 35 50 135 196617 buffer~ allaudio 3600000 2;
>
> doesn't reserve anything, or at least I don't see anything change in the activity monitor.

To me this looks like missing error checking in buffer~s' code: if you
ask malloc() (or any other memory allocation function) to alloc more
memory than possible they usually return NULL. Which means no memory was
allocated at all! I think that's what happening here. So if you start to
write to that memory you will just crash Max sooner or later because you
are overwriting memory that doen't belong to that buffer~.

Olaf

Quote: Emmanuel Jourdan wrote on Thu, 24 May 2007 11:45
----------------------------------------------------
> > #P newex 35 50 135 196617 buffer~ allaudio 3600000 2;
> >
> > doesn't reserve anything, or at least I don't see anything change
> > in the activity monitor.
>
> I get an error message:
> � error: buffer~: allaudio: out of memory
>
> But 3600000 ms at 44100 kHz, it makes a buffer of 1,278 GB.
>

Ah, I get the error too, missed it, sorry.

But it's weird that this generates an error while the other one crashes. Or.. could it be that it crashes when it tries to allocate with a memory address bigger than 2 GB but when the address is still within 2GB there is a possibility that it complains about a lack of memory?

Anyway, what is important is that I know for certain that a buffer larger than 2 GB is not supported and there is no intelligent memory allocation system inside buffer~ that would only use memory when it is first written.

So I'll have to find a way around the fact that buffer~ is not resizeable without losing your content.

Thanks,
Mattijs