Stereo Tool
https://forums.stereotool.com/

Low latency secondary input (microphone)
https://forums.stereotool.com/viewtopic.php?t=853
Page 23 of 75

Author:  hvz [ Tue Jan 05, 2010 4:18 am ]
Post subject:  Re: Low latency secondary input (microphone)

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

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

Author:  Bojcha [ Tue Jan 05, 2010 4:04 pm ]
Post subject:  Re: Low latency secondary input (microphone)

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

Author:  Kakoon [ Tue Jan 05, 2010 7:54 pm ]
Post subject:  Re: Low latency secondary input (microphone)

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 :)

Author:  hvz [ Tue Jan 05, 2010 8:39 pm ]
Post subject:  Re: Low latency secondary input (microphone)

Quote:
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
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.
Quote:
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?
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.
Quote:
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 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).
Quote:
I also noticed the bass was alot less present in the new beta compared to 4.22.
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.
Quote:
Anyway I was very excited to see the magic behind the quality radio boxes :)
:-)

Author:  Bojcha [ Tue Jan 05, 2010 8:49 pm ]
Post subject:  Re: Low latency secondary input (microphone)

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.

Author:  Kakoon [ Tue Jan 05, 2010 9:34 pm ]
Post subject:  Re: Low latency secondary input (microphone)

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.

Author:  hvz [ Tue Jan 05, 2010 10:02 pm ]
Post subject:  Re: Low latency secondary input (microphone)

Quote:
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.

Author:  hvz [ Tue Jan 05, 2010 10:14 pm ]
Post subject:  Re: Low latency secondary input (microphone)

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.

Author:  Kakoon [ Tue Jan 05, 2010 10:29 pm ]
Post subject:  Re: Low latency secondary input (microphone)

Quote:
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.
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.

Author:  Bojcha [ Tue Jan 05, 2010 10:34 pm ]
Post subject:  Re: Low latency secondary input (microphone)

Quote:
Quote:
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.
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.

Page 23 of 75 All times are UTC+02:00
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/