• SONAR
  • A loud pop and a maxed-out meter level followed by no sound? (p.4)
2017/07/13 00:21:46
PeterMc
Here's a possible fix for the loud pop/maxed-out meters problem - try setting ZeroFillMethod=0 in AUD.INI. This turns off the zerofilling. I suspect (for reasons too long to go into) that the zerofilling is a possible cause of the problem.
 
Of course, it's not quite that simple. Not all plugins do zerofilling. Sonitus do, but LP, for example, don't. Those that do zerofill spit out the tiny non-zero numbers even when the transport is stopped (although the audio engine needs to be running). You can see this by inserting SPAN after the plugin and looking at the RMS and peak values. Some instruments also do something similar (maybe not exactly zerofill, but there's a small signal always output), for example, SI-Bass-Guitar does. I've found you need to mute or archive these tracks too to test this theory. Put SPAN on the Master bus to see if any tiny signal is getting through even when the transport is stopped. If so, you haven't found all the instruments putting out tiny numbers.
 
Please report back positive or negative results here. Whatever we find might help nail this bug.
 
Cheers, Peter.
2017/07/13 00:50:21
taccess
- PAGE 9 - http://www.musicdsp.org/files/denormal.pdf 
 
3.2.5 Alternatives and efficient solutions
The methods below are derived from the previous ones and are close to perfection. They fit in
numerous common cases and are very fast. They are based on the addition of two alternative
values to the signal. As soon as the added value changes, the denormal apparition is prevented in
or for future feedback loops, for a limited number of samples. Value alternations just have to be
frequent enough to prevent most of the denormal apparitions.
Spectrum of the generated noise is quite rich. Moreover, by choosing 0 for one of the values, one
can create a DC offset while reducing calculations
To minimize calculations, one can also call
add_dc()
sporadically, for example one time every
20 samples, or even more. This produces random pulses, the spectral content of which is rich and
close to the white noise. However generating this random time component is not always obvious
and easy. One may just call
add_dc()
regularly to generate an impulse train. This method also
produces a lot of frequencies everywhere in the spectrum. It is especially adapted to block-based
processing. Of course block size should be carefully chosen depending on DSP algorithm
architecture.
+
Very fast.
Fills the spectrum almost uniformly.
Propagates to next stages.

It does not eliminate denormal numbers, but prevents their apparition.< if this is the negative then how promising is this )
To be maximally efficient, requires block-processing algorithms whose size should be
carefully chosen.
Alters the smallest numbers by quantifying them.
2017/07/13 01:38:07
PeterMc
Thanks for that. It's quite old (2002) and poorly written (e.g. quantifying should be quantizing, apparition probably means appearance), but it gets the message across. It's kind of like dither for computers :) I'm left wondering whether modern CPUs suffer the same problems as those from 2002?
 
I'll also ask, what happens if the value that is added is almost the same size but the opposite sign to the original data, thus creating a denormal? I wonder if that is what is happening inside Sonar.
 
Cheers, Peter.
 
2017/07/13 07:22:23
Samuel540
"mettelus:
Having an "audio engine troubleshooting" feature to hunt/kill bogus plugins would save some folks (literally) hours of troubleshooting time, alleviate the need to use "safe mode" when opening a project, and also supply a definitive answer from the right source (the audio engine itself) instead of trial and error or tribal knowledge from the end user(s). Such a feature has been hinted at before, and it is definitely one end users would find immense value in."
 
For a DAW like SONAR with so many anomalies and problems that constantly steal your focus from creating music, something like the above-mentionend "audio engine troubleshooting" in mettelus' comment, should have been implemented a loooong time ago.
 
We're now in the year 2017 but it seems like these problems aren't going anywhere. So I guess these problems are most-likely being migrated over to MacOS when that release finally comes out and that's a problem.
2017/07/13 10:00:29
ZincTrumpet
Useful to have the explanation from Cakewalk but I also think that more could be done to manage/report the consequence of the problem occurring. Some helpful ideas from Mettleus, Petermc and taccess (sorry if I missed anyone).  So how about a response from Cakewalk (on a possible update to manage/report the issue)?
2017/07/13 22:00:13
Fabio Rubato
abacab
bitflipper
I never use the 64-bit option, either.




I'm surprised at the number of posts here and in various threads from Sonar users that have shut off the 64-bit option.
 
That can't be a good sign ...


Me too. I now habitually turn off the audio engine before adding a new plug-in - esp on buses - and since I've turned off the 64bit option, no melt-downs. 
 
+1 to the Audio engine processing thingie to hunt/kill misbehaving naughty plug-ins BEFORE they *u## things up. :-)
2017/07/14 05:51:13
BRuys
I wonder what the difference is between users that have the problem and users that don't.  I run S-Plat every day and have a bunch of plugins.  I have seen the problem maybe a couple of times in the last couple of years - extremely rare for me, but I have seen it.
 
There must be a common denominator that can explain the issue and also why users like me virtually never see it.  Hmmm...
2017/07/14 09:44:36
Sir Les
I have noticed this in past times using sonar...but, I also noted cpu spike when this audio level would pop to the extreme ...and then no sound.
or some kind of hard drive thrashing on the cpu /disk metering...at times...
 
That is why I dug into MS windows services....as I was not using any FX, or any of the on bus or track features..all were turned off in my templet , as someone said to do once upon a time to stop a new feature add in from causing this issue of pops...is to turn off...all channel strips...but it did not solve.
 
Thus seeking into the logs of event viewer ...brought me to ruin...and updated and more and more problems...trying to solve the logging....which I think, was caused by the secret arm of MS trace and track...of your data on all drives while working in or on the system...win10 does do odd things with the nic and cache.
 
Just saying...it may work out..it is a plug in...
 
So...I stopped using it..and wait for a more bugged less of Les OS....
 
 
Just smile..it might take a picture of your frustrations one day...and or any uttered words ....cortina cortana..did you ask the machine why this is happening?.....LOL
 
Just be cheery...I am sure, they will dig into the...hacking it out soon...if it continues...wait...
 
Now what works, while waiting a life time to use?...ah....Some say Cubase, some say Studio One 3, some say Reason 9.5...Pro tools is a monster daw...
 
and others say the free stuff works ok also....so, you can still make stems...and import when, and if the issues are fixed.
 
 
 
 
 
2017/07/14 23:00:53
taccess
Can you please screen capture / audio capture the pop / spike problem you have , we realise it's too hard to re create but with video evidence cakewalk will have a better chance at fixing this .
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account