URGENT : sfplay~ and RAM


    Jun 14 2006 | 1:06 pm
    Hi Cycling,
    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

    • Jun 14 2006 | 3:48 pm
      Precision :
      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...
    • Jun 14 2006 | 4:27 pm
      Hi,
      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
    • Jun 14 2006 | 4:41 pm
      Hi,
      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.
    • Jun 14 2006 | 4:50 pm
      >
      > 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...
    • Jun 14 2006 | 8:02 pm
      Hello Manuel,
      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
    • Jun 14 2006 | 8:16 pm
      Hi,
      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
    • Jun 15 2006 | 7:19 pm
      hi philippe / Manuel
      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
    • Jun 15 2006 | 8:08 pm
    • Jun 15 2006 | 10:52 pm
      while i never had this problem before, yesterday it hit on me in its
      full glory.
      a mildly complicated patch (mostly graphic stuff) for a 5.1.
      installation setup completely started to screw up the machine. (last
      days i hadnt had time to read the list, so i wasnt warned what could
      be going wrong).
      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;
      hans w. koch
      im krahnenhof 11
      d-50668 koeln
      +49-221-554902
      www.hans-w-koch.net
    • Jun 16 2006 | 12:21 pm
      On Jun 15, 2006, at 10:08 PM, Joshua Kit Clayton wrote:
      > 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
    • Jun 16 2006 | 3:20 pm
      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.
      My apologies if this has already been suggested as I haven't been
      following the thread.
      Peas
      Dom
    • Jun 16 2006 | 4:37 pm
      > Hope someone will solve sfplay~'S problemS.
      > maybe at IRCAM....
      a good joke ?-)
    • Jun 16 2006 | 6:34 pm
      On Jun 16, 2006, at 8:20 AM, Dominic Melville wrote:
      > 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
    • Jun 16 2006 | 7:54 pm
      On Jun 16, 2006, at 5:21 AM, Manuel Poletti wrote:
      > 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.
      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
    • Jun 17 2006 | 11:06 am
      > In case it's not obvious, we are committed to providing as robust
      > and reliable audio features as possible.
      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.
    • Jun 17 2006 | 12:54 pm
      hi,
      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
    • Jun 17 2006 | 6:40 pm
      I stopped using sfplay~ in public performance several years ago due to unreliable playback (though it remains an excellent and valuable external for use in the studio). Instead I adopted the obvious solution of loading sounds into buffers for playback with groove~, but in that case of course you're limited by the amount of RAM on your machine.
      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
    • Jun 17 2006 | 6:47 pm
      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
    • Jun 17 2006 | 7:16 pm
      On Jun 17, 2006, at 11:40 AM, Eric Lyon wrote:
      > 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
    • Jun 17 2006 | 10:01 pm
      my tests led me to the same conclusion, since i experienced the very
      same behaviour with pure-data and vlc-player on a machine which
      choked on sfplay.
      the same patches run fine on another computer which has no problems
      with sfplay either.
      (see my post on this thread on june 16th)
      weird it is.
      hans
      hans w. koch
      im krahnenhof 11
      d-50668 koeln
      +49-221-554902
      www.hans-w-koch.net
    • Jun 18 2006 | 7:35 am
      Hi,
      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
    • Jul 24 2006 | 11:32 am
      Did this fix make it into the current 4.6 public Beta?
      Also, do you have a list of the machines know to be problematic?
      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
    • Jul 24 2006 | 5:50 pm
      On Jul 24, 2006, at 4:32 AM, neal wrote:
      > 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
    • Jul 25 2006 | 11:41 am
      Excellent, will start to move over to 4.6. I know this has been a long-running thread, and a frustrating (non-c74) bug for you guys to fix... Thanks for the new version.
      Neal
      >
      > > Did this fix make it into the current 4.6 public Beta?
      >
      > Yes.
      >
    • Jul 25 2006 | 2:16 pm
      On 6/17/06, Manuel Poletti wrote:
      > 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.
      I don't see why this is a problem. I don't use MacOS X much these
      days, but on most modern *nix machines, this is normal behaviour. This
      is just buffer cache and will be given up to an application the moment
      it needs it.
      Basically, what's happening is that the OS is being smart and storing
      data into RAM since there's no real value in wiping it. If you ever
      need that data again, it will already be in RAM, if you don't and need
      the RAM, it is given up to the OS/Application. Unless the OS does
      something dumb and starts swapping heavily (which doesn't seem to be
      the case here), this is not a problem at all.
      Cheers,
      Chris
    • Jul 25 2006 | 2:33 pm
      Hi,
      Christopher Murtagh said:
      > Unless the OS does
      > something dumb and starts swapping heavily (which doesn't seem to be
      > the case here), this is not a problem at all.
      Yes, but this is the case, the OS DOES start swapping and audio dropouts occour.
      Otherways why do you think that we did pose the problem ?
      This is not something happening in OS theory this happens on our machines.
      One year ago I had to rewrite one piece of mine cause this problem
      (otherways I had to buy 2 Gb of Ram but I am not Ircam, you know :-)
      ) ...
      Let's hope it is solved now...
      Peace , all the best
      Alessandro Fogar
    • Jul 25 2006 | 3:00 pm
      On 7/25/06, Alessandro Fogar wrote:
      > Hi,
      >
      > Christopher Murtagh said:
      >
      > > Unless the OS does
      > > something dumb and starts swapping heavily (which doesn't seem to be
      > > the case here), this is not a problem at all.
      >
      > Yes, but this is the case, the OS DOES start swapping and audio dropouts occour.
      >
      > Otherways why do you think that we did pose the problem ?
      Oh, sorry. I didn't see this in the thread, but re-reading it now I
      can see it. If this is the OS doing something dumb, this could be
      pretty hard for the cycling74 guys to fix. Ahh, the joys of the
      spinning lollipop - this is why I use Linux most of the time. :-)
      If however, the sfplay~ object is *always* loading entire samples
      into RAM regardless of their size (instead of buffering and loading as
      needed - a much more complex but obviously necessary task for large
      samples), it should be considered a limitation of the object. Using it
      to play 1GB audio files would be the equivalent of transporting
      elephants with a VW Bug. Perhaps it was just designed to handle short
      audio samples by the original author and therefore it's a useage
      and/or documentation problem? In either case a more appropriate object
      would be needed, maybe one that's always loaded (for small samples)
      and one that's buffered (for large files) would be the best approach?
      Cheers,
      Chris
    • Jul 25 2006 | 3:08 pm
      On 25 Jul 2006, at 17:00, Christopher Murtagh wrote:
      > If however, the sfplay~ object is *always* loading entire samples
      > into RAM regardless of their size (instead of buffering and loading as
      > needed - a much more complex but obviously necessary task for large
      > samples), it should be considered a limitation of the object.
      sfplay~ doesn't do this. It preloads and buffers some audio, and
      operates by streaming.
      -- N.
      nick rothwell -- composition, systems, performance -- http://
      www.cassiel.com
    • Jul 25 2006 | 6:03 pm
      On 25-Jul-2006, at 17:00, Christopher Murtagh wrote:
      > would be the equivalent of transporting
      > elephants with a VW Bug
      Oh, no! Not a revival of the "how many elephants can you get into a
      VW Beetle" jokes. I hoped I heard the last one of those in 1967.
      -- P.
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      Universal Binaries on the way
      iCE: Sequencing, Recording &
      Interface Building for |home | chez nous|
      Max/MSP Extremely cool |bei uns | i nostri|
    • Jul 26 2006 | 10:40 am
      Wasn't that the Ultimate Question?
      ;-)
      Trond
      > Oh, no! Not a revival of the "how many elephants can you get into a VW
      > Beetle" jokes. I hoped I heard the last one of those in 1967.