Stereo Tool

Ah. That should turned off on Linux (everything uses Jack anyway - not sure though if that really means that it's not needed...) but on on Windows - I guess I did something wrong there.

Oh oh, I've noticed some clicks on the transmission when listening to some quieter music, just as you've said they're there, Hans. To me, they happen sporadically, and they're on the left or right channel, but not on both channels at the same time.

And I can barely run a full fm-processing-preset (without composite clipper) beside the USRP-rendering on the Core2Duo-notebook. An i7 is absolutely needed for full ST-processing and USRP-rendering on one machine

The current version is built with GCC instead of the Intel compiler that I expect to give better performance. Also, at the moment all versions are 32 bits, I expect an interesting increase in performance (probably at least 20%, possibly more) when moving to 64 bits. Also in the current version the processing thread isn't put on high priority as it should be (still Windows-specific code, ALMOST all Windows code is made generic now but that part still needs to be done. Coming soon.).

Before I move to 64 bits I really want to get this version stable. And release it (both Windows and Linux).


Oddly, I heard clicks on both channels simultaneously...

That would also seem to be an ideal time to ensure that you are able to build with the latest compiler and IPP libraries.

Do you agree?

I will definitely compare the 64 bit performance of the two.

Still the "does not anything, does not receive any audio" problem.

@AlexL: Could you try another Jack-based program to make sure that that does receive audio? Also, in earlier versions, the program printed dots in the console window from which it was started each time a block of audio arrived - did you ever see those?

TODO list:
- RadioFreak: Hiccups - were not caused by Stereo Tool
- Linux: Clicks with Jack (First thing to check: Other latency settings.) Seems to only affect FM output. First test: Replace input by sine wave. And wav2.wav.
- Linux: Jack maximum buffer size smaller OR allocate more buffer space -> Make static!
- Linux: Quit in Linux (hang on close)
- RadioFreak: Crash after restart, gone after deleting .rc file.
- Linux: Jack latency settings (buffer size) don't seem to work in all cases. -> Normal and Low Latency were swapped
- Linux: Probably remove priority parameters in Linux
- Linux: Priority setting in Linux
- Windows: Synchronize doesn't work in Windows Fixed, buffer filling was returned as value between 0 and 2, but now as between 0 and 1. So the correction was calculated incorrectly. Bojcha reports it still doesn't work.
- Windows: Channel swapping in Windows So far unable to reproduce, will run a new release build using latest code.
- Linux: Jack no sound (AlexL) Logging (".") added -> Is displayed, but still no audio; other Jack programs are ok.
- Linux: Entering registration key in Linux
- Linux: Unresponsive GUI with dropdown menu's open
- All: Low latency sound sometimes bad (VERY bad)
- RadioFreak: when you save your actual setting to a preset (export) and then open this preset again (import), ST crashes sometimes
- Bojcha: If possible to add on list fix for MB compressors meters (and might possible audio) interact wrongly with Burst compressors AND limiters.

I've experienced some more issues with the latest linux-beta:
- when you save your actual setting to a preset (export) and then open this preset again (import), ST crashes sometimes
- after about 2 hours normal operation, the mpx-output gets lots of hiccups, and is unusable. I don't know if it has something to do with JACK and my other applications running at the same time, will check this

I also cant replicate channel swapping.. (whole evening)...

- If possible to add on list fix for MB compressors meters (and might possible audio) interact wrongly with Burst compressors AND limiters.