Stereo Tool

BETA601-025:
- Version with (hopefully) improved ASIO performance in Stand Alone version (lower latency possible).
NO CHANGES TO ANYTHING ELSE!

Winamp DSP plugin: http://www.stereotool.com/download/dsp_ ... 01-025.exe
Stand alone version: http://www.stereotool.com/download/ster ... 01-025.exe
VST version: http://www.stereotool.com/download/vst_ ... 01-025.dll
VST version (No SSE2): http://www.stereotool.com/download/vst_ ... 01-025.dll
Command line version: http://www.stereotool.com/download/ster ... 01-025.exe
Linux command line version: http://www.stereotool.com/download/ster ... ETA601-025 [not available]
Linux GUI version: http://www.stereotool.com/download/ster ... ETA601-025 [not available]


What remains for 6.01:
- Multiband: Adjust band 3 (and others?) 'soft limit' behavior at very low latencies. Maybe: Also check clipping (also for band 3, might be re-enabled!). DONE! - 1 hour
- Multiband: Adjust extreme EQ settings before processing to avoid issues caused by steepness. - 1 hour
- Multiband: Add 'Enable' button for steepness. 1 hour
- Performance: Multiband steepness: Moving UP can be done inside current loop, no separate loop needed. Maybe down too. Currently Multiband is FAR more expensive than before. - DONE, solved in a different way. - 1 day
- MAYBE: Make Steepness smarter. That would much better preserve the audio, especially at very low latencies! How: Instead of setting all the levels at AT MOST the level of neighboring bands + a bit, combine adjacent bands, determine total output level, and then fix it such that this combined output level is approached more. (So one very low, one very high --> one a bit less low, one a bit less high instead of both low).
- Fix NOISE GATE behavior in VST plugin
- Fix 'red output bar' issue. DONE - 1 day?
- Fix Highpass filter for higher input frequencies.
- Dynamic audio processing window: I've tested this at latency 512, and there it helps. But I don't have a clue what the effect is on higher latencies. They might also sound better, but they could just as well sound worse. - 2 hours. Result: 512 and 1024 got better, 2048 and 4096 got worse. So only turned on for the first two.
- Dynamic audio processing window: CPU load is probably a lot higher (haven't measured it yet) due to the dynamic adjustment of the behavior. The dynamic code was originally intended to be executed only once when a latency was selected, and it's not optimized at all. Fixed, CPU load reduced, and for latency 2048 and 4096 there's no difference. - Optimize, 1 day
- Reduce downsampling frequency because currently very high frequencies (21-22 kHz @ 176.4 kHz input sampling rate) in the input can cause spikes even if Hard Limit is used. DONE - 1 hour
- Vibrations caused by Very deep bass distortion protection at latency 1024. Also (but far less noticeable) in higher latency modes. No issue at latency 512 because there it's turned off. - Fixed, turned it on for latency 512, and turned other bass filter OFF for 512 because it caused distortion.
- Check difference in behavior between 44.1 and 48 kHz input for multiband! This could potentially result in really big differences. - No
- Performance: Multiband: Remove sqrt(sqrt(cos())), pow(x, .75) etc. - too expensive, replace by lookup table. - NOT FOR NOW, would increase memory usage and hence risk more page faults, so it's not sure that this would improve the performance. - 2 hours
- Performance: Move chain variables to a single Struct DONE - 1 hour
- Latency: Attempt to reduce Composite Limiter sampling latency - there is no audio anywhere near the filter frequency, so a much shorter delay might still work very well - DONE, composite limiter latency is now 0.9 ms at latencies 512 and 1024 (~1.7-2 ms at higher latencies)! It can be reduced a step further (to 0.5 ms) if I allow a bit more distortion - don't know if that's useful.
- Chris: "I still hear diff on Bass and kick between Beta 16 vs Beta 08 on 2048 latency. I hear more bass and kick on Beta 08. Pls check!" - No longer true, apparently fixed in BETA020... (Which does not make sense at all, but anyway)
- And I need to check how much the performance is impacted by the latency improvements, in the case where no upsampling and downsampling is needed. This seems to be impacted way more than I expected (could also be Multiband steepness --> Not anymore, fixed). Ah, got part of it: 1% is steepness. Which leaves about 3% to be explained. Het is NIET de FM Hard Limit - ook al bereken ik daar nu meer van. Wellicht chain2 calls? - No, wrong again. Decreased Steepness grain match from every 4 to every 16 samples, extra CPU load is now only 2% - acceptable.
- Check/fix Bass Boost ringing reported by Bojcha for higher 'upto' frequencies. REDUCED it a bit, hope that suffices... Less steep filtering (ie. bigger difference between first 2 frequencies) helps.
- Attempt to set GAUSS back to 0 - gives MUCH better processing of most filters (no high frequency noise). BUT: Loudness effect in Bjork - It's Oh So Quiet - can that be resolved in another way? BUSY, 1 day?
- Frequencies between 60 and 75 Hz are not handled properly yet, and can still cause vibration effects at soft high frequencies in latency 512 mode. (But FAR less than in version 6.00). Fixing this will probably increase artifacts for bass in this frequency range.
- Bojcha: "There is strange "tone" at LEFT channel (tested ST dsp), caused by Bass Boost, but not always!"
- ASIO latency: Add configurable ASIO granularity
- ASIO latency: Add active output push instead of reactive.
- ASIO latency: Make option to increase ST priority.

Questions:
* Multiband: Question: Is Steepness behavior ok?
* Loudness: QUESTION: The changed Punch behavior, is that good or bad? Should I attempt to let Punch behave as it did in the past as much as possible, or not?

At latency 512, Steepness can now be set a bit higher than before because there are far less artifacts.


For 6.02:
- It's possible to send data to an audio buffer AFTER I've returned control to the driver if I call ASIOOutputReady() when I'm ready
- Add non-phase linear Multiband stage between AGC and incoming_copy_needed.

Bojcha, I just noticed your post about your latency measurements (somehow I missed it before!). Thanks!

I hope the new latency will be lower. Maybe there's also something else wrong (if you're using 6 ms, it should be 12 + 6 = 18 ms, not 23...).

Did you try versions 1.02 - 1.06
http://download.esi-audio.com/?w=esi&p=6&g=1&l=en

That's what i measure, but anyway tomorrow i'll check new beta. Curently i don't have Juli@ here.
Playing with Maya44 USB...

I noticed when changing from 25.9 ms, 0,1 ms highter it goes to 25.1 ms and then 0,1 ms higher to 26.1

Is there some way to measure the audio glitches for best settings?

I forgot one VERY important thing about ASIO!

Most softwares that uses asio have "settings button" for "current used ASIO card.
So In Traktor DJ this button looks like this:


In BA Asio looks like this:


This calls ASIO panel from current used/selected ASIO soundcard.
Trick is that ASIO settings are remembered per aplication!!
So, if i set for my MAYA44usb 2ms (lowest latency) from Traktor it will work like that. But if is start ST (standalone) my MAYA will work at 'normal" latency, witch is for my MAYA44usb is 6ms!

Don't get confused with Juli@! That's only card i found that does not have this ASIO panel. (so it cannot be called)

Ah, that's good to know (and it might explain the extra latency in your case).

I've added some logging to my ASIO driver to see what would happen.

My VMware ASIO driver only supports a latency of 256 samples...

Latency set to 512, buffer size to 1 ms.
- Block 1, 2, 3 of 256 samples: SILENCE
- Block 4+: AUDIO.
So that's 3*256 = 768 samples (17.4 ms) latency, which makes sense (512 is needed to get the data, and then a bit more to do the processing).

Latency set to 1024:
- Block 1-5 of 256 samples: SILENCE
- Block 6+: AUDIO
Total latency is 5*256 = 1280 samples (29.0 ms) latency - also makes sense.

2048: 1-9, 10+, 9*256 = 2304 (52.2 ms) - ok

At 4096 something strange happens: The latency suddenly jumps to over 7000 samples. I'll have to check that tomorrow.

With a lower granularity than 256 samples, a slightly lower latency should be possible.

Note: With BYPASS enabled, the latency is only one block of 256 samples, regardless of latency settings.

Note #2: I haven't yet tested the behavior when I change the settings, these measurements were done based on a saved setting, and then restarting Stereo Tool. There SHOULD be no difference if you change settings, but - like I said - I still need to test if that's really the case.

OOPS! I missed something...

If I'm writing data to block #4, IT WON'T START PLAYING BEFORE BLOCK 4 HAS ENDED. So in my example that's 6 ms later.

And that delay might be completely unnecessary (if so, fixing it will take some effort), because I could still have written data to it until it started to play.

Anyway, this issue becomes far less important if the 'grain' is lowered - 48 samples instead of 256 would solve it almost completely.

Bojcha: In your measurements, was the latency indeed set to 256 samples?

When i measure with Juli@, latency was at lowest 48 samples, witch should be 1ms for 48kHz. But all was good at 192kHz too, and that is 0.25ms. Strange and impossoble.

Hans, exception is thrown by MSVCRT for beta25. Working fine till beta24. Please have a look...

_________________
visit website

0.25 ms... That is indeed insanely low (though not impossible, back in the days of MS-DOS even lower latencies were very easy to achieve). Of course that was with only one program running, fully using the CPU.

But what I meant is this: I thought for a moment that you used this for your measurement. But I re-read your post and there you say you used the Juli@.

Note: I added (below the ASIO checkbox) the number of samples latency that is being used. So at least it's displayed now - selecting different settings should be added later. I'm really curious if this is indeed just 48 samples...

Also, I'm not certain if DirectWire doesn't cause any latency. Or maybe even the opposite. Safest way to measure it would be by manually connecting the (analog) output to the (analog) input... - maybe just one channel


I'll try to install the older Juli@ drivers here soon - that way I hope I can *FINALLY* do some checks myself again.