I’m experimenting strange RAM behaviour while using sfplay~ in
multichannel mode :

whatever the number of channels is – 4, 8, 6, 12 or 16 – , when I
preload several soundfiles into sfplay cues, and start playing each
cue sequentially, the RAM used by MSP is continuously increasing,
once the preloaded part of the sound has been read (cf “top” in
Terminal app).
As I loop the sequence of cues, the free RAM gets soon totally
fullfilled, then, soon or later, Max simply quits – no crash log or so.
It looks like sfplay~ continuously “preloads” the part of sound it
has to play, without ever clearing the already-read part from the RAM.
Of course, I’ve tried, changing buffer size, using sflist~, splitting
soundfiles in smaller formats, installing a new system, on several
machines, downgrading Max to earlier versions, etc : same behaviour.

Thank you for a quick help from Cycling developers, we’re several
here to experiment LOTS of problems with sfplay~ in general, and THIS
OBJECT IS TOO IMPORTANT for live performances (some are thinking
using readsf~ from PD, via flext – cool).
I have now a new sound installation wich cannot run safely, due to that.
We must know if we can finally trust or not a simple multichannel
soundfile player in Max – or should we use f%$#@#@ sequencer ?

Thanks,

- and sorry, no time to google the site…

_M

same behavior with :
- G5 bipro 2GHz (several), G4 Powerbook 17″
- OS 10.4.5, OS 10.4.6
- Max 4.5.4, 4.5.5, 4.5.6, 4.5.7
- sfplay~ 1, 2, 4, 6, 8, 12, 16, using either [preload cueID] or
[open, 1] messages – different buffer sizes
- use sflist~ to preload the files, then access them with named sfplay~
- internal HD, external HD, boot from external HD (brand new OS 10.4.6)
…

It looks that Max never frees the RAM sfplay~ uses, rather it is sent
to “inactive memory”, according to terminal.
So, in fact, it is like sfplay loads slowly the entire soundfiles
into RAM.
As soon as the entire RAM is handled by Max, if I try something using
another trhead (a network access, for instance), the audio starts
clicking, I get random delays between the different tracks from the
soundfile, etc., then crash.

Please help – I can’t buy 5 Gb of RAM to solve the problem…

please can you post a patch showing this behaviour ?

I too have experienced this same behaviour but only in certain patches
(for example inside lloopp).

I have not been able to show to Joshua an evidence of the problem

All the best

Alessandro Fogar

just open sfplay~.help, load a long soundfile, play it and watch the
RAM percentage in Terminal.
Takes time if the sfplay~ is mono until the free RAM is empty (the
more channels the fastest).
Take several soundfiles to make a full test, since it seems that Max
keeps track of preloaded files until you instanciate the object
again, or quit Max.

Sorry, quitting is not enough – you must RESTART the machine so that
Max loses track of the old preloaded file.
C’mon…

I made several tests here with LightRegie120x and its sound files
reader.
You are absolutely right, available ram decreases during playback. The
mac must be restarted to recover RAM.
I noticed this does not happend when you repeat a file, it’s just with
“new” ones.
I finally – at that time- used the sflist~ option since I was never
lucky with sfplay~ by itself: too many inpredictable crashes.
I could simply not imagine a soundtrack abruptly stop during a theater
performance… At this time, it works but in theater conditions, since
soundtrack is not the most important thing, thanks to actors ;-)
I use a G4 PWB 1.25 gHz / 1.25 Go ram/ Mac OSX 10.3.9 & a 1 Go USB2 key
for files. The current version of LR120x use the last available version
of MaxMSP.
I finally made some tests with a jit.qt.movie object wich can play aif
files: the phenomenon does not happen. Maybe a short term alternative
for you?
Best,
Philippe

we already talked about this here:

http://www.cycling74.com/forums/index.php?t=tree&th=1133 9
and here

http://www.cycling74.com/forums/index.php?t=tree&th=1510 9
All the best

Alessandro Fogar

I made several tests too and have the same sfplay~ behaviour.
I use a G4 PWB 1.25 gHz / 1.25 Go ram/ Mac OSX 10.4.6 /Max 4.5.7.
Same bug whith build app.

using jit.qt.movie is not a “MSP” alternative.
using a seq. like Live, with a Max patch is a good idea to become crazy!

So, I need a simple way to play SFiles. is it so hard to do ?

Hope someone will solve sfplay~’S problemS.
maybe at IRCAM….

best,
Francois

the things is: playing a 6 channel-.aif-file starts shifting the ram
to “inactive” (as seen in terminal “top”), which is never freed.
after playing a couple of those files, of course, paging starts and
then things go really bad. increasing diskbuffersize was no help.

what drove me nuts is, that it only occurs on the installation-
machine (a minmac 1.42 ghz, 10.4.6, 512mb ram, max/msp/jitter
runtime/ demo-mode 4.5.7).
with the same patch on my pb (1.5 ghz, 1.5 g ram, 10.4.6 max/msp/
jitter) this behaviour doesnt occur.
strange.
even stranger: out of curiosity i made a simple pd-patch for playing
the same multichannel-files. same problem on the minimac, no problem
on the pb.
so it seems to be some bad system voodo rather than max alone.

my clumsy workaround: with the shell object i keep an eye on the free
ram. whenever it goes below a certain threshold, audio is stopped and
a buffer of approximately the size of the inactive memory is scripted
and then immediately destroyed. this frees the ram again (of course,
paging also happens, but it isnt that bad as before. tests still
running).

but still: what is it, that simply playing back audio-files can be
such a hassle???

puzzled
hans

p.s.: the patch to reproduce (or not) is so simple, taht i barely
dont dare to attach, but anyway:

max v2;
#N vpatcher 14 59 614 459;
#P toggle 84 78 15 0;
#P toggle 46 146 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 81 183 101 196617 dac~ 1 2 3 4 5 6;
#P message 68 114 30 196617 open;
#N sfplay~ 6 161280 0 ;
#P newobj 81 142 119 196617 sfplay~ 6 161280;
#P connect 4 0 0 0;
#P connect 1 0 0 0;
#P connect 3 0 2 0;
#P connect 0 0 2 0;
#P connect 0 1 2 1;
#P connect 0 2 2 2;
#P connect 0 3 2 3;
#P connect 0 4 2 4;
#P connect 0 5 2 5;
#P pop;

hans w. koch
im krahnenhof 11
d-50668 koeln
+49-221-554902
http://www.hans-w-koch.net

> We will of course look into (don’t expect an *urgent* fix by some
> deadline imposed by your projects, however, as we have many
> priorities and this is surely not our topmost).

Sorry ?
My project is certainly not a priority, but I would like to know if I
can trust soundfiles to be played on a computer with Max or not.
For the time being, it seems that I could save the installation by
adding 4 Gb of RAM (soundfiles take 3.5 Gb).
Fortunately, I didn’t have to pull out the money from my own pocket –
fortunately too, I could take enough time to track the problem (be
sure that I wouldn’t ring the support before at least 3 full days of
hard debugging), as I’m still a (temporar) employee.
As mentionned by another user, discussions around this topic started
in 2004.
if playing sounds with Max safely is not your topmost priority, I’m
very curious to know in wich position in the list comes the present
and future of doing audio with Max.

> Also note that cues remain resident in RAM. If you just generate
> more and more cues, they each will require the preload amount in
> RAM (for the *lifetime* of the cue). Replacing an existing cue
> number will free it and load a new one in place. However if you are
> just increasing cue numbers. RAM *will* grow without bound.

I only generate 12 cues in 2 sfplay~ object (so, 24 cues) using the
[preload cue-number filename] message.
Sfplay~ have an argument of 12 tracks, and the 60480 recommended
value (.help) for the buffer size argument.
Soundfiles have a length around 2mn each, each output is connected to
a dac-number.
Then I play those 24 cues one after the other, using an int
corresponding to the cue-number.
The total length of the loop is about 48 mn, wich is repeated from 11
a.m to 22 p.m.
That’s all what I’m doing there.

> As for cue list looping leading to VRAM issues (including in a
> multi-channel setting), I’ve attached the following patch which
> does n cause RAM to grow without bound on my machine 10.4.7. Does
> this patch grow without bound for you, Manuel?

As far as I can see, no.
Have a look on the patch issued from mine (maybe generate a 12 tracks
soundfile – I’ve put a small recorder inside – and replace the
filenames with yours).
This one does.

Thank you,

_Manuel

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 472 134 34 196617 pink~;
#P toggle 379 163 15 0;
#P message 396 163 30 196617 open;
#P newex 421 215 157 196617 sfrecord~ 12;
#P newex 472 159 41 196617 *~ 0.1;
#P user ezdac~ 362 304 406 337 0;
#P toggle 258 97 15 0;
#P newex 258 116 29 196617 gate;
#P message 86 38 109 196617 2 3 4 5 6 7 8 9 10 11;
#P window linecount 3;
#P message 288 35 407 196617 preload 2 01-LoupVoyeur-A , preload 3
03-Rencontre-A , preload 4 06-InBed-A , preload 5 09-Fugana-A ,
preload 6 11-Souffle-A , preload 7 01-LoupVoyeur-B , preload 8 03-
Rencontre-B , preload 9 06-InBed-B , preload 10 09-Fugana-B ,
preload 11 11-Souffle-B;
#P window linecount 1;
#P newex 86 329 170 196617 dac~ 1 2 3 4 5 6 7 8 9 10 11 12;
#P user meter~ 240 303 320 316 50 0 168 0 103 103 103 255 153 0 255 0
0 217 217 0 153 186 0 12 3 3 3 3;
#P user meter~ 226 285 306 298 50 0 168 0 103 103 103 255 153 0 255 0
0 217 217 0 153 186 0 12 3 3 3 3;
#P user meter~ 212 267 292 280 50 0 168 0 103 103 103 255 153 0 255 0
0 217 217 0 153 186 0 12 3 3 3 3;
#P user meter~ 198 249 278 262 50 0 168 0 103 103 103 255 153 0 255 0
0 217 217 0 153 186 0 12 3 3 3 3;
#P user meter~ 184 231 264 244 50 0 168 0 103 103 103 255 153 0 255 0
0 217 217 0 153 186 0 12 3 3 3 3;
#P user meter~ 170 213 250 226 50 0 168 0 103 103 103 255 153 0 255 0
0 217 217 0 153 186 0 12 3 3 3 3;
#P user meter~ 156 195 236 208 50 0 168 0 103 103 103 255 153 0 255 0
0 217 217 0 153 186 0 12 3 3 3 3;
#P user meter~ 142 177 222 190 50 0 168 0 103 103 103 255 153 0 255 0
0 217 217 0 153 186 0 12 3 3 3 3;
#P user meter~ 128 159 208 172 50 0 168 0 103 103 103 255 153 0 255 0
0 217 217 0 153 186 0 12 3 3 3 3;
#P user meter~ 114 141 194 154 50 0 168 0 103 103 103 255 153 0 255 0
0 217 217 0 153 186 0 12 3 3 3 3;
#P user meter~ 100 123 180 136 50 0 168 0 103 103 103 255 153 0 255 0
0 217 217 0 153 186 0 12 3 3 3 3;
#P user meter~ 86 105 166 118 50 0 168 0 103 103 103 255 153 0 255 0
0 217 217 0 153 186 0 12 3 3 3 3;
#N sfplay~ 12 120960 0 ;
#P newobj 86 75 179 196617 sfplay~ 12;
#P connect 16 0 15 0;
#P connect 14 0 0 0;
#P connect 15 0 0 0;
#P connect 0 0 1 0;
#P connect 0 0 13 0;
#P connect 0 1 2 0;
#P connect 0 1 13 1;
#P connect 0 2 3 0;
#P connect 0 2 13 2;
#P connect 0 3 4 0;
#P connect 0 3 13 3;
#P connect 0 4 5 0;
#P connect 0 4 13 4;
#P connect 0 5 6 0;
#P connect 0 5 13 5;
#P connect 0 6 7 0;
#P connect 0 6 13 6;
#P connect 0 7 8 0;
#P connect 0 7 13 7;
#P connect 0 8 9 0;
#P connect 0 8 13 8;
#P connect 0 9 10 0;
#P connect 0 9 13 9;
#P connect 0 10 11 0;
#P connect 0 10 13 10;
#P connect 0 11 12 0;
#P connect 0 11 13 11;
#P connect 17 0 16 0;
#P connect 0 12 16 1;
#P connect 19 0 20 0;
#P connect 22 0 20 0;
#P connect 21 0 20 0;
#P connect 19 0 20 1;
#P connect 19 0 20 2;
#P connect 19 0 20 3;
#P connect 23 0 19 0;
#P connect 19 0 20 4;
#P connect 19 0 20 5;
#P connect 19 0 20 6;
#P connect 19 0 20 7;
#P connect 19 0 20 8;
#P connect 19 0 20 9;
#P connect 19 0 20 10;
#P connect 19 0 20 11;
#P window clipboard copycount 24;

My apologies if this has already been suggested as I haven’t been
following the thread.

Peas

Dom

a good joke ?-)

> If I recall correctly it was I who instigated a lot the discussion
> regarding the problems with sfplay~. Mainly it not playing without
> a second trigger. I found the main cause to be drive speed. It was
> running on a powerbook at the time, moving all the audio onto a
> fast firewire drive cured it for me, but I did end up using Live
> for all critical audio just for safetys sake.

This is a different issue. That problem you are referring to is that
you need to disable HD sleep, or make sure the preload buffer is
large enough to wait for HD wake-up.

-Joshua

In case it’s not obvious, we are committed to providing as robust and
reliable audio features as possible. Unfortunately, as far as we can
verify, Max is working properly in this regard. So it is for marginal
cases (which we are unable to verify) which this is an issue. I
appreciate your frustration, but while soundfile playback from disk
might seem to be a simple and fundamental operation to you, it is
actually quite complex, especially with sample accurate cue
triggering and looping, variable speed playback, management of
arbitrary channel/bitdepth/ sample rate sound files in the same
circular buffer fed from disk, not to mention taking into account
everything that happens under the hood in the OS with respect to
memory management, disk access, and file I/O (which, as far as I can
tell, sounds like where these sorts of reports are having a problem).

Thank you for the clear example. These are always recommended for any
reports.

After initial preload of 11 cues of 12 channel pink noise files
(10-15 seconds each):
17846 MaxMSP 19.2% 2:12.15 22 651 694 32.6M 35.5M
51.0M 830M

After playback for several repetitions we have no signs of any
increase in RAM usage:
17846 MaxMSP 20.0% 16:43.68 22 652 694 32.7M 35.6M
50.9M 830M

I also don’t see the inactive RAM steadily growing as Hans Koch
reported on the MacMini using either MaxMSP or PD. It just fluctuates
within a 16MB range.

I’ll leave in the background playing longer, but this leads me to
think that it is an OS issue as had been discussed in the previous
thread, and as suggested by Hans Koch’s post on the subject. I’ll try
to do a bit more research on how this might be the case, but, until
we can establish the problem, we can’t fix it. Even if we do
establish the problem, it sounds like it might be in the OS and out
of our control. Hans’ fix for the inactive memory is also a curious
one, seemingly related to the memory manager’s inner workings rather
than anything in MaxMSP’s code.

-Joshua

It is – I’ve experimented too many local cases where this kind of
sentence had to be understood as a legend, to not appreciate the
responsiveness here.
That’s why I now use external pattented software (since 1997…).
But it’s hard for me to hear that audio playback is not a prior
feature to be fixed in a software that is intended to produce audio.
Numerous twisted real time/interactive/stochastic… anyway bloody
projects could be saved in the last minute using the old good “tape”.
That’s what I hoped I could do using sfplay~.

> Unfortunately, as far as we can verify, Max is working properly in
> this regard. So it is for marginal cases (which we are unable to
> verify) which this is an issue. I appreciate your frustration, but
> while soundfile playback from disk might seem to be a simple and
> fundamental operation to you, it is actually quite complex,
> especially with sample accurate cue triggering and looping,
> variable speed playback, management of arbitrary channel/bitdepth/
> sample rate sound files in the same circular buffer fed from disk,
> not to mention taking into account everything that happens under
> the hood in the OS with respect to memory management, disk access,
> and file I/O (which, as far as I can tell, sounds like where these
> sorts of reports are having a problem).

I fully understand that what seems obvious as a software feature
since Sound Accelerator & co appeared is hard to maintain over so
many versions of systems – especially when it has hundreds of
neighbours sitting in the same directory.
But, since 1997, it is no more a marginal idea for the happy Maxers
like me to intend to simply play looped multichannel files from a
patcher during a “serious” production.
So, excuse my surprise : if Digidesign couldn’t handle soundfile
playback safely, they would be dead today.
It makes me remember “Jamais”-Max – wich disappeard ages ago – there
never were reliable soundfile playback…

> Thank you for the clear example. These are always recommended for
> any reports.
>
> After initial preload of 11 cues of 12 channel pink noise files
> (10-15 seconds each):
> 17846 MaxMSP 19.2% 2:12.15 22 651 694 32.6M 35.5M
> 51.0M 830M
>
> After playback for several repetitions we have no signs of any
> increase in RAM usage:
> 17846 MaxMSP 20.0% 16:43.68 22 652 694 32.7M 35.6M
> 50.9M 830M

Yes – Max seems to remain stable.
On my powerbook (so, another machine), when I load the test patch
(with soundfiles preloaded), top says :

Processes: 52 total, 2 running, 50 sleeping… 213
threads 12:36:05
Load Avg: 1.24, 0.65, 0.33 CPU usage: 23.7% user, 17.8% sys,
58.5% idle
SharedLibs: num = 177, resident = 41.9M code, 4.78M data, 8.99M
LinkEdit
MemRegions: num = 5172, resident = 133M + 10.3M private, 121M shared
PhysMem: 92.7M wired, 135M active, 238M inactive, 466M used,
557M free
VM: 5.02G + 109M 27643(0) pageins, 0(0) pageouts

283 MaxMSP 4.5 14.4% 1:12.18 26 804 605 38.3M 28.4M 51.8M
682M

After 10 minutes of playback, top displays :

Processes: 52 total, 3 running, 49 sleeping… 212
threads 12:45:40
Load Avg: 0.96, 1.04, 0.73 CPU usage: 33.3% user, 22.0% sys,
44.7% idle
SharedLibs: num = 177, resident = 38.0M code, 4.38M data, 6.15M
LinkEdit
MemRegions: num = 5143, resident = 133M + 10.3M private, 116M shared
PhysMem: 92.9M wired, 182M active, 735M inactive, 1011M used,
12.8M free
VM: 4.93G + 109M 27656(0) pageins, 58(6) pageouts

283 MaxMSP 4.5 22.4% 3:42.96 26 804 605 39.2M 26.7M
52.7M 682M

So, Max is OK, but the free RAM is put into inactive, and not “given
back” unless you restart the machine.
Then the proportions of RAM remain more or less like that.
If I run the files during hours, Max will crash soon or later.
Now, we’ve added 4 Gb of RAM – + the original 1.5 Gb, wich is enough
to fit the 3.5 Gb of soundfiles in RAM – free RAM (1.5 Gb) is
stabilized once the whole files are read entireley, and Max doesn’t
crash anymore.

just joining in to confirm that there is more people out there having
the same problem – sfplay eating all the ram….

On 15.06.2006, at 22:08, Joshua Kit Clayton wrote:

> Replacing an existing cue number will free it and load a new one in
> place.

exactly this is not happening on my system (I have to reboot the
computer to get the ram back):

titanium 1 GHz, 10.3.8, max/msp 4.5.7

…..would be really great if there would be a fix sometimes……

best
noid

arnold haberl: noid@klingt.org
dornerplatz 13/32, a-1170 wien
+43-699-11 88 59 39

http://noid.klingt.org/

Joshua’s point is well-taken that unless the problem can be localized and made repeatable it is not easily solved. OTOH, on the same machine where I have had sfplay~ choke on a single stereo file (TiBook 1GHz, 512 MB RAM), I have never experienced a similar event from iTunes, or for that matter from Logic or Digital Performer. Or SoundHack. That suggests that, in theory, the problem could be solved. I’m not surprised that Pd gives similar performance, but it might still be worth checking if the SuperCollider or Csound disk file players prove more reliable.

In any case, even though this is reportedly a marginal problem (though of course it’s not marginal if it happens on *your* machine, especially in front of an audience), it would be nice if a universally reliable solution were found, because soundfile playback is a core functionality. Maybe even worth redesigning sfplay~ from scratch.

Best,
Eric

-Joshua

> Joshua’s point is well-taken that unless the problem can be
> localized and made repeatable it is not easily solved. OTOH, on the
> same machine where I have had sfplay~ choke on a single stereo file
> (TiBook 1GHz, 512 MB RAM), I have never experienced a similar event
> from iTunes, or for that matter from Logic or Digital Performer.

Hi Eric,

The above sounds like the well known HD sleep problem often discussed
on the list (and solutions posted for). And yes, Logic, and other
applications which require a similar sort of real time delivery from
the HD in time to synchronize with the RAM preloaded to play the
region will stop playback in such an instance that the HD cannot wake
up and deliver audio in time. This happens to me all the time in
Logic when the HD goes to sleep…all playback stops and I get a
dialog about not being able to synchronize audio. You might not
notice this if you just launch the program and hit play, since in
such a setting, the disk is almost always active, but if you pause
with enough time for the disk to sleep, I believe you should be able
to reproduce(unless your disk buffers in Logic are large enough to
compensate for this behavior…same is true for sfplay~). Note that
this is not the case with Sound Hack or iTunes, since in those
applications it is permissible to simply start playback once the disk
becomes active.

One solution to this problem is to not let the HD go to sleep. It has
been discussed that while MaxMSP is running, it should not let the HD
go to sleep, which we could do. However, I’m not sure that this is a
universally acceptable solution since people use MaxMSP for a variety
of different needs and so this should be configurable (but if
configurable, you can already do so in the energy saver control
panel, or use a large enough diskbuffer size to accommodate the
slowest of HD wakeups).

-Joshua

weird it is.
hans

hans w. koch
im krahnenhof 11
d-50668 koeln
+49-221-554902
http://www.hans-w-koch.net

consider that on my machine the sfplay~ inside a lloopp patch eats ram.

Instead, an sfplay~ inside the sfplay~.help or the patch submitted
some time ago by Noid does not eat Ram.

If you want I can provide patch examples.

All the best

Alessandro Fogar

Many thanks,
Neal

Btw, I think we will be able to have this problem solved in the next
version of MaxMSP. It appears to be strange behavior in the File
Manager’s caching implementation which is an issue only on some
machines (none of which I own). There are ways to avoid the File
Manager’s cache implementation which we will use in the next version.
Thanks for your persistence in bringing this problem to our attention.

-Joshua

> Did this fix make it into the current 4.6 public Beta?

Yes.

> Also, do you have a list of the machines know to be problematic?

It is not specifically a HW problem, but rather a software behavior
(Finder’s File caching strategy) which we have no data that would
explain why it provides different behavior at different times. Seems
like it might be a bug or idiosyncrasy in Apple’s algorithm for
determining how much and how long to cache file information. As
previously mentioned I’ve never been able to reproduce these problems
(meaning whatever voodoo that needs to be in place on my machine for
Apple’s file caching to work the way I’d expect it to).

-Joshua

Neal

>
> > Did this fix make it into the current 4.6 public Beta?
>
> Yes.
>