Stereo Tool

It has a number of features that are new:
- Multiple Stereo Tool instances can use it at the same time
- Inputs can be shared between Stereo Tool instances
- An ASIO device can be shared between instances
- Synchronization between sound cards is now part of the framework, before it was specifically built everywhere where it was needed (and not for Input 2 for example, which is why that was missing)
- Backup/adding is now also part of the framework, and no longer handled by Stereo Tool

And things that are planned:
- An output can be sent to multiple sound cards
- We want to use this in plugin versions as well, which will mean that Input 1 would be the plugin input, and Input 2 could be a real sound card. This will make it possible to talk over the audio with The BIMP for example, with Stereo Tool running inside your playout software.
- Giving some input sound cards a delay. This will make it possible to have low latency behavior from some inputs to some outputs even when using multiple sound cards.
- Adding more than 2 input sound cards
- Adding sound cards with more than 2 channels, especially useful for The BIMP.

Not everything is completely supported yet, but we'll add things if they are needed. Most importantly at this point, streaming input and output are not yet supported, and on Linux, Jack is not yet supported.

Vac1 input, vac2 output, 48kHz everything, no FM, 50-100ms buffer. Input Sync ON with relative adjust 0.10%
Is Input2 now in some sync with beta26? Anyway i put it on one transmitter site that has backup on input2, now i need to wait 2-3 hours..

_________________
control point
control point2

Ah, I see what you mean now. The moment when we check how full the buffer is must be different... so you see the buffer jump (that can happen with the normal version as well, but it often doesn't), and due to that the M value changes quickly as well. I'll check what's wrong.

Nope, still buffer overfill on input1 when input2 is enabled.

_________________
control point
control point2

hans i don't see aes67 input in STenterprise

Slightly, I suppose? If both input 1 and input 2 need to be synchronized, and one of the two lags behind a bit or they need an adjustment in opposite directions, you'll see (at most a few pixels) of one of the input buffers turn 'gray' (dotted). If it's more than that, it might be because your maximum resampling speed is too low.

Say you have 2 inputs, both set to 48 kHz, but one runs at 47999, the other at 48001. Then after 1 second, the first input will have produced 47999 samples, the 2nd 48001. Stereo Tool needs samples from both so it will consume 47999. So the 2nd input in this case will have an overflow of 2 samples. After 2 seconds that's 4 etc. Sync will start to compensate for that but a small part of the difference will remain. So one buffer will be "overfull" - but it should stabilize at some point, and the difference should be pretty small.

I see that it wasn't enabled in the release build, it is now so the next build will have it.

tnx

This is after 6 hours. Input and FM output goes asio (juli@), and input2 is VAC at 48kHz (tried 192, same). I also tried erlier without ASIO, but same thing occures.
So what i can do? I can change VAC clock, but i don't like that solution. Buffer overfill is so slow that some sync should anyway be capable to fix it.. idk.

Btw, on every PC i tested erlier, no metter what soundcard i use, always overfills input1 buffer. Never input2.

_________________
control point
control point2

Ok, this doesn't look right. The FM buffer is > 50% full which should force Input 1 to be speeding up. And Input 1 has too many samples in its buffer which should force it to speed up even more. But it is in fact slowing down (the M value is below 1)! So the issue will get worse over time.

Edit: I looked in the code and I cannot explain this yet. Can you give me a bit more info?
1. How big is your FM output buffer, and does it indeed appear to be > 50% full??
2. What are the M and x and resampling values for input 2, and do you see a similar effect there?

(3. For Input 1: Since it could be moving up and down: Does the M value stay below 1?)

I'll run a test here with similar values, to reproduce it on my end. That will make it much easier to find and fix.