atom(x)

I'm running under 10.5.2, and seem to be having problems with the sfrecord~ object. In the patch I'm working on, sfrecord~ is used to capture a buffered audio stream to disc at different intervals over long periods of time. The system works great for an hour or so, capturing a hundred or more samples. But, it will eventually go into spin-lock, and will require a force quit and relaunch in order to continue. This also happens if I run the patch using the Max runtime instead of in the IDE.

I find it interesting that when I do a process sample using the Sampler utility in the Developer tools, it shows the sfrecord~ process taking up 100% of the cpu time. I've attached a screenshot that illustrates this.

Has anyone else encountered problems like this with sfrecord~? I've down quite a bit of debugging, and don't think it's something in my patch, though that possibility always exists. I can post a barebones example if it will help get to the root of the problem.

Oh, and I have also tested the patch under 10.4.11, and the same thing occurs...

I'm running under 10.5.2, and seem to be having problems with the sfrecord~ object.  In the patch I'm working on, sfrecord~ is used to capture a buffered audio stream to disc at different intervals over long periods of time.  The system works great for an hour or so, capturing a hundred or more samples. But, it will eventually go into spin-lock, and will require a force quit and relaunch in order to continue. This also happens if I run the patch using the Max runtime instead of in the IDE.

problems-in-sfrecord

Here is a scaled-down version of the patch that crashes. It's a very simple patch, which makes me wonder if it is a bug in the sfrecord~ object causing this behavior.

Basically, the system monitors the level of incoming audio, and triggers a sample recording when the level exceeds the value set for Trigger Level. The recording will continue until the incoming audio level dips below the tTrigger Level for the period specified by Gate Time.

The patch seems to work fine when you first run it. However, if you let it run a while, it will eventually lock up.

Can anyone tell me why this patch causes a spinning-cursor lock after running a period of time?

- - - - - - - - - (snip) - - - - - - - - - - -

Here is a scaled-down version of the patch that crashes.  It's a very simple patch, which makes me wonder if it is a bug in the sfrecord~ object causing this behavior.

Basically, the system monitors the level of incoming audio, and triggers a sample recording when the level exceeds the value set for Trigger Level.  The recording will continue until the incoming audio level dips below the tTrigger Level for the period specified by Gate Time.

The patch seems to work fine when you first run it.  However, if you let it run a while, it will eventually lock up.

- - - - - - - - - (snip) - - - - - - - - - - - 

On 21 mars 08, at 02:44, Adam Watson wrote:

> Here is a scaled-down version of the patch that crashes. It's a 

> very simple patch, which makes me wonder if it is a bug in the 

> sfrecord~ object causing this behavior.

> Basically, the system monitors the level of incoming audio, and 

> triggers a sample recording when the level exceeds the value set for 

> Trigger Level. The recording will continue until the incoming audio 

> level dips below the tTrigger Level for the period specified by Gate 

I would use [deferlow] rather than [defer].

Maybe your sound level changes to fast around the threshold value, 

causing Max to create to many new files to fast? You may need to 

Centre de Recherches et de Formation Musicales de Wallonie asbl

On 21 mars 08, at 02:44, Adam Watson wrote:
>
> Here is a scaled-down version of the patch that crashes.  It's a  
> very simple patch, which makes me wonder if it is a bug in the  
> sfrecord~ object causing this behavior.
>
> Basically, the system monitors the level of incoming audio, and  
> triggers a sample recording when the level exceeds the value set for  
> Trigger Level.  The recording will continue until the incoming audio  
> level dips below the tTrigger Level for the period specified by Gate  
> Time.

Maybe your sound level changes to fast around the threshold value,  
causing Max to create to many new files to fast? You may need to  
smooth the output of the meters.

_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl
http://www.crfmw.be/max


Quote: Patrick Delges wrote on Fri, 21 March 2008 04:29

----------------------------------------------------

> I would use [deferlow] rather than [defer].

> Maybe your sound level changes to fast around the threshold value, 

> causing Max to create to many new files to fast? You may need to 

Thanks for the response. I altered the patch to take your suggestions into account, to no avail. I also added in a hardcoded delay of 500ms after the closure of the current file, to make sure that the object wasn't being "overloaded" with open/close requests.

The hang always seems to occur on file close, but the fact that the system can run for 30 minutes or more without a hang makes this very confusing. i can't nail down any other commonalities.

I think this may be a bug in sfrecord when used in conjunction with many different files. I'm going to set up a patch that simply creates a bunch of recordings over time, ignoring input and levels, and see if the same hang occurs.

Quote: Patrick Delges wrote on Fri, 21 March 2008 04:29
----------------------------------------------------

> I would use [deferlow] rather than [defer].
>
> Maybe your sound level changes to fast around the threshold value,  
> causing Max to create to many new files to fast? You may need to  
> smooth the output of the meters.
>

Thanks for the response. I altered the patch to take your suggestions into account, to no avail.  I also added in a hardcoded delay of 500ms after the closure of the current file, to make sure that the object wasn't being "overloaded" with open/close requests.

Here is one more wrinkle: I turned off Overdrive and eventually it hung up, as usual. But now I also got this output message in the Max window:

Here is one more wrinkle:  I turned off Overdrive and eventually it hung up, as usual. But now I also got this output message in the Max window:

I'm running into the same problem at the moment on Max 4.6.3, Mac OS 10.5.6.

In my case the hang occurs once in approximately 20 to 40 times when a 1 is sent to sfrecord~, sfrecord~ hangs on doInt().

I'm curious whether you found any new leads in the mean time?

I'll continue to isolate the problem in a small patch and test on more recent versions of Max.

What's the size of the file when you turn off the recording? Max cannot create file bigger than 2 GB something.

Emmanuel Jourdan wrote on Sun, 28 June 2009 00:12

The recordings are small, around a few seconds.

Btw, for me the hang happens when recording is turned ON, not off.

I have the feeling this problem has something to do with starting the recording immediately after opening the file. I rewrote my patch so that there are a few seconds between the open command and the record start. That way, the hangs happens much less frequently.

On the other hand, I can't make the hang happen with a small patch that simply makes a huge amount of recordings in a short time, it only happens in an uber-patch I'm working on. Maybe the hang only happens when other disc activity is going on, or when the system is performing heavily and the queue is getting longer, I have no clue yet.

Emmanuel Jourdan wrote on Sun, 28 June 2009 00:12What's the size of the file when you turn off the recording? Max cannot create file bigger than 2 GB something.

The recordings are small, around a few seconds. 

* i know this shouldn't be necessary but try using 2 (or more) sfrecords alternatively which ideally would even write to different disks (or at least partitions)

* i would do the triggerlevel-tracking differently especially calming down the results of your []. something like:

I have occasionally hanging sfrecord~ when turning off. Max hangs completely by the way. Its maybe 1 out of 40 when it hangs. I have to repaitr the header after force quiting Max. This problem exists for a long time (pre Max 5). Its more likely if I stop recording several sfrecords at the same time (seems logical...)

Btw, never had files bigger than 2 GB when it happened, could happen after a short recording time...

Mattijs wrote on Sun, 28 June 2009 12:27Btw, for me the hang happens when recording is turned ON, not off.

Problems in sfrecord~ ?