Stereo Tool

In st 7.4 the detection type of the post-agc-compressor still defaults to the old compatibility type rms.

Windows stand alone: http://www.stereotool.com/download/ster ... 41-024.exe
Winamp DSP: http://www.stereotool.com/download/dsp_ ... 41-024.exe
VST32: ----://www.stereotool.com/download/vst_stereo_ ... 41-023.dll


Changes:
- Removed some multi-threading, replaced it by doing everything in the same thread. I would have expected a small deterioration in performance, but on my pc it's actually running faster!
- Memory usage should have been a lot lower but appears to be nearly unaffected. I don't understand why... Oddly, if I turn some compiler optimizations off, it uses about 60 MB less!

Older changes:
- Hard Limit for composite clipper caused very soft clicks every block!!! Also in older versions...
- Composite Limiter was running in a separate thread, and taking 2 ms extra latency. The new version does not do that anymore, and returns a cleaner spectrum, but it requires a bit more horse power from the PC because it doesn't run on a separate CPU anymore.
- Added HQ mode Not available, for testing only
- Improve Multiband3 and Singleband2 limiting and (to a lesser extent) compression for low latency settings. LQ output should sound similar to normal output! Fixing this will also improve audio at lower latency settings. Compressor is probably more or less ok, limiter is pretty horrible, also at lower latencies!
- Fixed Phase Rotation frequency effects at low latencies (need to compensate for loss at certain freqs in low latency modes)
- Fixed AZIMUTH behavior at lower latencies
- AGC behaves slightly differently for lower latencies - Kinda OK. With shorter block size the drop for short spikes is bigger, which leads to a slightly lower overall output level. But I cannot easily fix that. Other differences are fixed now.
- Clipper (probably only ABDP) does not work well for latency 128. Yup -> if I lower the top bass freq from 400 to 200 Hz it's MUCH better. Fixed.
- Something removes low bass in low latency modes. -> EQ and other things. -> Improved. Difference is still large though.
Rewrote LQ Low Latency monitoring to use the normal processing code. Works reasonable, sound resembles that of the normal latency EXCEPT for the bass limiters and to a lesser extent the compressors in the multiband section. Memory usage for plugin version is reduced by more than 20 MB. Stand alone version might use slightly more than before.
- Fixed FOX TV Carbon Coder R128 normalization issue Waiting for feedback.
- Moved a lot of threads into a single thread. Might improve hiccups that some people have reported.
- Added Power Highs (it's in the same window as Power Bass).
- Moved Power Bass and Power Highs to before the wideband AGC to improve volume level consistency.
- Sudden fast rise of bass or highs is limited, new slider 'Release boost' added. I'm not really sure yet if this is ok; if there's a loud high or low sound it can push the band down a lot, and it comes down slower than before. If needed I can add something to allow it to come back faster after a short spike. Waiting for feedback first though.
- Sidechain checkbox removed (without that doesn't exist anymore).
Attempt #2: Redesigned Simple Clipper. Reduced CPU load.
- Reduced the memory usage
- Fixed most of the Stereo Image artifacts!!! "Deprecated" is removed from the sliders that were marked with it. See (*) for a cool new possibility!
- Removed some more unnecessary steps (AZIMUTH 2x, Stereo Boost 2x). 10 remaining.
Fixed 'Post filter for DC offset' problem.
52. Check CPU load. Start with checking if there's anything left that uses the 'unnecessary steps'. Sevdah Web preset: Data still gets converted 58 times... I think I need to do this one first, it should have some effect on the CPU load. 28 removed - next convert the 2 IIR filters so they can be optimized and the merge/split around it can be removed. I'm not measuring any effect from this though (but it makes the code simpler which is also good)
53. Noise Gate/Stereo Boost: Pre-calculate 1-cos() and sqrt() values.
55. Check MemoryPool behavior for cache improvements -> No effect measured, and might make behavior less constant.
56. Check if we can go in opposite direction for each next step to improve cache.
57. Check if lazy reverse FFT is an option. -> No, difficult and gain does not even seem to be measurable.
58. Created a separate class that performs the processing chain. Currently the same code is repeated twice (once for normal processing, once for low latency processing) - which means that a lot of code is duplicated and it's difficult to add extra chains. Most, not all, of that code is now moved elsewhere.

TO BE DONE:
- Spread over cores is not constant, which causes differences in performance. I *think* it might be the chain2() code that causes this. Actually it might be a good idea to get rid of that completely...
- Get rid of chain2() thread. This should also allow reducing the ASIO latency by 1 step (usually 1.5 ms). Hm.... Or not? I'm confused
- Composite Limiter effect no longer visible in GUI. (Is that bad?)
- New ASIO behavior: Push samples, read them back directly from buffer, skip whole Chain2 stuff. For HQ mode, add redundancy protection.
- Reduce stand alone version memory usage (unused low latency thread items can be removed.)
- Old Hard Limit for composite limiting was slightly tighter input level was very high. And had no overshoots; the new one does.
- Add watchdog for stand-alone version. Both built-in and separate.

Broken Download Urls

_________________
Sexy Girls in your city

Sorry - fixed!

On my AMD X6 CPU the load decreased by 1-2% with the new beta 24 over beta 23. Still very low overall usage but Stereotool seems to use one CPU more than all the rest. 80% on one and another at about 45%. The other 4 are just above 0%.

_________________
J0HN II

@john2: That confirms what I'm seeing here - great!

Ok... Next version might have a lower ASIO latency (1 step, usually 1.5 ms). But I'm actually not too sure about this - I think I made a 'reasoning error'. This piece of the code is pretty complex, I want to rewrite it completely at a later point.

On my system I see a memory usage reduction of 60 MB! Building now...


A bit more info on the ASIO latency:

Old situation:
- Samples arrive and are sent to a function that collects them until it has enough samples to process a block of data
- For each new sample that arrives in this function (which blocks during the processing of the block of data), one processed sample from the previous step is sent to a separate thread which performs some extra processing steps and sends it to the sound card.

New situation:
- Samples arrive and are sent to a function that collects them until it has enough samples to process a block of data
- After processing of a block, some extra processing is performed in the same trreads and the samoles are sent to the sound card immediately.

In the old situation, if you have a very fast CPU that needs less than 1.5 ms (which is usually the minimum ASIO latency that doesn't cause hiccups), then:
- First tick: Samples arrive and are processed.
- Second tick: Processed samples are sent to the separate thread
- Third tick Samples are actually moved to the sound card

In the new situation, the 2nd tick is gone.

Hello Hans,

Did you had a look on the stereo boost problem?? Do you think it's possible to solve it?

Thank you,

Sorry not yet. Are you sure that you are feeding both channels at the same level? Stereo Boost will increase level differences.

Give us the song that you listen , so we can test it too. May be he is listening a song that is recorded with some stereo effect, i don't know.

This new version is really getting difficult, Well not so much difficult - it's simpler than before. But it's a major rewrite of some (currently complex) parts of the code.

I'm building a new version now that I'll upload tomorrow morning. It appears to function properly, although I have not yet tested some 'strange' settings (input sample rates below 32 kHz, or between 50 and 128 kHz).

I was considering keeping it as it is for now, but I need to bite the bullet at some point - and once this whole thing is done I expect the CPU load to be a bit lower again. So...


One user reported a strange issue, actually I would have thought that it's an improvement but he clearly thinks otherwise: Before it was possible to create a normal stereo output signal with RDS on top of it. Actually that doesn't make sense, and in the new version if you use composite output (which is when you have either stereo or rds encoding enabled), if you disable the stereo coder you just get mono output. This one user was feeding the stereo signal to his transmitter which - for some reason - was transmitting an RDS signal that way.