Interesting System Link configuration

In all I’ve ever remember reading/understanding about VST System Link, it always has had the configuration/routing from one machine to the next, as in a ‘ring’ they say - this includes the System Link Data, as well as the audio - or so I thought. I know about the added latency with VSL data with each added machine in the network, and it’s supposed to make the system seem ‘sluggish’ etc, though claims ‘sample accuracy’. Assuming that audio usually (but not necessarily) was supposed to flow through the same cabling as VSL data, the audio within the system also has added latency. This makes perfect sense that the latency of the audio would at some point be very perceivable, but how many machines in the network will this begin to be very noticeable, I don’t know…?

Then I saw this article while researching…

It shows things a little different than I had for the most part understood. Instead of passing accumulated audio from one machine, then into the next, then next again etc along with VSL data in the same cable, adding more latency in the audio… this shows the audio going from each ‘slave’ machine (separate from VSL data) merging into ONE ‘master’ machine. This at least, appears that there would be less audio latency involved, merging separate feeds into one, than having the audio go ‘through’ everything in a daisy-chain. Thereby, whether you have 2 machines or 10 machines, the audio latency would be the same, and it’s only the VSL data that get’s accumulated latency, ie; reaction time etc… That’s how I understand it anyway.

All the above as opposed to this, where the audio & data are shared and accumulated…

Question is, in order to have all the audio feeds separate from the data feeds, all merging into one, rather than in/out/in/out of all machines, I’m thinking the link may be demonstrating ‘analog’ audio feeds instead of ‘digital’ audio?..unless there’s an interface capable of several s/pdif’s or adat etc. Even most newer interfaces I’ve seen have 1, 2 or as in RME, they have 3 s/pdif’s pairs of I/O in their Digi-face.
4 x ADAT
2 x TDIF (optional)
Is this enough?

Or if it’s not enough…maybe TWO of those could be installed in a computer :smiley:

Which brings to mind, many audio interfaces (not sure about the above RME, being it’s a PCIe being one of them) can have multiples of their units installed in one machine for more I/O, all running under the same ASIO driver. And that could be a lot less expensive of a proposition.

Sending separate audio feeds among multiple DAW’s in a VSL network, say 4 as in the examples above, at least seems like it would give less audio latency than sending all audio through the same audio/data ‘ring’ of cables. What the difference of latency really is between the two types of configurations, I’m not sure. I would assume each individual machines own audio latency would be fully added…that is, opposed to how midi works, that adding midi devices do not add to the total latency…so I read anyway.

I don’t understand the interest in VSL since VEP Pro came out.

I don’t tried VSL, but VEP doubles the latency of the whole system due the ethernet data turn-around.

Haha! I was expecting a “VEP Pro is better” chime in at some point :slight_smile: And it does seem like many who are looking for a solution to harness the power of a 2nd machine, gravitate toward VEP Pro. However that’s not what I was talking about, but feel free to chime in with anything :wink:

In all fairness, with VEP Pro & VST System Link, I believe there’s going to be a some amount of latency involved when using ‘multiples’ of machines (especially in say 3 to 5 machines) but with say only 2 machines I’d imagine the latencies involved would be fairly low, manageable & very workable for either.

One thing about VST System Link that’s intriguing is that each machine can be completely ‘separate’ yet work as one, and how you use them, or how multiple users use them is up to you. You don’t have to work with both (or all) machines full time…but one or the other (depending what you’re working on) and add your machine(s) as needed. You’re not limited in many ways, one such way is you don’t ‘have’ to send midi between machines at all, you can record your midi directly into your VSTi machine, do everything you need to do locally there (as you would with one machine), and just send a stereo sub-mix back. You don’t have to have complicated routing schemes between machines with your audio or midi (though you can if you must). VST System Link just seems like a better & easier way of working to me compared to the complexity involved of Ethernet networking. Personally, I don’t understand why VEP wins over with VSL…I guess it’s ‘the new kid on the block’ kind of thing. But I do admit the Dante thing(?) seems very interesting, and how they claim it automatically recognizes and configures everything for you, now THAT’s special…expensive for now though.

Anyway…back on topic, which was regarding the potential decreasing of latency involved when removing the audio streams of each computer from the VST System Link ‘ring’ network, as in how I for the most part have understood how it’s done, but instead merge all audio to a central hub/master, with or without a mixer as was shown since many sound cards are capable. Even years later since the introduction of VSL, there’s not a wealth of very clear information, especially on the various configurations. Though I guess anyone can try both ways and compare for themselves.

Something I’ve been thinking of… I read recently on-line that VST System Link is among the most accurate means among other protocols to sync DAW computers together. If the audio can be merged together for less latency among several computers as in the above images & configurations I had posted, why can’t VSL be designed to also merge the DATA together as well? It is said that the machines can ‘react sluggish’ in a VSL system. I wonder if the transport functions are really all THAT sluggish with say 3 or 4 machines… and as long as the audio can be merged to reduced latency there, maybe the rest is negligible :question: