Stereo Tool

(Beta59) Declipper + Nat.dynamic booster+loud metal music causes the sound stutter. Look at that:
Core i5 760 CPU ..

Switching off dynamic booster stops stuttering.

@Vortan: Still I think the CPU load is too high... The whole processing occurs on one core, which means that you quickly run into trouble.

I don't know yet how to optimize it, but I will - this is (for most people) unusable.

BETA060:
- Improved performance of declipping again.
- Added short-term declipping maximum level determination to avoid some unnecessary repairs.
- When determining the tilt, the reliability of tilt detection for each portion of audio is used
- If no tilt is detected, the tilt level slowly drops to the default tilt level (currently hard coded at 0 degrees, will be configurable).

Winamp DSP plugin: http://www.stereotool.com/download/dsp_ ... 20-060.exe
Stand alone version: http://www.stereotool.com/download/ster ... 20-060.exe
VST version: http://www.stereotool.com/download/vst_ ... 20-060.dll
VST version (No SSE2): http://www.stereotool.com/download/vst_ ... 20-060.dll
Command line version: http://www.stereotool.com/download/ster ... 20-060.exe
Linux command line version: http://www.stereotool.com/download/ster ... ETA620-060 NOT AVAILABLE
Linux GUI version: http://www.stereotool.com/download/ster ... ETA620-060 NOT AVAILABLE

TODO:
- Fix loading changed multiband frequencies
- Add buffer and filter for SCA output (SCA1 ok, SCA2 ok)
- Finish AGC improvement - make mono value configurable (replace checkbox by slider) 1 hour --> NO, not needed - anything else needed? -> NO
- Fix Punch
- Check what to do with new filters (such as bass AGC) - keep them, remove them, change them? --> KEEP
- Save new BASS_AGC setting in VST mode
- Loudness: Annoying cracking sound in bass. Slightly present in 5.00, worse in 6.00, maybe even worse in 6.10. Only when bass is too loud. Much worse than in Final Limiter (at same input level!) - so this clearly indicates a bug. Most likely cause: The filter that was added to remove bass artifacts....... - No, it's the louder bass. But it can be fixed by changing some settings. Default settings updated, and behavior for 'not Very strict' improved. Also Deep bass boost and Very deep bass protection are enabled for latency 512 now.
- Fix crash at program close
- Fix VST plugin version (does not run)
- Dynamically drop 'Allow louder highs, even if it causes vibrations' to 0 when bass filter suspects noticeable voice vibrations. 1-2 hours
- Reduce Loudness CPU load days?
- Check and remove static variables
- Finish new de-essing filter (check what to do with the settings, remove at least some!) 1 day
- Convert Multiband input to MONO, then use arrays [2][4096] --> should give speedup. - FAILED
- Natural Dynamics: Fix or remove transient boost
- Natural Dynamics: Add expected + strength slider per band
- Finish declipping filter (clipping level detection + level reduction in dB). 1. Figure out why removal of unwanted frequencies causes flat lines at high quality setting with small overlap. This causes distortion, with this fixed repairs are MUCH better. 2. Fix MP3 correction, automatically scale down when this deteriorates the sound. --> TOP part fails!
- Declipping filter: Fix low latency behavior
- Always oversample clipping (configurable)
- Declipping filter: Change detection at lower input levels.
- "Test Right Channel" in "FM Transmitter Calibration" does not work since v6.10 (standalone) (bojcha)
- Declipper window close function - check! - Seems ok
- Scopes black background?
- Add AGC start level
- Declipping filter: Add comparting of sample history to make sure loud bursts are still detected properly (now, with 16 blocks of history, 65 samples are removed even when ignoring just 0.1%). I should also check the current block (probably with a margin of a factor 2).
- Declipping filter: Use reliability of tilt detection to determine movement speed; slowly move to default tilt (configurable!)
- Declipping filter: Far too many samples are marked as 'maybe/probably' clipped. Histogram not used or not cleared?
- Declipping filter: Optimize tilt detection for performance. SSE2 for maximum. And keep separate smaller histograms to determine the maximum (should perform much better).
- Declipping filter: Optimize peak matching for performance: Move determination to extra preprocessing step; try to change if statements to min/max or something.
- RDS issue reported here: viewtopic.php?f=15&t=3703&p=11524#p11524 partially solved
- Declipping filter: Add setting and saving of new sliders (history size, percentage of highest samples to drop, tilt detection range start, end and precision)
- Natural Dynamics: Voices, especially in chorus, still sound weird.
- Natural Dynamics: Smooth out different bands more to reduce low-bitrate-MP3-like sounds.
- Natural Dynamics: Optimize situation with no interaction between bands for performance.
- Update presets? (BASS_AGC etc.) 1 day
- Finish blind interface
- Channels L/R swap in stand alone version when changing filtering/quality (?) (eldoradofm)
- Move pre-emphasis to end of processing 1 day
- Save all new settings, also through VST interface
- Change version number 1 hour
- Release 1 hour
- Add lowpass filter for stereo signal (will cause a lot of extra latency!) - it might be possible to avoid this latency using a Hilbert transform
- Add smarter clipping detection. Maybe something much simpler suffices: Current clipping detection with threshold + flat line detection
- Declipping filter: Automatically override the 3 clipping level sliders if the clipping level is detected very clearly (clear thin spike in sample value histogram). - NONSENSE, this is already done by the histogram function. But it can be made a BIT better - I think - by automatically LOWERING the 'always clipped' slider if a lot of data is present at the highest few bins (but care is needed for DBN - Jack is Back like tracks)

Have you tried to adjust your (external) latency settings ?
I use the Stereo Tool DSP version in combination with 4 Breakaway Live Cores (with 4 VACs).
All with different latency (plus different sample frequency) settings inside Breakaway Live (so for TV I can use 2048 sample latency inside Stereo Tool and for music 4096).

And under certain circumstances I sometimes get a stuttering with some STS presets (that use excessive processing).
But in most cases this can be fixed by using a higher audio driver latency setting in Breakaway Live.
Obvious the latency is not constant.
It depends somehow on the processing intensity.

Drake - "Fancy" down to mid to upper 70s instead of 80s, so marginal improvement...

DDR 500, or more accurately named PC 4000, actually has a clock speed of 250mHz. So if you memory is actually running at only 50mHz clock speed, then something is massively wrong with your config.

That being said, I think you are drastically mistaken about the bottleneck of the memory in relation to the vast average of audio recording/playback and processing. First off, moving code from memory to L2/L1 for operations happens EXTREMELY fast compared to the latency of 1 frame of audio. Even with a total of 1ms latency from the I/O (which you'll *maybe* get with an RME and a crazy low DPC latency), the amount of time it takes for the code to go from executable module in memory to L1 is a MICROSCOPIC fraction of that time.

The other concern would be the audio data itself. And that is also a nearly infinitesimal amount of data compared to the overall throughput of PC 4000. You wouldn't start running into issues until you're dealing with over 100 channels of high-res (32bit float 192kHz) audio, most likely somewhere over 200 channels of high-res audio.

So your memory speed and L2 size has essentially ZERO effect on the performance of your setup for this application, because it happens so massively much faster than the latency of the workload itself. Also, the nearly infinitesimal effect it does have is not even measurable in terms of CPU use.

Given that you cannot follow simple English, I'm taking your discussion with a HUGE grain of salt.

"I'm running DDR-500, which is 50 MHz [open parenthesis] 100 if you count the double rate [close parenthesis] higher than the nominal rates for Socket 939 (Athlon64) [which is 200 MHz, or 400 if you count the double rate)."

Let me be blunt. You and Vortan can get up off my back or just put me in ignore. I've already put Vortan in ignore.
Disable your damn cache and watch your performance plummet, or perhaps underclock your memory, or shut up. I *DO* know what I'm talking about, and I'm really, really, really, REALLY tired of being attacked. I yanked copies of the preset I was working on last week because you all irritated the crap out of me, and I had just now settled down after having some time and some PM discussions with Hans.

Thanks for your compliance.

I never said the cache wouldn't effect performance. But for the VERY small amount of memory required for (A) the code and (B) the audio, and given that it takes only a microscopic amount of time to happen compared to the required time that MUST be taken for the audio latency itself to happen, the size of the cache and the speed of teh memory simply is NOT a bottle neck for you or anyone else at all.

And it's true, even if the data being pushed through the CPU were high enough, and the required latency of the work load low enough, for your memory speed and cache size to impact the performance... it *still* wouldn't be measured in terms of CPU use. In fact, you would get stuttering and decreased performance, and you would actually see LESS cpu use.

This is not a personal attack on you. Take it however you want though, I'm not offended by you getting offended over nothing but technological fact, so I won't be ignoring you.

---

If you want to prove that I am right, or wrong, run a memory throughput test on your machine. Here are the numbers to compare to, with a worst case scenario in terms of required overhead bandwidth:

512 samples per frame @ 192kHz and 1MB of cache for reference (even if it's not all being used)... that's: 750 Megabytes per second assuming that ALL 1MB of cache is totally reloaded TWICE every single frame.

The audio itself is 750 Kilobytes per second, each time it is transfered to/from memory, so if Hans wants to kick in how much that would be in total throughout the process, he can... but I think it'll be a moot point compared to the cache (assuming of course that the cache is fully reloaded twice, absolute worse scenario possible).

Now see how much bandwidth your memory actually has. [edited]You should run a test that can test what the read speed is, since that's what would be happening while the CPU is caching memory from the already loaded process in memory.[/edited]

---

PC 4000 really is 250mHz clock though (operating at 500mHz equivalent), and the HyperTransport on Socket 939 is actually 1gHz. "DDR" doesn't apply to the FSB, HyperTransport, PCI(e) bus, or the CPU clocking, it's strictly used in reference to system memory. The base clocking also is multiplied to whatever the actual devices are using. That's how I have 800mHz DDR2 (1600mHz effective) in TWO Socket 939 systems I have in this room right now. One of them is decently slower than your machine, despite having much faster memory.

Whatever...

You know, there is a post somewhere on here from someone with a Core generation laptop who is *ALSO* having CPU utilization issues. Core trumps K8 across the board. The similarity is the 1MB L2. Bojcha's system? Hey, lookie lookie. 1MB L2, but at a higher clock rate, so that system is simply plowing through faster because of having to wait less time.

Oh, and Hans' system? The one that is clocked LOWER than Bojcha's, but has 2MB L2 per core and has no problems? What about that?

Another factoid is that in my past experience with SETI@Home, there was a discussion about FFT size and being able to fit the transform into the cache and it making a HUGE difference in processing times and reduced CPU load.

...and I know full well that the S939 spec is for DDR-400. DDR-400 is 200 MHZ, double data rate, arriving at 400. I said that my memory was running 50 or 100 higher than nominal, which is 100%, fully, completely, totally accurate, unless you're wanting to nitpick, or are blind as a bat and didn't see the "higher than nominal" portion.

Stop being so petty.

This IS correct. SETI@Home, Dedicated.Net, etc, etc... they don't HAVE to wait for data to be input into the chain like it does in a realtime audio (or whatever other form of sampling) application... so the overall throughput is effected by ALL of the time spent waiting for the code to cache. With a realtime sampling application, the overall throughput is only effected when the time spent waiting for code to cache is longer than the required latency of each frame MINUS the CPU time spent processing the frame. When that happens *then* you will have wasted clock cycles which cause stuttering, etc, and the further above that you go, the less the total CPU time is used by it will be. It'll never cause the CPU time to be more, because caching doesn't get counted as CPU use. This holds true for the Task Manager's "CPU Time" and "CPU Usage" as well.

But I'm definitely not saying that it doesn't effect performance. Eventually there can be a bottleneck cause by lots of caching, lack of memory read throughput, and the CPU time required to be spent per frame length for a given the CPU's "cajonies".

I did not see that, BOTH times I read it. Can I have a Kit-Kat moment? (I had TWO flat tires last night, walked 3.5 hours in the freezing rain, got 3 hours of sleep, and spent the better part of today dealing with more tire mayhem.)

[edit]
by the way, i'm reading through this now myself, since... it seems enjoyable despite my brain fry... entertainingly written
http://arstechnica.com/gadgets/reviews/ ... hing.ars/1
a short history of CPU caching
[/edit]