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

New things...
https://forums.stereotool.com/viewtopic.php?t=4334		 Page 62 of 76
Author:  hvz [ Sat Dec 01, 2012 2:06 am ]
Post subject:  Re: New things...
This VST version works fine on my end:
http://www.stereotool.com/download/vst_ ... 3-053A.dll
Author:  Bojcha [ Sat Dec 01, 2012 2:16 am ]
Post subject:  Re: New things...
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)
Author:  Storm905 [ Sat Dec 01, 2012 3:06 am ]
Post subject:  Re: New things...
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
Author:  Brian [ Sat Dec 01, 2012 8:03 am ]
Post subject:  Re: New things...
Quote:
Quote:
The extra processing that you talked about just a couple of days ago when we were talking about the CPU load of "loudness", and you mentioned that AGC, Noise Gate, and MB had extra calculations that may not be needed...and that it was the sum total of everything that was pushing my system over the edge, not exclusively loudness.
Ah, that. I don't expect too much improvement from removing it, and it's too much work for now - however I'll make sure that everything I design from now on will take this into account. And I'm definitely converting Loudness (which is already nearly converted) and Hard Limit soon - because a big customer is requesting a new feature that requires me to change it. Those two happen to be some of the easiest ones to convert.
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.

Quote:
Quote:
As for where locks happen, it's really random, and it has to do with high CPU load. For example, not always, but from time to time, if I click the X to put the GUI to the tray, it will partially tray, meaning that the tray icon is there, but the GUI window remains "up", sort of, displaying normal GUI updates as the track progresses, but you can't actually do anything with the GUI. To get it working again, you have to click the tray icon to "really" bring it back up.
Cannot only be CPU load related, must be a real bug... (Once you click the X, the window updating should stop immediately). I'll try what happens if I run it on 1 core (you have 1 core right?) and check the code.
Yes, 1 core. What I see is, well, the :arrow: 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.
Quote:
Quote:
Another example is when changing presets while a track is playing. From time to time when I do that, the preset list will just get stuck and I can't click anything, including the stop button in Winamp! That situation does clear up when the track ends, but until the track ends, or you end task on Winamp, there's nothing you can do in ST or in Winamp.
Not always? Does this happen with specific file types? (I'm guessing .wav and .flac files, NOT .mp3 files)
99%+ of my files are MP3
Quote:
Quote:
I've also had an instance where Winamp claimed that the last track played was one of the STS files! That has only happened once, and it was after a high CPU load situation where I ended task on Winamp.
There's no way Windows can ever see an STS file unless you dragged it to or opened it in Winamp yourself. So I'll assume that this is a user error for now...
If it is "user error", it is CPU LOAD INDUCED USER ERROR! :evil:

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.
Author:  Brian [ Sat Dec 01, 2012 8:09 am ]
Post subject:  Re: New things...
Quote:
Quote:
Quote:
DSP version is good.
The beta turned off Bass Boost and Loudness by default, even though the preset I had loaded had them enabled. Might check that behavior. Still checking to see if there are other problems.
O you're right. I added a separate box to enable Loudness but forgot to add backward compatibility. :(
Bass boost is odd though - I didn't change anything there. But I'll check it.
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.
Author:  hvz [ Sat Dec 01, 2012 8:58 am ]
Post subject:  Re: New things...
Quote:
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.
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.

Quote:
If it is "user error", it is CPU LOAD INDUCED USER ERROR! :evil:
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.
Author:  hvz [ Sat Dec 01, 2012 9:12 am ]
Post subject:  Re: New things...
Quote:
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?
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).
Quote:
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
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...
Author:  Brian [ Sat Dec 01, 2012 10:49 am ]
Post subject:  Re: New things...
Quote:
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.
This goes back to the lack of a testbed. The systems you're testing on are far less constrained.
Quote:
Quote:
If it is "user error", it is CPU LOAD INDUCED USER ERROR! :evil:
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.
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?
Author:  nelson c [ Sat Dec 01, 2012 3:25 pm ]
Post subject:  Re: New things...
Because the new multiband cost you less bands :cry: ? although 10 bands are difficult to configure the sound you get is great. It would be better the user defined the bands that need
Author:  hvz [ Sat Dec 01, 2012 10:03 pm ]
Post subject:  Re: New things...
@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.
Page 62 of 76 All times are UTC+02:00
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/