Stereo Tool

Hi all,

I'm not sure if this one is a bug on side of Stereo Tool or Windows.

We're using SAM Broadcaster and Stereo Tool as DSP plugin on Windows Server 2008 (productive system) without any problems. There are running two instances of SAM/Stereo Tool on the same machine.

Just now we are testing the same configuration on Windows Server 2012. Basically it all runs very stable and high performant. But if we activate Stereo Tools on both SAM instances, we're running into troubles - indistinguishable on the Windows System itself. Please let me say that everything runs fine (with two SAM instances) as long as we not start Stereo Tool DSP in the second SAM instance.

Some players are interrupting playback on and on (short re-bufferings I think), some players working still without any problems. For example, iTunes is buffering - TuneIn mobile app doesn't. As I mentioned already above there are no visible signs on the Windows System for this issue. CPU, RAM, network bandwidth - everything is absolutely fine (CPU 22%, RAM 2GB, outgoing network bandwidth usage below 1Mbit).

I assume a problem with the realtime handling of Win Server 2012. What we've already tried was to set the task priority of both SAM instances to "Realtime" but without any success...

System information:
Intel Xeon E3-1230 V2, 3.30GHz / 16GB RAM
Windows Server 2012 R2
SAM Broadcaster 2013.6
Stereo Tool 7.31

Thank you in advance for any feedback/hints

Regards,
Reto

We also tested under Windows Server 2012 (not R2) - same result :-/

It probably has little effect, but upgrade to version 7.40 of Stereo Tool - it uses less CPU.

Can you check what happens if you lower the latency of Stereo Tool to 512? You should not do that for a stream (it reduces the audio quality) but I want to know if it solves anything. If it does, we might know what to look for.

(Why: Stereo Tool processes blocks of audio, which means that every time when - at standard latency of 4096 - 2048 samples have arrived, Stereo Tool starts to process them and does not send any samples through for a very brief period. It could be that this period is too long and causes SAM or the encoder to do weird things. By lowering the latency to 512 the time of blocking is reduced by a factor 16.)

I tested it also with 7.40 now - still with the same issue. I will check the lower latency asap. If you are right, then the gaps are getting more in shorter spaces (or no more gaps), right?

Yes. I would expect no more gaps.

Anyway, if you run 2 ST instances they are unaware of each other, and the only effect they should have on each other is a difference in CPU load... So I think it *must* have something to do with that.

Something else you could try (save your settings first) is to do a RESET of all the audio processing settings and see if the problem disappears. That would definitely confirm that it's CPU load related.

Just to add something that is a "no no" in our network; our IT people will never run audio software on Windows Server software. They say the priorities in Server software are not for processing audio. I could get more details if needed but I know that none of our network's RCS NextGen or Zetta automation systems are on Windows Server software because of it.

Indeed reducing latency has lead to success! Setting latency to 2048 is already enough to get the gaps fixed...

Then I'm guessing that you indeed need to change some buffer sizes somewhere (probably in the encoders) to fix this. And I think Clipper is right...

I know Windows Server is not the best choice for realtime applications but our datacenter does not offer other Windows Editions at all. We tested it all successfully on Server 2008 so we'll stay at 2008 for the moment.

Thank you guys!

Nearly 2 years later I took another approach testing our configuration on a Windows 2012 R2 server. Unfortunately the problem is still the same - the stream is often buffering.

I was able to solve the problem by reducing "Quality (CPU load)" to 70% (latency = 4096 samples). But considering the fact, that the CPU load reaches max. 15% this can't be the real solution in my opinion.

Does anybody facing similar problems with Windows Server 2012?

System information:
Intel Xeon E3-1231 v3, 3.40GHz / 32GB RAM
Windows Server 2012 R2
2x SAM Broadcaster 2015.2
2x Stereo Tool 7.73