AMD X2 DualCore 5600+ and juli@ are happy now
512 mode - 192kHz - FM Output - MinBufferSize 2.7 (good at 4,1ms)
Must be at RealTime priority. MultiCore do not make much difference, I think CPU load is bit higher.
| Stereo Tool https://forums.stereotool.com/ |
|
| Stereo Tool 6.00 https://forums.stereotool.com/viewtopic.php?t=2811 |
Page 66 of 72 |
| Author: | Bojcha [ Fri Feb 04, 2011 3:46 pm ] |
| Post subject: | Re: Stereo Tool 6.00 |
AMD X2 DualCore 5600+ and juli@ are happy now 512 mode - 192kHz - FM Output - MinBufferSize 2.7 (good at 4,1ms) Must be at RealTime priority. MultiCore do not make much difference, I think CPU load is bit higher. |
|
| Author: | hvz [ Sat Feb 05, 2011 3:00 am ] |
| Post subject: | Re: Stereo Tool 6.00 |
BETA601-033: - Buffer sizes now rounded up to whole ASIO grain blocks - in-between settings are useless because the clicks might get less but won't disappear - ASIO actual buffer sizes now displayed in ms and samples - Priority behavior changed: * Normal mode unchanged * Realtime mode: If single core processing is used, the single processing thread is now set to priority 26 (was: 25), for 2 threads the first thread is set to 25 and the FM composite limiter thread to 26, as before. GUI thread at 22. * Higher mode: Priority of processing thread now set to 14 (single core) or 13 (main processing thread) and 14 (FM composite limiter thread); Automatic priority boost turned OFF now! So threads will stay at these priorities. GUI thread is set to 12. I don't expect any changes for Normal and Realtime mode, but Higher mode might work better than before. Winamp DSP plugin: http://www.stereotool.com/download/dsp_ ... 01-033.exe Stand alone version: http://www.stereotool.com/download/ster ... 01-033.exe VST version: http://www.stereotool.com/download/vst_ ... 01-033.dll VST version (No SSE2): http://www.stereotool.com/download/vst_ ... 01-033.dll Command line version: http://www.stereotool.com/download/ster ... 01-033.exe Linux command line version: http://www.stereotool.com/download/ster ... ETA601-033 [not available] Linux GUI version: http://www.stereotool.com/download/ster ... ETA601-033 [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. - Fix BYPASS mode in stand alone version DONE - Fix 4096 in stand alone version - 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. DONE - Check ASIO on single core behavior... DONE, option available - Change ASIO latency interface (lower values, more fine-grained; display actual latency after rounding) - 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? - WAIT FOR FEEDBACK - 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. - WAIT FOR FEEDBACK - Make this level depend on the input level (gives less artifacts when not needed) DONE - Set Steepness a bit higher than before because there are far less artifacts. DONE - Bojcha: "There is strange "tone" at LEFT channel (tested ST dsp), caused by Bass Boost, but not always!" - Seems gone now - DONE - Something is wrong with ASIO if there's only one channel instead of 2. - Bypass is not good again - phoenix: Direct sound at any buffer doesnot work unless MultiCore is ENABLED! FIXED - phoenix: "Change of Thread Priority: Now this really needs working. I'll try to make you understand the pattern that I'm observing. Normal and High donot work. Only REALTIME works depending upon whether ST is run using elevated privileges or not. So if I run ST as Admin, it changes to REALTIME in Win 7/Win Vista, else it sets it to HIGH. Now clicking on Normal or High puts it back to the priority at which ST was running just before setting it to REALTIME. So if it was set to Above Normal(using task manager), it reverts to that when clicked on Normal or High from ST Sound Confg Window." - BEHAVIOR UPDATED - bojcha: When i change Soundcards samples it should ask me to restart program or somehow to deal with it. Currently it hangs. Moving buffer size or bypass ON/OFF, resolves it. - REPORTED TO BE OK NOW - phoenix: ASIO sound disappears on enabling multicore. - SOLVED - Allow setting Realtime priority on Vista (if possible, Admin rights?) - NOT POSSIBLE - Change buffer size configuration to match whole ASIO grains (probably only displaying them) - DONE - bojcha: I notice when Opening and starting program is a bit slower, minimizing to tray slower too. but it's ok. - Reported OK now. - Hangups during closing of stand alone version. (hThread) Solved??? - NOT SEEN BY OTHERS - Real-time priority +6/+5 possible instead of ABOVE_NORMAL and HIGH? - Fix different priority settings - BUSY, waiting for feedback... - 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. Another step is possible to reduce them further (probably 50% more) - DONE, FAR less artifacts now. Questions: * Multiband: Question: Is Steepness behavior ok? - AS GOOD AS POSSIBLE NOW, AND CAN BE TURNED OFF. * 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? 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. - Use double overlap (allow quality levels > 100%) to strongly reduce artifacts - Introduce extra latency between 512 and 1024 by upsampling or downsampling |
|
| Author: | Bojcha [ Sat Feb 05, 2011 4:17 am ] |
| Post subject: | Re: Stereo Tool 6.00 |
Quote: - I notice when Opening and starting program is a bit slower, minimizing to tray slower too. but it's ok. It's good now.Quote: - Hangups during closing of stand alone version. (hThread) Solved??? Ok here. For now always closed without hangup.Quote: - Fix different priority settings - BUSY, waiting for feedback... OK here, but i need to check on slower AMD PC new priority setup.btw, this with buffer size is nice. |
|
| Author: | Bojcha [ Sat Feb 05, 2011 4:21 am ] |
| Post subject: | Re: Stereo Tool 6.00 |
Quote: btw, this with buffer size is nice. Is it possible to automticly detect minimum, but working, buffer size at ST startup, when ASIO is used?If yes, maybe good idea for some future release. |
|
| Author: | hvz [ Sat Feb 05, 2011 4:23 am ] |
| Post subject: | Re: Stereo Tool 6.00 |
Here are some remaining open questions: Phoenix About AMD patches: I've tried what would happen if I replace the search for 'GenuineIntel' on my pc by 'GanuineIntel', so it would fail (basically I opened the executable file and changed every occurrence of 'Genu' that I could fine). I cannot measure any difference in performance! Could you measure a performance difference in your case (ie. lower CPU load or something like that?) Bojcha About Loudness Punch (all latencies, so also 4096): I added protection against loud bass sounds in the Loudness punch. Basically, if there is NOT much loud bass, I could increase the Loudness functionality again because there won't be artifacts anyway. You were saying elsewhere that maybe I should do _more_ to the bass and maybe less to higher frequencies - if that's the case then this change wouldn't be good at all, and increasing the Punch slider a bit would be much better... |
|
| Author: | hvz [ Sat Feb 05, 2011 4:27 am ] |
| Post subject: | Re: Stereo Tool 6.00 |
@Bojcha - thanks, will update my todo list! Quote: Is it possible to automticly detect minimum, but working, buffer size at ST startup, when ASIO is used?
I guess that should be possible. Although it might take a few seconds to determine it - I could also add an 'auto determine' button.If yes, maybe good idea for some future release. But actually, for the next release I'm planning to reduce the latency slightly more (1 ASIO grain, so usually a bit more than 1 ms); after doing that automatically determining the minimum won't be possible anymore... |
|
| Author: | phoenix [ Sat Feb 05, 2011 8:04 am ] |
| Post subject: | Re: Stereo Tool 6.00 |
Woke up to a nice, lovely weekend noon!  2 new betas in repository, yaaahooo!!! BTW, the effect of this whole AMD-Intel lawsuit can be seen in Intel C++ Studio XE 2011 where the dispatcher has been done away with. Quote: Phoenix
I'll explain the patching part, but Hans, I also intend to know from you that to what extent SSE2 can augment the performance in a modern Intel or AMD Quad core processor based system wrt StereoTool(which computes several floating point ops per second)? The performance incentive that I witnessed was on a 2core VM running on my Phenom II X4 965BE. The actual machine didnot show any noticeable performance change. So someone who has a relatively old AMD dual core(or may be single core) CPU is a good candidate for testing the patched version. Prior patching beta31D, the buffer in VM needed to be at 20ms for absolute glitch-free sound. Now I could put it to 5.2ms(infact I disabled Superfetch service and got it to 5.0) and ASIO4ALL at 128 samples. I'm yet to test the betas post 31D and from the reviews I gather that there are improvements. Will let you know how these perform on the afore said setup. Other than that I cannot comment anything conclusive about 'Performance Increment'.About AMD patches: I've tried what would happen if I replace the search for 'GenuineIntel' on my pc by 'GanuineIntel', so it would fail (basically I opened the executable file and changed every occurrence of 'Genu' that I could fine). I cannot measure any difference in performance! Could you measure a performance difference in your case (ie. lower CPU load or something like that?) Now the patching part: There are 2 approaches: i. Make the vendor string change to vendor string of AMD, provided the string size matches and it actually corresponds to vendor string of target CPU. Because Ideally changing it to 'GanuineIntel' would make the dispatcher take Generic IA-32 path on any machine(which is why I raised question about SSE2 showing effect as you said you cannot measure any changes on your QuadCore Intel). So as per 1st approach for AMD systems, 'GenuineIntel' translates to 'AuthenticAMD'. Which also means that truncated strings translate as: 'Genu' -> 'Auth', 'ineI' -> 'enti' and 'ntel' -> 'cAMD' in the entire file. In Stereo Tool there are 6 such instances. In 'TapeRestoreLive' there were 2(if I remember correct). ii. Make the compare instruction test to 'True' so that 'intel bit' gets the value 1. This is what the dispatcher looks like: Quote: mov eax, [ebp][-0008]
The binary file is scanned for compare instructions like 81 fa 47 65 6e 75 (cmp edx, 0756E6547), the latter being replaced by commands like cmp eax, 0756E6547 ;"uneG" ; Checking on "Genu" jne not_intel ; if it doesn’t equal, switching for not_intel mov eax, [ebp][-0010] cmp eax, 049656E69 ;"Ieni" ; Checking on "ineI" jne not_intel ; doesn’t equal - not_intel mov eax, [ebp][-0014] cmp eax, 06C65746E ;"letn" ; Checking on "ntel" jne not_intel ; doesn’t equal - not_intel mov edx, 000000001 ; the intel byte jmps next not_intel: xor edx, edx ; and here we have 0 for all non-Intel CPUs next: testl edx, 000000000 (f7 c2 00 00 00 00) which will always evaluate to 'True' no matter what the Vendor string is. Similar checks on EAX, EBX, ECX, EBP, ESI, EDI, and [EBP]. So to be double sure, if you release a beta version compiler with the option /Qx:SSE2 only(no /arch:SSE2), then it would run only on Intel compilers supporting SSE2 instruction set and would throw an error or just won't run on AMD. but if you patch using either of the 2 methods, then the same binar would run on AMD systems. This is sure-shot check that the executable is leveraging the SSE2 instruction set. Let me know your thoughts. 
|
|
| Author: | phoenix [ Sat Feb 05, 2011 9:29 am ] |
| Post subject: | Re: Stereo Tool 6.00 |
@Bojcha: Sorry I inadvertantly skipped a question of yours in a previous post concering the low latency Preset...the preset sounds good on most modern tracks. It's only in vintage tracks or some soft rock tracks that obvious lack of punch is felt. Sounds far better in 4096 latency mode. Examples: Father Figure(George Michael), Sailing (Christopher Cross) , umh..what else....Only You (Informers OST) @Hans, At 4096 latency mode, I am pretty much content with the default punch behaviour (0.225 / 0.75). So, no cribbing from me. Rest is at your discretion to retain it or replace it with something new(hopefully better). |
|
| Author: | phoenix [ Sat Feb 05, 2011 9:32 am ] |
| Post subject: | Re: Stereo Tool 6.00 |
This is to solemnly declare that I love Stereo Tool to the truest of my conscience! Couldn't think of anything else to scribble for my centenary post without being in the same league as those spammers..
|
|
| Author: | Bojcha [ Sat Feb 05, 2011 2:59 pm ] |
| Post subject: | Re: Stereo Tool 6.00 |
Tested beta33. AMD DualCore 5600+ and Juli@ 192kHz 256samples@soundcard / FM Out / Composite ON / Transmitter Calibration ON / Loudness, Strict clip,... ON / 4096 mode! Buffer size 24ms (4068samples) -- 192kHz 256samples@soundcard / FM Out / Composite ON / Transmitter Calibration ON / Loudness, Strict clip,... ON / 512 mode! Buffer size 4ms (768samples), 2,7ms (512samples) - Multicore helps a bit and when buffer is full. - High Priority seem better now, but Realtime is better. - Buffer is not full always after program start or "restart button" - High/Realtime Priority and/or Multicore helps for DS too! |
|
| Page 66 of 72 | All times are UTC+02:00 |
| Powered by phpBB® Forum Software © phpBB Limited https://www.phpbb.com/ |
|