Jim Roseberry

My advice... If you want a smoother ride, stay on the backside of the update wave. If you ride the crest, sometimes you're gonna wipe-out. (cue that tom intro)

When playing virtual-instruments, you're dealing with one-way (Playback) Latency. Playback latency is (roughly) half the total round-trip latency. Certainly workable (decent) with the Apollo... The RME Fireface UFX+ can achieve lower Round-Trip and Playback Latency. The Presonus Quantum can achieve even lower Round-Trip and Playback Latency than the UFX+. If lowest possible latency when using 3rd-party EFX/Instruments is a paramount concern, Apollo isn't the interface you want. Apollo's forte' is fidelity... and being able to run UAD plugins at ~2ms round-trip latency.

By very definition, ASIO can't use more than 1 audio interface simultaneously. Some manufacturers get around this by allowing using two (or more) of that same/similar model of audio interface... that each use the same ASIO driver. IOW, The additional audio interface shows up as more audio I/O... using the same (single) ASIO driver. You can create an aggregate audio device using ASIO4ALL, but then both devices would need to share a common clock (otherwise tracks would drift apart over time - due to the slight difference between the two clocks). It's (at best) a half-baked solution. If you need more I/O, you're infinitely better off getting a single audio interface that has the necessary I/O.

You'll want either the Apollo x8 or x8p. x8 has four onboard mic preamps x8p has eight onboard mic preamps Both will allow playing/monitoring thru UAD plugins at ~2ms total round-trip latency (using their "Unison" technology). Apollo's only real downside is if you're trying to achieve lowest possible round-trip latency when using 3rd-party plugins. Apollo can achieve ~3.7ms total round-trip latency. That's not particularly bad... but you can achieve about the same with a top-tier USB-2 audio interface (ie: RME Fireface UFX).

Hi Craig, I'm sure the 64Bit mix engine makes any rounding error moot. ? With CPU power available today, it seems unnecessary to make Normalize a destructive process. I'd like to see (per-clip) Normalization and Static Gain... as those features combined would (non-destructively) address any Normalization need... and allow quick means to level out a performance.

I agree. Non-destructive Normalize and Static Clip Gain should be tied together. Make it so!

FWIW, Thunderbolt-3 is rock-solid on the PC side. I've been running Thunderbolt audio interfaces on PC for a good while (UA Apollo-8 and Satellite, Antelope Zen Tour, RME Fireface UFX+, Presonus Quantum). All ran flawlessly... I'm currently using Quantum and UFX+ Quantum for when I want ultra low round-trip latency UFX+ for when I want hardware based monitoring We have many clients running Thunderbolt audio interfaces.

Another thing to be aware of... Some older USB-2 audio and MIDI interfaces don't work well with USB-3 controllers. Usually, the issue is with 3rd-party (not Intel) USB-3 controllers.

Presonus Quantum can get down to ~1ms total round-trip latency. UFX+ can get down to ~2m total round-trip latency.

I was running an Apollo-8 (Quad) and Quad Satellite expander (both via Thunderbolt) for a good while. Fidelity is excellent (super low noise-floor). Stability was excellent. My only gripe with the UA audio interfaces is that (due to their onboard DSP), round-trip latency is a little higher than something like a UFX+ or Quantum. Of course, if you're wanting to run UAD plugins, you can play/monitor in realtime thru UAD plugins with 2ms round-trip latency (via their Unison tech). The lowest round-trip latency you'll achieve with the Apollo series (and Arrow) is ~3.7ms. If you go Thunderbolt, you've got to make sure all the details have been tended-to. The combination of Asus Thunderbolt EX3 and the Apple Thunderbolt-3 to Thunderbolt-2 adapter has worked extremely well in all scenarios we've tested. This includes many different desktop builds, laptops, etc... Though Presonus recommends the StarTech Thunderbolt-3 to Thunderbolt-2 adapter, the Apple adapter works perfectly fine with Quantum.

In this day and age, Normalizing should absolutely be non-destructive. It would make sense to tie this into that Per-Clip "Static Gain" parameter I've been lobbying for. ? There are many cases (when mixing), where I'll use static gain changes (per clip) to even out a vocal performance. Yes, Clip Envelopes work... but it's slow (compared to a Static Gain/Normalize parameter).

As a test, what happens if you switch to the onboard audio? Does the issue with crashing persist? The reason I ask is the HD500x drivers are getting a bit long-in-the-tooth. First thing I'd do is rule it in/out as a culprit.

For a period of time, I was using a Zen Tour audio interface (which doesn't provide a WDM stereo port for Windows Audio). This small application can route Windows Audio to one of your audio interface's ASIO outputs. https://www.vb-audio.com/Voicemeeter/index.htm If you're wanting to "connect" various applications, this may be what you're looking for: https://www.vb-audio.com/Cable/index.htm

That was excellent all around. Both performance and recording... Funny enough, I kinda like this version better than the original (though I'm not a huge Chicago fan).

If you keep your machine disconnected from the Internet. ? With the Pro version of Win10, you can completely shut down all Automatic Updates (including notifications). Unfortunately, you can't do this in the Home version. There is an "in-place" upgrade from Home to Pro... but MS gouges a bit on the price ($100). There's no performance advantage to Pro, but we recommend it to clients because it allows more control to "rein-in" Win10. Automatic Updates can be fully shut down... and the Group Policy Editor makes it easy to shut down Cortana, OneDrive, etc.

I've got the Montage version of SampleRobot. Haven't had the time to use it.

Yeah, I'm sure you *can* do it... but it will be an elaborate process to get all articulations captured/programmed... with custom script/s controlling the switching. That makes my tendons hurt just thinking about it. ? LOL

IIRC, Waves Central doesn't ping the Registry for your preferred/default VST Plugins folder location. Every time I reinstall my Waves plugins, I have to manually move the WaveShell dlls. That said, I wouldn't want to be without their SSL Bundle, H EQ, or Scheps Omni Channel. If you ever need a de-esser to solve problems (string squeaks, sibilance, excessive cymbals), the pair in Scheps Omni Channel are amazing.

Hey Max, Isn't the vl70m a physical-modeling synth? If so, it's going to be really hard to sample that... so it accurately reproduces all nuances.

If you're working with straight up audio production (especially with today's delivery often being "digital"), it doesn't matter nearly as much as 20 years ago. Sample-rate conversion is significantly better than it was all those years ago. If your'e working with video, it's more convenient to stick with 48k. The latest project I'm mixing was done at 96k. The previous project I was mixing was at 44.1k. While I do believe there are audible advantages to using high sample-rates, there are many other factors that have larger impact on final quality. Front-end gear Mic placement Engineer's experience Quality of instruments Caliber of the player (a great player will sound good on nearly anything) Song arrangement Etc

Make sure you have a backup if you're going to install v1903. Even with the latest patches, we've seen DPC Latency issues with current generation hardware.

If you don't know what you're doing, be careful when switching! Some devices don't work (at all) with MSI... and can cause your machine to BSOD. Other devices (like RME audio interfaces) will appear fine... until you try to use it (and realize it's not actually working). Video cards and most of the core hardware work fine with MSI Audio interfaces (dedicated and onboard) and Firewire controllers often don't work with MSI.

The reason you see this is due to CPU throttling. When the machine is under heavier load, DPC Latency is lower... because clock-speed is higher. If the machine has major issues with DPC Latency, putting it under heavy load won't solve the issue. Power-management necessary to achieve long battery-life is diametrically opposed to configuration for maximum performance. That's the heart of the issue. If you look at any of the top performing custom built laptops, notice that they're *all* using Clevo shells. They're expensive, bulky, and have extremely short battery-life. Physics... of such a tight space make it a complicated balance. If you're strictly talking off-the-shelf laptops, Apple (OSX on the MBPs) does a better job juggling the above than any off-the-shelf PC laptop. Custom Clevo's smoke the MBPs... but that's another topic.

Is everything powered from a single outlet? If not, I'd try that before unplugging all audio.

At the risk of repeating: If the machine suffers from high DPC Latency, there is no working around it. It has to be solved at the source. No audio interface, no setting core affinity, etc. Read the details here: https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-threaded-dpcs With many cases... especially when it's ACPI (power-management) related, there is no solution. The only solution is to replace said hardware (in the case of a Laptop, NUC, All-In-One) isn't possible.