Stereo Tool https://forums.stereotool.com/ |
|
Stereo Tool 6.00 https://forums.stereotool.com/viewtopic.php?t=2811 |
Page 40 of 72 |
Author: | Bojcha [ Fri Jan 28, 2011 4:04 pm ] |
Post subject: | Re: Stereo Tool 6.00 |
Edorado What buffer size you can get ? |
Author: | hvz [ Fri Jan 28, 2011 4:48 pm ] |
Post subject: | Re: Stereo Tool 6.00 |
"REAL_TIME" priority in Windows is not real-time AT ALL. On the other hand, the ASIO thread is controlled by the sound card DRIVER, which can respond to sound card interrupts and hence be far more real-time. I'll ask some questions in an ASIO developer forum to see if there are any 'good' solutions. For now, this is what I see as possibilities: 1. Current implementation, and making sure that Windows does absolutely nothing else. 2. Perform all my processing inside the ASIO thread. The disadvantage is that the ASIO buffer size must then be set big enough for an entire block of processing to be handled. In itself that doesn't have to be a problem, BUT since the ASIO buffer size must usually also be a power of 2, I'll probably loose a few ms there. (Say my processing costs, in samples, the duration of 260 samples. Then I would have to set the ASIO buffer size to 512... Right now it could be 64, and I would loose only 60 samples - that would then suddenly be 252 samples...). Someone reported that BA didn't work well on lower ASIO latency settings, that might be explained by this... I hope someone who has more experience in ASIO application development can give a better solution. |
Author: | Bojcha [ Fri Jan 28, 2011 4:57 pm ] |
Post subject: | Re: Stereo Tool 6.00 |
Quote: Someone reported that BA didn't work well on lower ASIO latency settings.....
That was me .. 48kHz can't work with under 64 samples and 192kHz can't work under 256 samples in BA asio.BA Asio config ![]() |
Author: | eldoradofm [ Fri Jan 28, 2011 7:04 pm ] |
Post subject: | Re: Stereo Tool 6.00 |
Quote: Edorado
In the previous topics i was talking about buffer sizes i could get with stereotool maximized. What buffer size you can get ? With stereotool minimized and virusscanner disabled i can get to very low settings. Now testing with 1,5 ms @192 KHz. No clicks so far when i don't do anything else with the computer. It's quite different with stereotool maximized. It's now also almost completely running on one core of the pc when i look at CPU usage. I'll do some more testing tomorrow. |
Author: | Bojcha [ Fri Jan 28, 2011 7:21 pm ] |
Post subject: | Re: Stereo Tool 6.00 |
Ok, good. It same like here. |
Author: | hvz [ Fri Jan 28, 2011 10:21 pm ] |
Post subject: | Re: Stereo Tool 6.00 |
Quote: Quote: Edorado
In the previous topics i was talking about buffer sizes i could get with stereotool maximized. What buffer size you can get ? With stereotool minimized and virusscanner disabled i can get to very low settings. Now testing with 1,5 ms @192 KHz. No clicks so far when i don't do anything else with the computer. It's quite different with stereotool maximized. It's now also almost completely running on one core of the pc when i look at CPU usage. I'll do some more testing tomorrow. |
Author: | Bojcha [ Fri Jan 28, 2011 10:41 pm ] |
Post subject: | Re: Stereo Tool 6.00 |
Quote: If you set the priority of Stereo Tool to REALTIME, you do the same with the window update thread! So I think the first thing I need to do is increasing the priority of the processing thread, but not of anything else.
That will probably be good!When Ba Asio is running, there are 2 processes. I guess one is for procesing only, and other one is for window/skin/buttnons/meters/scope/etc Only first one 'eat" cpu. |
Author: | hvz [ Sat Jan 29, 2011 12:41 am ] |
Post subject: | Re: Stereo Tool 6.00 |
Ah, here it is: There are 2 levels of priority: - Process level. This is what you can see in Task Manager. All _threads_ within a process get a priority between 0 and 15, except at setting REALTIME, then the threads get a priority between 16 and 31. - Thread level. I need to set the processing thread to TIME_CRITICAL. Combined, this gives a processing thread priority of 31 - enough to stop even mouse movements and keyboard input during processing. I'm not sure if that's good though, because this way it might be that the ASIO input/output thread itself gets stopped by my extremely high priority thread... I'm now building a version where you can choose between 3 priorities: - Normal - High (thread priority increased to TIME_CRITICAL) - Extreme (High, plus process priority class changed to REALTIME). I've tried to check the thread and process priority myself during ASIO driver calls, but I just get Normal/Normal, which seems very unlikely (_anything_ running at a normal priority could then disrupt it). If this is true though, both increased settings would cause a mess at single core systems. |
Author: | hvz [ Sat Jan 29, 2011 1:14 am ] |
Post subject: | Re: Stereo Tool 6.00 |
BETA601-027: - Added priority settings to stand alone version NO CHANGES TO ANYTHING ELSE! Note: I expect this new version to solve the clicking issues of the previous BETA's on multicore systems. I'm not sure what happens on a single core system though - the processing thread priority might be so high that it blocks the ASIO driver itself... (Especially at 'real-time' priority). Winamp DSP plugin: http://www.stereotool.com/download/dsp_ ... 01-027.exe Stand alone version: http://www.stereotool.com/download/ster ... 01-027.exe VST version: http://www.stereotool.com/download/vst_ ... 01-027.dll VST version (No SSE2): http://www.stereotool.com/download/vst_ ... 01-027.dll Command line version: http://www.stereotool.com/download/ster ... 01-027.exe Linux command line version: http://www.stereotool.com/download/ster ... ETA601-027 [not available] Linux GUI version: http://www.stereotool.com/download/ster ... ETA601-027 [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!" Seems gone now (601-BETA028) - ASIO latency: Add configurable ASIO granularity - ASIO latency: Add active output push instead of reactive. - No longer needed - I think. Data is now sent to output BEFORE processing. And there's always some processing delay. Might become more interesting when CPU load goes down. - ASIO latency: Make option to increase ST priority. BUSY - Fix BYPASS mode in stand alone version DONE (601-BETA028) - Fix 4096 in stand alone version - DONE (601-BETA028) - Change ASIO latency interface (lower values, more fine-grained; display actual latency after rounding) 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. |
Author: | eldoradofm [ Sat Jan 29, 2011 1:30 am ] |
Post subject: | Re: Stereo Tool 6.00 |
I'm trying version 27 now. I can't see changes in priority in windows task bar when i select different settings. Is this correct? |
Page 40 of 72 | All times are UTC+02:00 |
Powered by phpBB® Forum Software © phpBB Limited https://www.phpbb.com/ |