Stereo Tool

SSE2 is the limit here. If you compare Core vs. Core2 (the laptop vs. Hans system), on a raw architectural level, there isn't much difference. It boils down to clock speed or cache. Everyone reporting significant issues for some time has less than 2MB cache. E-v-e-r-y-o-n-e. Those with 2MB or more noticed the stutterings with BETA57SLOW through current.
I'm seeking to see an apology there, but I don't exactly find one. It's more of a "don't be offended with what I typed" than it is an "I'm sorry, I misunderstood what you typed."

Regardless, if you'd like to ease up on the "you're an idiot" content of your posts to me, I'll be happy to continue discussion. I could be wrong about the cache, but the evidence (reports from people) is decidedly on my side for the moment.

People, please keep each other alive...

About the cache: I think Brian has a point here. Even on my own system I think the Natural Dynamics filter *is* memory bandwidth limited rather than CPU limited.

This is partially caused by a poor implementation (I'll have to perform some optimizations, and I must say after reading Brian's post about the 1 MB/2 MB cache I think they'll be far more effective than I first thought, maybe even enough to make the filter usable).

The issue here - and it's valid for Multiband as well, but may be less problematic there because there are less bands - is that I'm actually using a massive amount to store intermediate results:

- Each band takes 4096 * 2 float values (4 + 4 bytes) = 32 kB
- I have 18 bands, so that's 18 * 32 = 576 kB. Which fills up more than half of the cache, if it's 1 MB.
- Next, and this is something that can easily be optimized (but I didn't know what I needed exactly when I wrote the code): 18 bands of volume information. That's another 576 kB - which means that it's now using OVER 1 MB of memory.
- On top of this, for overlap purposes I also need to access some intermediate results from the previous step - another 576 kB of which I use half, so 288 kB. Ow, and I also need the matching previous step volume info, another 288 kB.
This totals 576 + 576 + 288 + 288 = 1728 kB. That's close to 2 MB. And I might even be forgetting some things.

The issue here is that there are effects between adjacent bands, which means that I cannot just process one band at a time. The optimization that I can perform is only keeping the bands in memory that I need.

When I wrote the code:
- I was using existing Multiband code, where there are all kinds of links between bands so I need all of them at once there.
- I didn't know how much effects between bands I would need (as it turns out, I need 2 adjacent bands on each side of the band that I'm currently calculating - now that I know this I can optimize for it).

Still I'm not sure if I'll be able to lower the memory usage below 1 MB - maybe I should slightly lower the number of bands.

But I'm also still thinking if there's another way of getting the same result. (I know Leif uses a very different implementation in his multiband, and I've actually used that same mechanism myself on image processing in the past, that lowers the memory usage to about 1/4th of this, even if I keep ALL the bands in memory... But I expect more artifacts with that method if you configure it very aggressively. On the other hand, it will be far more efficient in both CPU and memory usage, so maybe I should use it for Natural Dynamics but not for Multiband).

I'm not sorry for not correctly reading what you typed. Twice. Accidents happen. I'm not perfect, and I'm never going to be sorry for not being perfect, or I would hate myself.

I am sorry that you were offended by my misunderstanding. I wasn't disheartened when you said I couldn't even read English. So yeah, it's an honest mistake of mine, so please don't rake me over the coals over it any more, or I'll stop caring about chatting with you... which I do enjoy for the moment. I'm all about the pursuit of the absolute truth, if possible, when it comes to the matters of all things technical. It's one of the ONLY areas this can even happen, in our largely random and organic universe. (at least, how we understand it right now anyways, who knows, maybe it's all going *exactly* as planned, bwahaha)

I don't think you're wrong about the cache if the issue is that there is overall stuttering problems that are not caused by the CPU time being over-utilized (very close to 100%). While the CPU use itself won't be effected until stuttering happens, and the CPU use will stay the same or decrease... (that being said, here's the part where we already both agree )

The cache SIZE being an issue WILL become more of a problem the closer to 100% the CPU use is, because the remaining CPU time in each audio block will be increasingly closer to the amount of time spent caching code.

Using a benchmark of system memory read speed, and knowing the total "worse case scenario" instruction and data throughput requirements, and knowing the CPU time required per block, and ofc the block length... one can figure out exactly what percentage of the available time that *could* be spent on code/data reading IS. And that's *without* any caching at all.

I'm NOT 100% sure that your system, at some-80s% CPU use would have enough system memory bandwidth to keep up in that some-15% of CPU time that's not getting used. But I'm about 90% sure it would. Basically you see if the total code/data caching throughput of the application is less than 15% of your total system memory throughput. And even more importantly... how much less. If caching is a large problem with overall realworld PERFORMANCE (not to be confused with CPU use) of StereoTool, then you should not be able to use 100% of the CPU with StereoTool. The worse the caching bottleneck is, the farther away from 100% CPU you you'll be, where the stuttering first starts to happen.

There actually *should* be some kind of software to measure this, if it's even possible at all. I might have a look around later today or tomorrow if I think of it. It would be a very interesting thing to be able to measure, wouldn't it?

So yes, it can be a very real performance problem. But it should not cause "CPU Usage" to increase according to any modern OS kernel that I've developed server applications for recently (OSX, Linux, WindowsNT, Oracle, Solaris, AIX, and BSD within the last 10 years), since the problem is that the CPU would be under-utilized.

Anyways, I shant beat a dead horse, I know you "get it" like 2-3 posts ago. Cheers.

If it's causing stuttering, then that is absolutely a possibility.

The coincidence with a decrease in "CPU Usage" and in fact CPU time isn't related to caching. That was my main point. I wasn't trying to ever say that it couldn't effect realworld performance, especially the higher that the CPU use already is. (see my simple math to asses that, above) Just trying to keep things moving forward, as logically and fact-driven as possible while being "anal retentive" as little as possible.

Just for data. This doesn't include any instruction cache. So that is most definitely being at least partially re-cached constantly.

Even on 2MB cache, that doesn't leave a huge amount of room for instruction cache, so some potentially useful CPU time will be spent waiting. Coincidentally these are generally faster CPUs that have plenty of CPU time per audio block to spare on just waiting around, and generally faster system memory as well.

Worth a shot. It'll be interesting to see if/how it impacts the sound quality as well.

Can I get a witness?

My point was, is, and, until such time as the memory requirements for what he's doing decreases, will be, it's exceeding the cache that I've got. When the computation goes beyond the available cache, it's *GOT TO* go to main memory. Yes, yes, I was mistaken about stating HyperTransport is involved. It's not. The DRAM Controller <--> RAM bridge is though. It *IS* going to be slower than 2750 MHz.

Anyway, I, allegedly, have a point. Ending this discussion now...

@Hans:

Subject switch...

What is the expected behavior of "From 350-600 Hz clip below" slider in loudness?

Is it expected that if I take that to 0, that I completely lose all bass, not just the content from 350 to 600?

Also, if I take the under 150 slider down to 0, I do *NOT* lose bass?

The name is a bit unclear (I'll change it).

- The below 150 Hz slider: If you set it to 0 you loose the bass below 150 Hz.
- From 350-600 Hz slider: I've changed the name to Below 350-600 Hz: It reduces EVERYTHING from 0 Hz upto those frequencies. So setting this to 0 removes all bass.

BETA061:
- Changed the clipping detection behavior. There should be less false positives now, and clipping should be detected better!
- Changed the default values to match the new behavior (lowered 'may be clipped' slider from 70% to 65%, increased median deviation slider from 15% to 20%.)

Winamp DSP plugin: http://www.stereotool.com/download/dsp_ ... 20-061.exe
Stand alone version: http://www.stereotool.com/download/ster ... 20-061.exe
VST version: http://www.stereotool.com/download/vst_ ... 20-061.dll
VST version (No SSE2): http://www.stereotool.com/download/vst_ ... 20-061.dll
Command line version: http://www.stereotool.com/download/ster ... 20-061.exe
Linux command line version: http://www.stereotool.com/download/ster ... ETA620-061 NOT AVAILABLE
Linux GUI version: http://www.stereotool.com/download/ster ... ETA620-061 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: Cleaned histogram must be mirrorred. After cleanup, mirror center is place where SIGMA above == SIGMA below! Only use on the lower end. Then run cleanup again! The result should contain approximately the same amount of data above and below. If not, that indicates incorrect detection.
- Declipping filter: Add a long term histogram, and use maximum of short term and long term start clipping level detection.
- 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)
- Declipping filter: Create a new histogram after declipping, clean up and subtract from original.

Clearly that is not working properly...as I can listen to Lil Jon & Ying Yang Twins - "Get Low", with the slider all the way to 0 and have plenty of sub-150 sounds...

Ah, that's the 'dynamic' part: It only reduces the bass if there are highs to make room for. If there's ONLY bass, or little highs, the bass won't be completely removed.

All the sliders in this area are intended to protect mid/highs against extremely loud bass sounds, which would otherwise cause distortion.