Vienna Symphonic Library Forum
Forum Statistics

181,993 users have contributed to 42,199 threads and 254,645 posts.

In the past 24 hours, we have 4 new thread(s), 9 new post(s) and 49 new user(s).

  1. Home
  2. Software
  3. Vienna Instruments Pro
  4. Contributing factors to latency in VEPro 7

  • Contributing factors to latency in VEPro 7

    D
    D
    Hello folks - It’s coming time to build a new PC for remote VEPro duties. So I’m wondering what things I can do to address large buffer sizes in the remote machines I use. My main machine is a 2013 Mac Pro 12- Core with 128 GB of RAM and ProTools HDX with an HD|IO and the satellite is currently a 2010 Mac Pro 3.7Ghz 12-Core with 64 GB RAM. The remote machine is handling many things, most notably the SampleModeling brass which are pretty demanding CPU-wise, but also the OT Metropolis Arks and several percussion libraries (it’s also where I’ve “quarantined” the EW Play player). The main machine is doing various libraries including my VSL winds and strings, and also AudioModeling winds and SampleModeling strings, Superior Drummer 3, Damage 2 and a host of other Kontakt instruments, as well as Altiverb and a few other verbs for tail. I use a local VEPro to host the instruments, and the Reverb’s are all in Pro Tools. I sketch with most instruments turned off but a piano, and I can do this at a low buffer size, but when it’s all up and in use, I have to - have to - use a 1024 buffer to avoid the usual pops etc. (I’m working at 48/24.) In particular, the brass instances on the remote machine (an instance per section, and a Kontakt instance per chair) require 3 buffers in the instance to play back without artifacts. Everything in the satellite Mac is streaming off of nvme drives in a Sonnet 4x4 PCIe card, and throughput and latency are excellent. WiFi is off. Gigabit Ethernet connections through a Netgear switch. Cat6 cabling. Short runs. My instances of VEPro are on instrument tracks. I also use aux inputs for multi-out returns from VEPro. So I can manage the delay after the fact very reliably - compensation has been fine; but obviously it’s no pleasure to play through. What I would like is a minimum of latency for real-time performance. Where can I look to start improving this? If I did less on the main computer and more on a very fast remote computer or computers, or if I did it all locally on a much faster computer? I realize that the newest tech in there is seven years old (though I bought the 2013 Mac in 2015 new). I’m just trying to figure out where the logjams are so a) I don’t configure my machines poorly and b) so I don’t spend a ton just to discover that I’ve gained 5ms of latency performance. Also, I’m doing some transitioning for certain kinds of work into Cubase. I still use VEPro on the remote Mac but have found that for my workflow needs, using Cubase to directly host plugins works a little better. So, VSL geniuses, what’s the path to awesome here? What aspects of a system govern buffer sizes the most - CPU speed, drive latency and throughput, other? How do I get a system to allow me to play a remote DSP-hungry instrument without having an eighth-note delay? Thanks!
  • C
    C

    "Where can I look to start improving this?"

    The audio interface designed well for low latency. I recognize all of that and for far too long was doing 1024 samples buffer in order to have things not badly falter. During most of these years I was under-specced to a degree where I was hesitant to say the least to throw money at the problem, and most of the claims and benchmarks are windows-centric and not even relevant, I'm a skeptic... but this year I spent $650 on the Quantum 2626 by Presonus. So now no matter what I throw at it my latency, set at 192 buffer gets me 8.5 ms roundtrip. I'm a poor tech writer so my explanation of why this is working isn't anything, but it uses a Direct Memory Access driver which takes a lot of load off the CPU.
    Unfortunately I don't think it's going to be the same thing on your older machines, it leverages thunderbolt 3. I honestly don't know what is good or what isn't. I had an RME firewire interface with a MacPro 2009 model but while it was much better than the onboard audio drivers it was not what it's cracked up to be on windows.
    But the quality of drivers on the audio interface is the biggest part of the solution. NB: I am working on one machine/local host, machine in my sig. Generally you need the muscle on the slave; me, I didn't lose much if anything by selling the  MacPro I used as master and doing it all localhost back then.

    If you are experiencing bad bottlenecks (frankly that all sounds pretty normal to me) the cause is almost always some hardware not playing nice with the rest of the system. A video card, USB devices that aren't very well-designed etc.