Stereo Tool

This VST version works fine on my end:
http://www.stereotool.com/download/vst_ ... 3-053A.dll

Im thinking something.. it might be good to add some Meter for "Simple Clipper" (to measure it's output). It can be really good to know loudness input.. (-x to +6dB)

FM synchronization is a great feature. I have a use for that where some small remote fm sites are currently fed via an RTP multicast AAC stream using Winamp as the site player, and I have the issue you described Hans. At the extremes I've observed, one site 'playing slow' can fill its buffer by an additional ~ 0.2-0.5 seconds an hour, so over one week can be 30-40 seconds behind. Yet another FM site on the same feed 'playing fast' may get an hourly gap of 0.3 seconds as the player is slowly starved of data.

As Greg from Orban says; "the man with two clocks doesn't know what time it is” syndrome.

Using this new feature, what does "Relative adjust" do? Does the FM Buffer Size need to be a certain minimum size for correct operation and can we safely turn off turbo in order to always observe a 0.1% Max Speed Adjustment setting?

With a 2sec buffer setting, the FM buffer meter behavior jumps from ~0.25 full to 0.75 full every five seconds or so, is that what we should be seeing? Cheers AJ

Bloat happens because things are pushed back, and pushed back, and pushed back, until they are forgotten about / accepted as normal. Sooner or later, you're going to hit a 2MB wall, which I then figure you'll have to deal with more hurridly.

Yes, 1 core. What I see is, well, the CPU load spikes up , I get a grayish window, then it sorta trays, then it redraws and continues to display for the remainder of the track. The only way I get usability back is to click the tray icon and bring it back up. Maybe I should also mention I have not yet seen this happen when CPU load is lower, like with my work with Purity Control. It only happens with my work with Cobalt, and thus a high CPU load.
99%+ of my files are MP3
If it is "user error", it is CPU LOAD INDUCED USER ERROR!

The problem here is that even if you reduce to 1 core, you still have at least 2MB cache available to that core, where as I only have 1MB.

You need a proper testbed. Due to not having a proper testbed, it'd be great if you could find the time to reduce the extra steps in the various filters.

Bass Boost may have been ok. I may have turned it off the last time the preset was loaded and hadn't remembered that I had turned it off, because I haven't seen further issues with that and other presets.

So that, yes, user error.

There is no way, however, that I would've attempted to load a text file in winamp and attempt to play it, without the CPU load causing lag in where and what I was clicking.

All the filters share the same memory, and these unnecessary steps use the same block of memory every time - in total 64 kB. I wouldn't call that a 'bloat'. For Multiband I've tried removing it in the past, the CPU load didn't change at all, probably because these steps have advantages on some things as well. And within a few weeks it should be completely removed for input downsampling and declipper (both are already converted), clipper, hard limit and output upsampling (still to be done). I want to start with a new multiband compressor soon (which will have less bands and hence use far less memory), and that will also be set up without this. So this extra steps issue will get reduced over time - and pretty rapidly too.

Very well possible. I'm just saying that this happening due to a bug in Stereo Tool or even Winamp isn't possible (the only thing that I do in Stereo Tool with an STS file is open it, read the contents and close it again, and store the name in the STS file in the list of recent files. The only way it could end up in Winamp is if I overwrite a memory position in Winamp where the file names of the playlist are stored, or if Winamp copies data from the Stereo Tool memory and happens to pick an STS file name out of the dozens of MB's that Stereo Tool has in use. You are a programmer, so you know that the chance that this happens is insanely small.

The buffer size must be big enough to handle all hiccups due to packet loss etc in the signal. So if latency is not an issue I would set it at the maximum.
Relative adjust: At first you need to set the buffer size the same at all sites. There may still be small differences in latency though due to a different connection path, different hardware (a.o. CPU load affects the latency, because with the jumps that you see it affects the average measured sound card buffer filling); if you would try to adjust that by changing the buffer size the playback restarts every time. If instead you use this relative adjust it has the same effect but without restarting playback, and Turbo is enabled when you change it. Turning Turbo off is possible, it may take longer to reach synchronization when you connect to the stream though. If you set the Max Speed Adjustment to 0.1% anyway I don't see any reason to turn Turbo off... (It goes off automatically as soon as it reaches sync - and doesn't get turned on again unless no data is received for over 10 seconds).
See that here as well, I don't know what's causing it. Fortunately I'm averaging the measured delay over more than 1000 measurements - and using something median-like calculation...

This goes back to the lack of a testbed. The systems you're testing on are far less constrained.
When the preset list hang issue happens, when I hover over Winamp as a toolbar docked at the top of my screen, my cursor changes from the standard Windows cursor to your custom cursor for your DLL. Anywhere else on the screen, other than your GUI and Winamp, I have the normal cursor. Your GUI and Winamp, your cursor. Interaction between the two are probably more common than you think.

I've repeatedly told you that the issues I've reported just don't happen under more reasonable CPU load conditions. I don't feel like arguing. You don't have a testbed to match, and if you don't want to take my word for this, so be it. I'm not going to lie about when things happen to make you happier. They happen when they happen, and they happen under heavy CPU load. If you want to put off addressing it, well, hopefully it won't get worse and impact 2MB cache systems, because there are far more of those out there. Although, I guess from my perspective, maybe that's what is needed?

Because the new multiband cost you less bands ? although 10 bands are difficult to configure the sound you get is great. It would be better the user defined the bands that need

@Brian: Unresponsive GUI issue confirmed. I lowered my laptop speed to 30% of the normal speed and allowed both Winanp and Stereo Tool to use only one of the 8 cores. I then clicked on the presets pull-down menu and everything was completely unresponsive. Even after the track finished playing the CPU load of that core remained at 100%. Then when I increased the speed it immediately came back.

I think what happens is that more GUI update events are being fired than the processor can handle (every 2048 samples a GUI update is requested). Will check how to reduce this without doing less redraws when the CPU *can* handle it - keeping a counter of unhandled repaint request might be a solution.

Edit: Yes confirmed. If I increase the CPU speed while music is still playing the CPU load stays 100% for a while, then suddenly all the requests that still needed to be handled are executed.


So far unable to reproduce the send-to-tray issue.