sfplay stops early - I am in need of an Urgent fix


    Dec 01 2006 | 9:25 am
    In either loop mode or not, sfplay is unable to make it to the end of a file. The 3 files I am trying to loop are 12min, 16min, and 19min. In loop mode they turn over after about a minute, without reporting a bang in the right outlet. In non-loop it stops at random times, (around 1 min.) and does report a bang as if it reached the file end.
    I have tried workarounds, such as defining the loop points using info from sfinfo~, still has the same problem.
    This happens on all 3 of my machines.
    Max 4.62, jitter 1.6.2.
    I might try re-building this part using jit.qt.movie and a spigot~ combination, but cpu is tight, and I really shouldn't have to do this. However, I need it working by mid-day tomorrow. It is unfortunate as the rest of my patch, which is much more complicated, works fine, but ufortunately I did my testing with much shorter files and never had the problem. (btw the problem even occors using the sfplay~ help file.
    Thanks,
    Christopher Overstreet

    • Dec 01 2006 | 9:45 am
    • Dec 01 2006 | 7:25 pm
      Thanks Patrick for the suggestion.
      I did try different buffer sizes, but never high enough. I haven't tested the files on the final machine, will go there in the hour. But my ibook, suffered the same problem. I set the buffer size to 180000 and that solved it. By the way is this ms or samples? Seems awfully big if it is ms. I am just trying to play the files straight thru at regular speed.
      I think this is a bug in sfplay. If the hard-drive can't keep up there should be some more elegant way of handling this other than the file automatically starting over from the beginning, as well as some sort of error reporting. For example, in multi-track software, one first begins to hear drop-outs, which was always my cue to look into hard-drive issues.
    • Dec 01 2006 | 7:56 pm
      On Dec 1, 2006, at 11:25 AM, Christopher Overstreet wrote:
      > I did try different buffer sizes, but never high enough. I haven't
      > tested the files on the final machine, will go there in the hour.
      > But my ibook, suffered the same problem. I set the buffer size to
      > 180000 and that solved it. By the way is this ms or samples? Seems
      > awfully big if it is ms. I am just trying to play the files
      > straight thru at regular speed.
      It is in bytes (so you need even more than samples). The default is
      currently 120960, which in my experience is enough on all machines
      except in the case of certain drives when they go to sleep, as oft
      discussed on the list. If you copied an old instance of sfplay from
      an old patch, however it retains the *old* default disk buffer size
      (eek, sfplay~.help is one such place where the old disk buffer size
      of 40320 is still used). You can see this if you open the patch as text:
      default with newly typed instance:
      sfplay~.help
      Sorry for this inconvenience.
      -Joshua
    • Dec 02 2006 | 3:17 am
      HI
      once i had a problem with one wav file: at some point the sfplay~ stop playing. but when i put [sfplay~2 16000 2] the outlet next to last output give me the file time and it stil running! so i re-render the wav file and problem solved... bad wav!
      so you can try the same but i think it will not work!
      Rui Caldas
    • Feb 08 2012 | 8:24 pm
      Anyone know if the help info about buffersize in the Max5 / Max6 sfplay docs is up-to date? As mentioned in
      I need to reliably play back / record 48000 / 24bit / 16-channel audio files
      thanks
      oli
    • Feb 10 2012 | 9:23 am
      At least for the playback side, a workaround for a colleague of mine was to split the multichannel file into stereo pairs and use the signal cue trigger feature to start many sfplay~s synchronous (see sfplay.help->More features->signal_inputs).
      Thomas
    • Feb 04 2013 | 12:22 pm
      I've a feeling this problem hasn't gone away. I had a weird experience at a performance two days ago of sfplay~ objects starting a soundfile and stopping after less than a second. Didn't happen all the time, rather, just randomly. I only had this problem on a colleague's machine, which we were using for the performance. On two other machines and at three prior performances this never happened.
      Could it be the max version? I have 6.0.7 and my colleague had 6.0.8.
      My sound files were 4-channel AIFFs, 48k, 24 bit, Big Endian.
      All suggestions gratefully received 'cause this is a bizarre one and is making me a little paranoid about using max in this piece in the future...
      Best, Michael
    • Feb 04 2013 | 2:51 pm
      As far as I know sfplay~ and sfrecord~ are still unreliable when working with large/multichannel files.
      If your computer has enough memory, it might be worth using buffer~ objects rather than sfplay~. If memory is an issue, Alex Harker made some buffer objects which which will load the audio data into memory in it's original format, saving a bit of space.
      oli
    • Feb 04 2013 | 2:58 pm
      also, you could consider using a DAW like reaper to play back the audio and pipe it to max via jack/soundflower/rewire. Reaper is controllable via OSC, so you can jump around the timeline etc
    • Feb 04 2013 | 3:12 pm
      @Michael
      The problem is always there, for me…
      matteo
    • Feb 14 2013 | 5:28 pm
      Thanks Matteo. See also this, which I just wrote: http://cycling74.com/forums/topic.php?id=38567
    • Nov 29 2013 | 3:06 pm
      I was having this exact problem, but seem to have solved it. I was was using sflist~ as well as 5 instances of sfplay~ playing 8-channel files. After some experimentation I ended up using a buffer size of 20160 * 8 * 5 = 806400 in ALL FIVE splay~s AND IN sflist~ (if you don't have the same buffer in sflist~ as splay~ many problems can result)
      Hope that helps
      Andrew