• SONAR
  • X1 crashing on Export Audio
2012/11/04 21:12:08
Calkwalker
I have a project with several audio tracks and several MIDI tracks, plus three soft synths for the latter.  It is similar to a number of my other projects, but this is the first time I've encountered a crash.  
I couldn't get the project to playback in its entirety without SONAR hanging in a "stutter" infinite loop. I had to reboot to stop the looping audio stutter every time.
 
The crashes happened various ways.  I captured the Windows 7 "Problem signature" window, which contained these lines:
  Problem Event Name: APPCRASH
  Application Name: SONARPDR.exe
  Application Version: 18.1.5.535
  Application Timestamp: 4f4d5612
  Fault Module Name: Dimension Pro x64.dll
  Fault Module Version: 1.5.0.5
 
I made the following configuration changes to resolve the issue:
 
Increased Preferences > Audio > Sync and Caching > Record I/O Buffer Size and Playback I/O Buffer Size from 128 to 2048 (incrementally, until the hangs stopped happening on playback). 
 
I also increased Preferences > Audio > Configuration File > ExtraPluginBufs from 0 to 2.
 
The Audio Buffer Size in my Octa-Capture is set to 6 (the default).  I did not change it.
 
I thought that I was out of the woods until I tried to export the full mix to a Wave file.  SONAR didn't just hang, like it did with the initial playback problem, it terminated.  I've repeated this a few times.
 
The problem project mostly differs from my others in that there are more clips per track and more audio edits, including a number of deleted passages that are preceded by fade-outs and followed by fade-ins.  I'm not sure how much processing overhead these multiple clips and fades introduce.
 
I have read that one thing I may have to do is freeze some of the instrument tracks or use "Bounce to Clips" on the audio tracks to consolidate the multiple clips per track.  But which is more critical?
 
Does SONAR have any tools that can identify the playback processing cost per track?  I need some guidance on where most of the processing overhead is coming from.
 
My system:
SONAR X1 Producer Expanded
Windows 7 Home Premium
Intel dual core 860 @ 2.8 GHz
8 GB RAM
RAID 0 hard drives
No antivirus software or other clutter
2012/11/04 21:36:38
swamptooth
you probably shouldn't even be using sync and caching - it just causes disk reads and writes and you have more than enough memory to handle a LARGE project.  really, turn them off. 

from the help file :
"Enable Read Caching and Enable Write Caching. Choosing either of these options lets SONAR use the Windows disk cache while reading or writing audio data. SONAR 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 SONAR’s audio performance."

 increase your audio buffer size a few ms and  in prefs/midi/playback and recording increase prepare buffers to 500ms.
2012/11/05 02:21:29
Calkwalker
swamptooth

you probably shouldn't even be using sync and caching - it just causes disk reads and writes and you have more than enough memory to handle a LARGE project.  really, turn them off. 

increase your audio buffer size a few ms and  in prefs/midi/playback and recording increase prepare buffers to 500ms.
The checkboxes "Enable Read Caching" and "Enable Write Caching" are NOT checked.  Under those checkboxes are two value fields:
 
   Playback I/O Buffer Size (KB)
   Record I/O Buffer Size (KB)
 
These apparently default to 256 KB, but I set mine to 128 KB over a year ago to match my RAID 0 data strip size.  No problem until now.  I progressively increased these to the max value (2048), and that appears to allow the playback to go longer before hanging, but it is still hanging after two minutes of playback with those settings.
 
I tried increasing Preferences > MIDI > Playback and Recording > Prepare Buffers from 250 to 500, as suggested, but this has not had any effect.
 
I've also run 'Bounce to Clips' on all eight audio tracks, which consolidated the project quite a bit, but unfortunately has not resolved the hang issue.
 
Any advice appreciated.  Dead in the water on this project.  What the heck.
 
2012/11/05 02:36:00
scook
Aside from DimPro what other synths are you using? Are you running X1d? Does the project play when you disable effects?
2012/11/05 03:18:18
swamptooth
in the config file options change dropoutmsec to 750. 
2012/11/05 03:22:17
swamptooth
and try rescanning and/or reinstalling dimension pro.
2012/11/05 03:37:25
Calkwalker
scook


Aside from DimPro what other synths are you using? Are you running X1d? Does the project play when you disable effects?

Two instances of Dim Pro 64 x64 and one of Z3TA+2.
 
I'm running X1d (build 535), x64.
 
The playback issues began when I added the second Dim Pro instance, although I have several other projects with two Dim Pro instances.  This project does use a different Dim Pro plugin than the others.  I'm wondering if the different one is the root cause of the playback problems.  It's called Warm Strings Pad 05.
 
Playback is successful if all three synths are muted, and when the first Dim Pro instrument is unmuted.  Playback hangs if the second Dim Pro instrument is unmuted (while keeping the other two muted).  The second one uses Warm Strings Pad 05.
 
Maybe it's bad?
 
2012/11/05 03:45:03
scook
Could be. You could try unmuting the other DimPro instance and freeze it. Then unmute the Warm Strings Pad DimPro see what happens. If there is problem still exists freeze the z3ta. Then try again.
2012/11/05 13:40:43
Calkwalker
I have isolated the hang/crash issue to the Dim Pro x64 plugin called Warm Strings Pad 05.  If I change that one instrument track to another Dim Pro patch (like Warm Strings Pad 01 or Warm Strings Pad 03) all is well.
 
Has anyone encountered a problem with a single Dim Pro plugin like this?  What would be the next logical step?  Rescan all plugins?  Reinstallation of the entire Dim Pro x64 product?
2012/11/05 18:05:20
scook
Report it to Cakewalk. Avoid using the patch. Study the patch in your spare time to see if you can figure out the failure.
12
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account