Christopher Overstreet

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.

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.

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.

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.

sfplay-stops-early-i-am-in-need-of-an-urgent-fix

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.

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.


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 

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:

> 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:

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!

Anyone know if the help info about buffersize in the Max5 / Max6 sfplay docs is up-to date? As mentioned in

https://cycling74.com/forums/sfplay-preload-and-unibody-macbook-pro

I need to reliably play back / record 48000 / 24bit / 16-channel audio files

Anyone know if the help info about buffersize in the Max5 / Max6 sfplay docs is up-to date? As mentioned in 

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).

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...

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.

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.

As far as I know sfplay~ and sfrecord~ are still unreliable when working with large/multichannel files. 

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

@Michael
Maybe related to this one https://cycling74.com/forums/sfplay-preload-and-unibody-macbook-pro ?

Thanks Matteo. See also this, which I just wrote: 

https://cycling74.com/forums/sfplay-doesnt-play

Thanks Matteo.  See also this, which I just wrote: https://cycling74.com/forums/sfplay-doesnt-play


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)

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