Cakewalk stops during record?

[jono grant]

Sometimes Cakewalk just decides to stop during a recording take, not a very long track either.

It doesn't always happen but when it does, it's a always a drag.

What causes this?? I assume AV programs, internet connection? Anything else that could cause an interruption?

I need to trust my DAW can get through a take without stopping. I can't imagine recording a 40 minute podcast or something...

Thanks

Jono

 

 

[msmcleod]

3 hours ago, jono grant said:

Sometimes Cakewalk just decides to stop during a recording take, not a very long track either.

It doesn't always happen but when it does, it's a always a drag.

What causes this?? I assume AV programs, internet connection? Anything else that could cause an interruption?

I need to trust my DAW can get through a take without stopping. I can't imagine recording a 40 minute podcast or something...

Thanks

Jono

 

 

The dropout code should give you some indication as to why this is happening.

One thing I would check though, is what your dropout threshold is:

"Internal" dropouts can actually occur pretty often, especially when there's a lot of FX processing going on and the CPU simply doesn't have enough time to process everything before the next buffer.

Increasing this value will allow more of these to be "ignored" before Cakewalk actually gives up and stops the engine.

The other thing that could affect recording drop outs in particular, is file access. You shouldn't experience issues with an SSD, but if you're using a HDD fragmentation or seek delays can cause recording to drop out.

One way to mitigate this is to increase the amount of hdd space allocated to the audio file before recording:

According to the help file:
"Record Pre-allocate File (seconds). When this option is set to a value greater than zero, Cakewalk will pre allocate the file to be recorded to the size specified (in seconds). This means that the file will not be resized while recording until it reaches the allocated size. The setting has the potential to reduce disk activity while recording and allows for more possible tracks. The valid range is 0–14400 seconds and the default value is 0. A reasonable setting would be 10 minutes (600 seconds) to 30 minutes (1800 seconds)."
 

Finally, you could consider increasing your Record I/O buffer size (in steps of 128):

Again, from the help file:

File System

Enable Read Caching and Enable Write Caching. Choosing either of these options lets Cakewalk use the Windows disk cache while reading or writing audio data. Cakewalk will usually perform best with all caching disabled, which is the default setting. If your computer has an older IDE disk controller, or a disk controller that does not use DMA transfers, enabling caching may improve Cakewalk's audio performance.

Note: Changes to these settings only take effect when you restart Cakewalk .

I/O Buffer Size. This value determines the buffer characteristics for transfers to and from the disk. Changing this value does not affect audio latency, but will affect the disk throughput for audio tracks. The default setting is 128. A higher value causes more audio to be buffered from the disk ahead of the playback cursor. If you are hearing consistent dropouts/clicks in your audio and if your project contains high bit depth (32/64 bit) or high sample rate audio (88.2K or higher), it may be indicative of a too small I/O buffer size. If so, try a higher I/O buffer size like 256 or 512. If audio problems persist, reset to 128 and try a different remedy.

Also, if you are playing a large file, and using maximum latency, a too-small I/O buffer size may cause dropouts or crashes. Try increasing the buffer size by blocks of 128.

 

[jono grant]

Wow! Thanks!

- Interested what you might suggest for a Dropout Msec value?

- Would it be okay to max the "record pr allocate file" value to the 1800 seconds?

- I've never changed the i/o buffer size I don't think in about 15 years...lol I'd be interested to know what to set the two buffer sizes to, on a good computer..

**This is a new computer with pretty good specs, with that in mind, are these tweaks useful on a powerful machine?

I would suspect some sort of system interruption might cause this as well. I know for sure that if I have any anti virus running, it really slows down the loading of a sample or file...

Thanks again

J

 

[msmcleod]

3 hours ago, jono grant said:

Wow! Thanks!

- Interested what you might suggest for a Dropout Msec value?

Somewhere between 300 and 500 ms would be a good value.

3 hours ago, jono grant said:

- Would it be okay to max the "record pr allocate file" value to the 1800 seconds?

You could set it to 1800 seconds, but be aware this will ALWAYS pre-allocate to 1800 seconds. If you've got separate audio file per clips set, you're going to end up with some pretty big audio files.

I don't know off-hand if/when the file is trimmed - I suspect Bounce to Clip(s) will trim it, but I'd need to experiment.... so use with caution!

[jono grant]

7 hours ago, msmcleod said:

Somewhere between 300 and 500 ms would be a good value.

You could set it to 1800 seconds, but be aware this will ALWAYS pre-allocate to 1800 seconds. If you've got separate audio file per clips set, you're going to end up with some pretty big audio files.

I don't know off-hand if/when the file is trimmed - I suspect Bounce to Clip(s) will trim it, but Id need to experiment.... so use with caution!

- Perhaps just use this when needed then?  Band wants to do a take of a 5 minute tune, set it to 300 to 500 but maybe leave it at zero otherwise?

Thanks

[Noel Borthwick]

The most important thing is to note what the dropout code says. The help link in the dropout toast message lists the meaning for all the codes and possible resolution steps.
 

[jono grant]

More times than not, it doesn't have a dropout code,  it just stops the recording..

[Rod L. Short]

BTW, I remember a time when Sonar advertised a "gapless audio engine".  Anybody else remember that?