I am doing some work re arranging the AUD.ini in alphabetical order as well as trying to source out the missing documentation for some of the current settings inside it.
 
Through some of the forum threads i have read, there has been lots of Advice/Tips regarding different AUD.ini settings.
 
I realize the values of these settings are all different as per setup.Although the setting/s itself should relate to something valuable you can add to your fellow user/s.
 
I would like to include a ( Tips: Section ) at the bottom of each "What it Does " AUD.ini Alphabetical Manual which will help understand possible connections to problems or interaction with other settings.
 
No ones asking for you to hand over your secret signal flow with those perfect chains that probably don't exist anyway.
( If they do you can hand them over by the way ! Just Saying! )
No just some very short tips linked to a AUD.ini settings, maybe something you tweaked and it worked or some super technical advice relating to buffer starvation ! Anything That you know will relate to or help a particular setting !
Just keep in mind that this is for everyone to reference from including you and helping to tie settings together with user experienced tips will make a huge difference !
 
The Main thing is the missing documentation for the remaining undocumented settings but i thought  hearing what (other people think of other peoples tips)< try saying that 3 times really fast !  before i add them will be fair and most importantly more correct.
 
Thanks

FlushMultiple=<0 or 1>(Default:1)
 
This variable determines how SONAR performs writes to disk in cases where multiple inputs are being recorded simultaneously. The default setting causes SONAR to write all the data for all inputs all at once, and then wait for the entire set of writes to complete. Overriding this value by setting it to 0 causes SONAR to perform each input’s write separately, and wait for each individual write to complete before proceeding to the next one.


Has Anyone changed this to (0) ?
or
Does anyone have advice on whether write all data for all inputs at once is better than write each input separately ?

DropoutMsec=<num>(Default:250)
 
Under high system load conditions, the SONAR audio
pump mechanism may become starved. When this
condition is detected, SONAR drops out. The
DropoutMsec variable allows you to configure the
tolerance time in milliseconds. This variable applies to all driver modes.
Setting DropoutMsec to a positive value > 0 specifies the actual time in milliseconds to tolerate before dropping out due to starvation.
Setting DropoutMsec to a negative value < 0 means we use a multiple of the audio buffer size as the tolerance.
i.e. -2 means we use twice the audio buffer size.
Note that setting this value too low (e.g. 0) can result in more frequent dropouts in the program. If you notice too many dropouts, try raising it in buffer multiples or by explicitly specifying a millisecond value.


 
Has anyone used the negative value for this setting ?
or
Can someone explain any benifits / differences between choosing (Positive : time in miiliseconds) or (Negative:multiplying the buffers) ?
Is one of these a "Better" Tolerance than the other.
 
 

I use DropoutMsec set to 500.
 
(By the way, it would be great if the preferences in Sonar window could sort these for us alphabetically by clicking on the column header, right now they are random.)
 
I made that change when I was beta testing Kaleidoscope. In the early phases it used a huge amount of CPU and the testers were all trying different things to improve it performance.
 
I made this change and modified some VST buffer sizes and stuff like that and got some benefit.
 
I just left things that way after that.
 
By the way, as I interpret this, it will have no affect on the typical glitches one might hear when the audio drivers buffer size is too short. That will not stop Sonar. Increasing this just tells Sonar to try a little longer before halting with a dropout message.
 

arachnaut
I use DropoutMsec set to 500.
 
(By the way, it would be great if the preferences in Sonar window could sort these for us alphabetically by clicking on the column header, right now they are random.)
 
I made that change when I was beta testing Kaleidoscope. In the early phases it used a huge amount of CPU and the testers were all trying different things to improve it performance.
 
I made this change and modified some VST buffer sizes and stuff like that and got some benefit.
 
I just left things that way after that.
 
By the way, as I interpret this, it will have no affect on the typical glitches one might hear when the audio drivers buffer size is too short. That will not stop Sonar. Increasing this just tells Sonar to try a little longer before halting with a dropout message.
 

Can you elaborate on why did you decided to go for a " positive "increase of 500 milliseconds and not a "  negative" -2 which i believe if i am correct with a current audio buffer size lets say of 2048 would give you a tolerance of 4096 i believe.
I am only trying to find out if there are any benefits or reasons behind going ( positive = milliseconds ) or (negative = Buffer increase ) when making the decision for this tolerance setting .
 
Also does anyone know if you did use a negative say  -2 for this tolerance setting if this would add any Latency !I assume not but i am sure many would ask !
 
 
 

taccess
 
Can you elaborate on why did you decided to go for a " positive "increase of 500 milliseconds and not a "  negative" -2 which i believe if i am correct with a current audio buffer size lets say of 2048 would give you a tolerance of 4096 i believe.
I am only trying to find out if there are any benefits or reasons behind going ( positive = milliseconds ) or (negative = Buffer increase ) when making the decision for this tolerance setting .
 
Also does anyone know if you did use a negative say  -2 for this tolerance setting if this would add any Latency !I assume not but i am sure many would ask !
 

 
I have no reason, I just tried a bunch of things that might seem reasonable and left things when it seemed like I was starting to make things worse.
 
It might not even have made things better as I don't think I reverted back to 250 to see if it made a difference - that was some time ago.
 
I just followed this methodology: make a test case, then adjust one (or two) things, repeat test, repeat with another change. Stop when you get exhausted, bored, or seem to be regressing.
 
I've honestly given up believing just about anything anyone says about optimization. I want to see it for myself. 
 
 

If it is any help to you, here are my AUD.INI settings sorted with the device-specific parts eliminated:

AllowOfflineRenderMixThreads=1
AlwaysOpenAllDevices=0
AlwaysStreamAudioThroughFx=1
AutomationDecimationMsec=50
BitsPerSample=24
BounceBufSizeMsec=0
ComputePicturesWhilePlaying=1
CopyOnImport=1
CSUseSpin=1
DataDir=K:\Sonar Platinum\Cakewalk Projects\Audio Data
DefaultAudSnapOfflineStretchMethod=3
DefaultAudSnapOnlineStretchMethod=1
DefaultEqPosition=0
DefaultSampleRate=48000
DefaultVocalSyncOfflineStretchMethod=7
DefaultVocalSyncOnlineStretchMethod=1
DisableIMDuringPlay=0
DiskBufSize=512
DiskRecBufSize=512
DitherAlgorithm=4
DriverID=0
DropoutMsec=500
EnableAsioBufferSwitchTimeInfo=1
EnableCacheWriteThru=1
EnableDeviceOutputLatencyCompensation=1
EnableLiveADCRecalc=1
EnableMixThreads=1
EnablePicCacheThreads=1
EnablePluginLoadBalancing=0
EnableSetThreadIdealProcessor=1
EnableSSEMixing=1
EnableWasapiDSP=1
ExtraDiskBuffers=2
ExtraPluginBufs=2048
FileBitDepth=64
FlushMultiple=1
FlushOnStop=0
FlushWriteBeforeRead=0
FreeMemOnUnload=1
GapDezipperUsec=500
ImportBitDepth=0
KsUseInputEvent=0
LatencyMsec=21
LinkPFSendMute=0
LinkSendPan=0
ManageASIOThreadPriority=1
MaxInputChannels=16
MaxOutputChannels=16
MaxPreviewMsec=300000
MeterFrameSizeMS=40
MinimizeDriverStateChanges=1
MinPluginLoadBalancingBufferSamples=128
MixDezipperUsec=50
MixThreadCount=0
MMCSSTaskKey=Pro Audio
MMCSSThreadPriority=2
OpenInputFirst=0
PanLaw=1
PanLawCompatMode=0
PanMethod=1
PicCacheLevels=2
PicCacheMB=500
PicCacheZoom=128
PictureDir=K:\Sonar Platinum\Cakewalk Projects\Picture Cache
ProfiledKS=1
ProfiledMME=1
ProfiledWASAPI=1
RadiusStretchingPhaseCoherence=50
RadiusStretchingPitchCoherence=50
ReadCache=0
RealtimePreroll=0
RecordPreAllocSeconds=3
RemoveDCOffset=0
RenderBitDepth=64
ShowMultiChannelInputs=1
ShowMultiChannelOutputs=1
SmpteMode=1
StartFadeMsec=0
StopFadeMsec=0
StopOnEmptyPlayQueue=0
SuspendPluginsOnBounce=1
SyncDivisor=8
SyncMaxDriftMsec=2
ThreadSchedulingModel=2
ThumbnailCacheSize=100
TimingOffsetBuffers=0
TimingOffsetMsec=0.000000
TransDetectorModel=1
UseAlias=1
UseHardwareSamplePosition=1
UseMMCSS=1
UseWDMDmaForWASAPI=1
VolMethod=1
WaveInBuffers=8
WaveInID=0
WaveOutBuffersKS=2
WaveOutBuffersMME=4
WaveOutExtraBuffers=1
WriteCache=0
ZeroFillDB=300
ZeroFillMethod=2

 

arachnaut

I've honestly given up believing just about anything anyone says about optimization. I want to see it for myself. 
 
 

Yeah, it's hard sifting through a lot of advice, particularly when advice may seem to help on some rigs and not others. But never the less, advice it's similar to music in the way that you start with something that leads somewhere else that changes places and eventually makes you get to the place you wanted,

Hopefully someone who has used the negative dropMsec setting comes along because it would be enlighting to hear a point of view on a setting no one seems to have used and i agree that a positive 500 does the job and probably should be the default instead of the current 250, my ideas with this thread was to try chat about the documented settings and get people's perspective on these particular settings so users 100% understand what each setting is best applied to tweak/troubleshoot, and then add some of those tips to the aud.ini alphabetical manual and tidy it up with some even more relevant information.
Sometimes when we ask something someone's not around and eventually they and the answer comes along. What I have noticed sifting through .ini threads is if you have all those tips and if we all added our best advice here they could all be added under each .ini setting as a huge head start .

Thanks for your input arachnaut it's appreciated

I do understand, and I'm all for reducing the misunderstandings and myths that get propagated.
This is a great thread and I'll put in my two cents plus inflation if I can offer any advice.
Since Sonar is so 'old' (or mature, or whatever - she's a lady, I'll be nice!) it has a lot of inherited stuff from DOS, Win 3.1, XP, etc. Lots of fixes and kludges and workarounds for older problems. Just like Windows.
Or at least I imagine that is true - I don't want to start a new myth!
 
So some of these may just be relics and not so useful going forward.
 
I think it would be great to split them in two or more parts - not so useful or old, somewhat useful in general, and brand new setting or updated recently.
 
 
 

Right now I am tweaking overclocking, SpeedStep, TurboBoost, Hyperthreading, PCI clocks and stuff like that.
But that's not the tweaks you want.
 
I don't like the performance I get with HT off, SpeedStep off, TurboBoost On compared with what I got with these in opposite states like I had before.
 
Even if I increase overclocking considerably, I had better results before I descended down this path of madness.
 
The ASUS motherboard BIOS I use is a dream and a nightmare - I have pages and pages of stuff I can screw with.
 
I wish I had a documented ASUS.INI file to work from. The BIOS help is not always a help.