Is there a way to disable the transport stopping when a dropout is detected? I'm using 8.53 and SUperior drummer causes dropouts intermittently under very light loads. Superior 2.20 works fine but versions above that have this problem. 2.3.1 brought some new features that I like using, yet the dropouts are very irritating.
 
I rarely operate under such a load that I'd get a real dropout, so there is no reason to stop the transport as far as I'm concerned. So far I tried changing the AUD.INI dropout msec from the default 250 and changed it to 400 and had one dropout today. So I don't know if it had any effect. I've also changed the playback and record buffer settings, raising them from 256 to 512 with no effect.

You could try raising it to say 1024. Can you set the dropout Marc any higher than 400?

Leadfoot
You could try raising it to say 1024. Can you set the dropout Marc any higher than 400?

When the dropouts happen, I have tried boosting the buffers with no effect, yet I can try 1024 the next time to see if it helps. I'm not sure if changing those settings affects Sonar right away or if it only affects it the next time Sonar is opened
 
I went ahead and boosted the dropout MSEC in AUD.INI to 800. At this point I'd be surprised if any of these changes would help, that's why I was hoping to find a way to disable the stopping of the transport during a dropout.

I don't think there's a disable option, but I could be wrong.

Dropouts are fatal to the audio engine. The transport has no recourse but to stop. There is no indication of whether you are running 32 or 64 bit and how much RAM you have. Superior Drummer just like any of the better drum synths wants to use a lot of RAM. Superior Drummer has several settings to reduce the RAM needed. Ultimately, you might need to freeze as soon as possible to free up the resources used by the synth. Running up the DropoutMSec in Aud.ini to 700-800 is not a bad idea. Not sure about tweaking the record/playback buffers. If 512 did not help, I would take them back to default.

scook
Dropouts are fatal to the audio engine. The transport has no recourse but to stop. There is no indication of whether you are running 32 or 64 bit and how much RAM you have. Superior Drummer just like any of the better drum synths wants to use a lot of RAM. Superior Drummer has several settings to reduce the RAM needed. Ultimately, you might need to freeze as soon as possible to free up the resources used by the synth. Running up the DropoutMSec in Aud.ini to 700-800 is not a bad idea. Not sure about tweaking the record/playback buffers. If 512 did not help, I would take them back to default.

 
I'm running XP SP3 with 4 megs of RAM, 32 bit. I'm using Superior as 16 bit to reduce RAM. It uses about 650 meg. Ivory uses about 700-1000 meg. Many times I get dropouts with 2 audio tracks. Superior playing a 1 bar drum loop and recording an Ivory piano part - very light load. Certainly nothing that would be remotely fatal to the audio engine. I don't get any of this weird dropout behavior using Superior 2.20. Toontrack doesn't have any good suggestions.

Getting dropouts with that light a load may be an indication of excessive DPC time. Get a copy of DPC Latency Checker and see what it has to say. If you still get dropouts after setting DropoutMsec to 800, that means the engine only gives up if dropouts exceed 0.8 seconds. An 800ms dropout isn't your usual click or pop, it's silence for half a measure in duration (!), and indicates something other than normal CPU exhaustion.
 
You could also be running out of address space if Ivory is taking a gigabyte of RAM. You've only got 2GB to work with, and sonarpdr.exe can easily take a gig on its own. Check the Windows Task Manager to see how much memory SONAR's using.
 
BTW, you can reduce SD's RAM usage even further by enabling caching, which loads only the samples that are actually used. The downside is you have to play the song all the way through one time before exporting, to make sure all the samples get loaded. Another technique for reducing SD's memory requirements is to limit the use of bleed samples. I don't like a lot of bleed except to the overheads, so RAM usage for me with SD is usually < 400MB using 16-bit samples (which I use for everything, even final render) and can be < 150MB with caching enabled.
 
I don't use Ivory, but I'm guessing it has some memory-management features as well, as most sample players do. In a pinch, there's always the technique of using a less-demanding synth (e.g. TTS-1) as a placeholder during composition and then substituting the real samples before exporting.

bitflipper

Getting dropouts with that light a load may be an indication of excessive DPC time. Get a copy of DPC Latency Checker and see what it has to say. If you still get dropouts after setting DropoutMsec to 800, that means the engine only gives up if dropouts exceed 0.8 seconds. An 800ms dropout isn't your usual click or pop, it's silence for half a measure in duration (!), and indicates something other than normal CPU exhaustion.

 

You could also be running out of address space if Ivory is taking a gigabyte of RAM. You've only got 2GB to work with, and sonarpdr.exe can easily take a gig on its own. Check the Windows Task Manager to see how much memory SONAR's using.

 

BTW, you can reduce SD's RAM usage even further by enabling caching, which loads only the samples that are actually used. The downside is you have to play the song all the way through one time before exporting, to make sure all the samples get loaded. Another technique for reducing SD's memory requirements is to limit the use of bleed samples. I don't like a lot of bleed except to the overheads, so RAM usage for me with SD is usually < 400MB using 16-bit samples (which I use for everything, even final render) and can be < 150MB with caching enabled.

 

I don't use Ivory, but I'm guessing it has some memory-management features as well, as most sample players do. In a pinch, there's always the technique of using a less-demanding synth (e.g. TTS-1) as a placeholder during composition and then substituting the real samples before exporting.

Today I'm trying 800 MSEC in AUD.INI, yesterday I tried 400 and got 1 dropout, working for 7 hours. I do have DPC latency checker and now have it fired up to see if it shows something when I get a dropout. In a typical song Windows task Manger shows
 Physical memory
total - 3.4
available 1.0
sys cache - 1.2

If I disconnect Ivory in the synth rack then the available mem goes to 1.7. Occasionally I gets chonic dropouts, like every few seconds, to the point where I have to close and reopen Sonar. Usually everything is fine then for a while. When I get chronic dropouts, I've tried a few things like reduce the playback and recording buffers, archiving tracks, reducing Ivory's polyphony, etc.

 If you have any more suggestions to try in these situations that would be great. The only solution in this situation is to clsoe and reopen Sonar.

The key number is not necessarily total available memory, but how much memory sonarpdr.exe is using. If, for example, you load up a project and Task Manager shows that sonarpdr.exe has 1500MB allocated, then you only have 500MB available for loading a sample library regardless of how much memory is available system-wide. It appears Ivory is pretty memory-hungry, taking up 700MB.
 
I have dealt with similar issues here, also running 32-bit SONAR on XP. It never was a big problem until recently, when I installed Orange Tree Samples' Rickenbacker bass library (32 velocity layers!). I had to reduce the number of layers as well as reduce the DSD preload buffer size in Kontakt in order to use the library alongside Superior Drummer. Sounds like Ivory is an even bigger hog. Hopefully, it has some memory-management features of its own.

bitflipper
The key number is not necessarily total available memory, but how much memory sonarpdr.exe is using. If, for example, you load up a project and Task Manager shows that sonarpdr.exe has 1500MB allocated, then you only have 500MB available for loading a sample library regardless of how much memory is available system-wide. It appears Ivory is pretty memory-hungry, taking up 700MB.
 
I have dealt with similar issues here, also running 32-bit SONAR on XP. It never was a big problem until recently, when I installed Orange Tree Samples' Rickenbacker bass library (32 velocity layers!). I had to reduce the number of layers as well as reduce the DSD preload buffer size in Kontakt in order to use the library alongside Superior Drummer. Sounds like Ivory is an even bigger hog. Hopefully, it has some memory-management features of its own.

Have you had the same inconsistent behavior I've had where at times it works just fine then out of the blue you get a dropout under a pretty light load with no real changes to memory? Have you also the occasional chronic dropout that happens every few bars until you close and reopen Sonar? I'm also curious if you used Superior 2.20 and if your performance and dropout issue improved as mine has.