Stereo Tool

Hi,

Do you think a 6.20 realease is ok for october ?
We start a new radio the 26 of october.

if not we used the lastest beta of ST 6.20, it's very good job Hanz !
CONGRATULATIONS

Thanks Hvz !

When looking at the todo list for this beta version, you can safely use the latest beta version.
It looks like the most important things on it are done.
Only some bug fixes before release.

... and some cpu optimization (if possible)

...and to think, I wasn't the one that said it...

Is your Intel system starting to have issues? I have no doubt that your AMD has significant issues by now unless you cut back on the quality. Declipper is pretty much out of the question for K8-based AMDs...

O, did the CPU load go up in the last few weeks? I have to admit that I haven't checked that yet. Will do that soon.

I don't think there's much to be gained anymore though. (Although: Multi-threading in the declipper should help a lot. Clipper as well, but that's not possible for composite clipping which I want to implement soon).

On some dualCore AMDs i am starting to have problems. Can't use Full quality + De-Clipper. Not from last few weeks.. somewhere from first de-clipper. Even on Dual Core Intel i can't boost, for example, strictness more then 0 and to be safe. (fm mode)

For me no problem it is a Intel i5 2500K

ST use nearly 13-14% of CPU with declipper

32K data + 32K instruction L1 cache per core + 256K L2 cache per core + 6MB shared L3 cache on that processor, so, no, you won't see things as having a problem.

This application is very cache-sensitive. At this point, without reducing quality settings, it looks like 2MB cache per core is the minimum requirement. Access to 4MB+ (either L2 or shared L3) seems to be preferred.

Actually this whole cache thing doesn't make much sense anymore since I 'removed' Natural Dynamics. The only thing that uses a lot of memory is Multiband (because it separates the data into 10 bands per channel = 20 * 4096 floats = 320 kB, plus extra buffers for other data which might mean a doubling of this number).

The declipper and clipper however do things with very little memory (one channel at once, and only a few buffers = a few times 4096 floats = a few times 16 kB).

I'm actually starting to wonder if it could be something else. For example:
- Code cache vs. data cache.
- Cache lines issue (for example, 64 kB multiples of addresses cannot be in the cache simultaneously. This can give HUGE performance effects.)

Could someone who has cache problems do the following tests?
1. Try what happens if you turn Multiband off.
2. Try what happens if you lower the latency by one step (or multiple steps). Each step causes a reduction of memory usage by half! (The memory will stay allocated, but it's no longer used, hence no longer placed in the cache).

If lowering the latency does NOT help, the issue is probably code cache instead of data cache. If it's that I can try building a version that's more optimized for size than for performance.

Actually the first time that I checked this in ST.
Wouldn't it be better to split these kind of settings up in a different window?
As far as I am concerned these settings should only be altered once and that is when you setup your station.
PI code well yes 16 bit but it is more than just a bit of code. I would concider to seperate it in country, regional/supra regional.... , and then the 'station code' (1 to 254)
Guys, you must set this correct or it might show up that you are broadcasting in another country etc.