Stereo Tool

Kewl! I'll keep working on the CPU load.

New version (improved "remove remaining loud peaks" in pre limiter) is online, BETA3A again.

Hi Hans,
Is it better sound now? i think it is, and yes, less cpu usage.

Hehe I'm currently trying the latest beta.

All sliders to the left: 36 % cpu usage
First three sliders in the middle: 44 % cpu usage
First three sliders to the right: 48 - 50% cpu can not handle, buffer overflow

Note that 50 % is one processor here, and all percentages have to be multiplied by 2 to get the load on one processor. I'm running this on a pretty recent laptop with a 2 ghz intel core 2 duo processor, with nearly every option enabled, including fm broadcasting.

Isn't it possible to make more use of threading and use both cpus more effectively? Or would that take alot of redesigning?

Also, I can not use other buffer sizes than best quality, starts to stutter (in a constant way, so doesn't seem to be buffer underflows or something)

I also noticed the bass was alot less present in the new beta compared to 4.22.

Anyway I was very excited to see the magic behind the quality radio boxes

At least for the highest latency (4096 or extra latency) setting, the 3rd slider (block overlap) doesn't have to be set higher than about 20-30%. Changing that will GREATLY reduce the CPU usage.
It's possible, but I'm first going to try to bring the CPU usage down in the first place. If that doesn't suffice (I expect that it will) I'll look further into multi-core processing.

The only things that I _can_ spread over multiple cores without increasing the latency take a very short time to calculate, and I expect that the synchronization and the fact that data needs to be copied to the other core will take away most of the performance gain.

Alternatively I can increase the latency and process different blocks simultaneously, that shouldn't be too difficult to implement. It would double the latency though.
I just checked it here but I'm not getting any stuttering. How fast does it stutter? (If it's processing related, I would expect it to be approximately as fast as the latency setting - 9 ms to 34 ms depending on the setting).
Is that with the maximum latency setting? Because with that setting the sound SHOULD be nearly identical to that of v4.22 (I've compared the spectra, and they are identical +/- 0.2 dB). Of course I might have missed something (if you're using a setting that I didn't include in my test for example)... I've performed my measurements using the "FM Loud Europe (Extra Bass)" preset.

It's not good to use First option in "Cpu Usage, Latency" because filters are not good.

Anyway quality is good with settings posted on picture erlier. I don't know for lower bass in this beta .. i'll compare it later with 4.22.

I've recorded a sample to show what's happening (stutter), also included the preset.

In the sample, I start at the highest quality setting, then switch over to 4096, it starts stuttering, then gets a buffer underflow, then i set it to 2048 and the stuttering is faster.

Recorded from FM (400 kB sample)
Preset

Also, yes all tests I did was on highest quality, couldn't test the rest.

It sounds like there's indeed a buffer underflow - and prior to that very small mini-underflows - so I think you need to increase the output buffer size a bit. It doesn't sound like a processing related problem, for that the stutter speed is too low.

Lowering the CPU usage (try setting "Block Overlap" to 20% or so) might also help.

I just discovered that I did something really wrong in the last version - which is why the CPU load is so high.

But - what I don't know is how I should fix it.

Method 1: Keep what I have now, just reduce the CPU load.
Should sound similar to the current BETA3A.

Method 2: Do what I intended to do (and which is what I did in v4.22)
I'll upload something as BETA3 in a moment where I did that. CPU load is a lot lower now (and can be lowered a bit further).

The CPU load for both solutions will be roughly identical. So the big question is: Which version sounds better?


On top of that, I've changed the implementation of the 'slope overlap' slider. For the original behavior of that slider, instead of setting it to x%, set the top 2 sliders to 100-x% (so instead of 20% 'slope overlap', set both 'steepness' sliders to 80%).

"Slope Overlap" has NO effect on the CPU load anymore, but setting it to a higher value hides the effect of the 'steepness' sliders. Setting both Steepness sliders to 90% is similar to setting 'slope overlap' to 10% in the previous version. BUT: If you then set 'slope overlap' to 10% in this new version, the artifacts caused by the Steepness sliders are lowered by about 4 dB.

That helps removing the big underflow, but not the small ones. even when the buffer is set to 5 seconds it's still the same.

And as a response to your last post, I think for low latency mode, the BETA sounds better than the original. And it's more responsive, I could use the 512 samples setting, and bring the buffer back down to 0.02 seconds without buffer underflows.

Hi Hakoon
Nothing wrong with ST processing just Cpu usage is big .. and your cpu can't stand it .. so buffer underfolw occures. I know that your cpu is not on 100% usage in that very moment. increaseing the output buffer size will not help, stuttering will occure soon or later.