success story with 4.0.42.240

Just had a successful session !!! - didn’t lose sync over several hours (PC studio / Mac performer) - audio only, no midi.

the cycle record mode worked beautifully :smiley:

no trying to gloat - just letting people know it is possible to get it to work.

Cool! Slightly off topic, I have 4.0.41.215 on my Cubase machine, the performer has 4.0.40 stable version VST Connect Performer, Last night we did a 2.5 hour session with one glitch. When that happened, I asked if she had her email program running, and it turned out she did, plus and several other online apps going. She quit those apps and from then on we were glitch free.

What’s totally dis-intuitive is that the internet connection in her home, which is provided by her owners association (a large 100 apartment building) would not achieve a stable sync via wifi nor via Ethernet cable, but when she connected to a commercial wifi hotspot (here in the USA, Comcast subscribers get access to these) the connection synced great. I had Remote Delay set to 1.5 and Video upstream at the lowest, 64kB/sec

I had remote delay on 1.5 too - saw some odd things with the buffer level but that’s another story

there is something very (very) fussy about the network - it would be good to pin down exactly what that is…

Networking is voodoo stuff, very difficult to discuss cogently unless one has a lot of specialized knowledge (which I don’t). We really can only talk about the quality of the connection, a thing apart from its speed.

I don’t buy the “quality” thing…(as somebody who works with very high powered networks 9/5

do they mean out of order packets - latency - dropped packets - speed. What is the “quality” that is at fault

they used to provide some very rudimentary tools in VSTconn - now missing. But if you monitor the network yourself there isn’t a problem with it - you still get sync errors. It might be that these sync errors are actually ASIO buffer issues - cpu overloads…who knows ? But it something that needs attention IMO

I’m not sure I understand, are you a network engineer, or you mean you do your work over high powered networks?

I just mean to use the word ‘quality’ to differentiate from speed, for lay-people, which as far as networking goes, I am one.

In my experience I’ve connected over networks that test fast, but aren’t stable, and with the same performer connected to another network that tests at the same speed, we get a stable sync.

I manage a bunch of network engineers (and it’s all voodoo to me too :smiley: ) And I’ve done test sessions with them too. These are guys who have miraculously got thousands of people working from home over VPN and PCoIP in the most amazing way - this is realtime and latency intolerant - try moving a mouse with 2 seconds of delay !- they’ve even squeezed nearly a 1000 in little over a gig of internet - with people working from very limited home broadband…so why can’t you do 1 compressed audio/video stream over that reliably ?

you can set the “delay” as high as 5 seconds - that’s a lot of buffering - probably more than netflix- even then I’ve done test sessions with people who can’t get stable sync for just a few seconds at a time. Yet the network monitoring shows no problem - in fact you CAN have other network transfers going on and it causes VST connect zero problems… there is something else going on here IMO - it’s not magic we just need to find out what. Simply saying “the network quality isn’t right” doesn’t help …again IMO.

And how did you work out the network “wasn’t stable” - or is it that vst conn didn’t sync ? I bet that network was stable enough to run 99% of other network stuff (including realtime - with a buffer)

Simply that VST Connect didn’t sync consistently on the first network, and it did on the second. I’m not competent to say anything about the whys or wherefores of it, nor do I know with what other network applications I could make a valid comparison.

So talking about quality seems to be a good enough way to describe it, since we can’t get more granular about it without using specialized jargon from the trade.

wasn’t intending to criticise your use of the term quality ! - I totally understand why people are saying quality - but there doesn’t seem to be an explanation of what this quality is ? (not asking you to provide one of course :slight_smile: )

why is it failing for some (many?) people - even on what I would describe as a high-quality network ? I’m not seeing these failures with other “real time” networking applications.

Basically what I want to know is what part of the “network quality” is important - as I mentioned I’m not convinced it’s just about dropped packets or bandwidth. I saw some odd things, even on the successful session today. The blue buffer indicators showed some odd behaviour - even though it didn’t lose sync.

It wouldn’t be the first time there had been a massive bug like this…just sayin’ :smiley:

hopefully we can pin it down and find out

FWIW the non-techy guitarist I was working with today thought the whole thing was amazing - and he’s been in the recording game a long long long time ! Just needs to work 99% of the time not 10%

Quality means that when Alice sends a packet to Bob, it does arrive “in time”. With Netflix etc, there is no problem because they can buffer 10 seconds or so (and even then you occasionally get the spinning wheel, right?), and when a packet doesn’t make it to the destination it is beeing re-requested until it arrives, even if that takes seconds.
You do accept all the poor quality, robo voice and dropouts etc with Skype, Zoom and the likes, and you have to accept long delays when communicating via phone/WhatsApp, but you want high quality with VST Connect.
That beeing said, “high quality network” isn’t easily acheivable and you can’t even claim that. You may have a good internet connection with your Internet Provider (IP), but even if the peer also has a good IP, there are still possibly many hops (servers which transfer your data to the next best other server) and packets may get lost along the way. VST Connect does its best to re-request lost packets within the given timeframe (namely, the “Remote Delay” setting), and it does great as long as the transmission path provides the goods.
There is more to it, and we are currently evaluating possible improvements, just give us a bit of time for concentrating on these quite complex issues.

totally understand - not tryingto rush you :slight_smile: it’s working better than it ever has IMO

You can set the “delay” to 5 seconds in VSTconn which should be plenty of time for resending packets ? Especially with a latency of 10 to 20 ms ?

iPerf shows zero packet loss on networks that I have had sync failures with vstconnect

anyway, appreciate all the effort you are putting in

yes, but 5 seconds is over the top I guess, more than 3 usually makes no sense.
Amd yes, with zero lost packets there should be no sync issues. However it still happens when internal timing goes wrong, mostly due to constrains on i/o latency (buffer size) and/or CPU, or other external problems (streaming/video conferencing etc running in parallel). As said, we are looking into this right now (and reply to the forum at the same time - Eastern).