HDX/HD|IO latency greater than Apollo Twin Duo?

[melodydetective]

Hey folks -

So - HDX in a Sonnet TBolt 2 chassis, connected to 2013 12-Core Mac Pro. Old Apollo Twin Duo on another tBolt bus, intended for system sound and as a dongle for the DSP sometimes.

I’m sequencing orchestral score. Everything is real-time. Switching between engines, I have found that using HDX, my full template requires a buffer of 512 when I’m lucky and sometimes 1024. When I switched over to the Apollo, I was surprised to be able to get 256 and often 128. At 48k it’s a pretty big difference in playability. Trying to figure out why this is before I ditch the HDX and HD|IO and get a thunderbolt Lynx Aurora or something. Any thoughts?

[BScout]

HDX is a dsp mixer/engine. Everything is operated on the cards. Samplers/sample playback like Kontakt, etc are native processes. So an HDX system has to transfer over to the native engine to run the plugins and then transfer back to the HDX engine for the audio mixer side. That's twice the amount of buffers needed just to complete that.

On any core audio hardware, you start and stay in the native engine on the cpu. None of these buffer transfers between different engines. Unless you need the I/O, using PT HDX for orchestral sampling/sequencing is a bad idea.

[DetroitT]

Also note that having a master fader without any plugins inserted
Your midi response will be independent and better than engine buffer size

[Bob Olhsson]

Buffers don't include the hardware latency so settings are somewhat meaningless when comparing platforms.

[Marsdy]

Originally Posted by BScout

HDX is a dsp mixer/engine. Everything is operated on the cards. Samplers/sample playback like Kontakt, etc are native processes. So an HDX system has to transfer over to the native engine to run the plugins and then transfer back to the HDX engine for the audio mixer side. That's twice the amount of buffers needed just to complete that.

On any core audio hardware, you start and stay in the native engine on the cpu. None of these buffer transfers between different engines. Unless you need the I/O, using PT HDX for orchestral sampling/sequencing is a bad idea.

I’m not sure about this. Latency soon builds up if you repeatedly transfer too and from HDX to native but if you’re careful you can mitigate against that. Once it’s on the HDX card it stays on the card. Surely VIs only have to travel once from native to HDX don’t they?

I’m getting great VI performance with HDX and a huge template. I’m usually at a buffer of 256 and VI latency in HDX feels fine for my purposes when played from a keyboard or Maschine. It feels less responsive and more “flammy” when I switch to native at 256. I don’t know why that should be but it’s definitely noticeable. If I was working native I’d want to be at most 128.

Then of course I can still track audio at very low latency. This wasn’t the case with my UA Apollo.

I also have 24 channels of hardware synths/Eurorack constantly running live which only get printed when something is signed off. HDX is effectively a live mixer so I’m getting the hardware running live, perfectly playable (for me) latency for VIs AND very low latency for tracking real instruments/vocals etc. I couldn’t do this with the Apollo and mix as I go even without using UAD plug-ins.

[melodydetective]

Originally Posted by Marsdy

I’m getting great VI performance with HDX and a huge template. I’m usually at a buffer of 256 and VI latency in HDX feels fine for my purposes when played from a keyboard or Maschine. It feels less responsive and more “flammy” when I switch to native at 256. I don’t know why that should be but it’s definitely noticeable. If I was working native I’d want to be at most 128.

Then of course I can still track audio at very low latency. This wasn’t the case with my UA Apollo.

So what’s a huge template?

Let’s see if I’m doing something foolish here - I run all of my VEPro Instances on instrument tracks- used to do them on audio tracks until I read that lower latency can be achieved this way, but I have not verified this. It’s a 12-core 2013 Mac Pro with 128GB of RAM. I’m running Berlin Strings (all of it), SampleModeling Strings, all of the AudioModeling woodwinds, Superior Drummer 3, Trilian, a ton of Sonic Couture, Vir2’s Acou6tics library, IS Steel Guitar, Orange Tree’s Ukulele and tele, Omnisphere 2, Serum, Ana2, Strezov Upright piano, Bolder Roots upright bass, Spitfire Aperture, and a few of the NI ultimate instruments - and the second Mac has a ton more things connected via VEPro. Everybody is streaming from SSD’s, primarily nvme. Running digital picture using Avid’s own DNxHD codec and an Aja T-Tap. Using Altiverb and a couple of Slate reverbs, and the steel guitar has an AR-1 on it, and the strings have some eq. HDX, 16x16 HD|IO. Using a Sonnet expansion chassis. With this setup all loaded using HDX I can not use 256 buffer size at all. 512 sometimes works. It prefers 1024. When I use my cheap little Apollo Twin Duo I can use 256 sometimes but it prefers 512. The VEPro buffers are mostly x2, but one or two on the other machine are x3, and I know they should be worse and I live with that. I don’t buss for stems - I bounce stereo mixes - so there’s no extra aux routing delays.

The thing is, I’m all about real-time. So there’s going to be a little latency while recording MIDI - I get that. What I don’t get is why it’s worse with the hardware - unless it’s all about trips back and forth between the card and the native stuff - and it occurs to me that there are some aax-dsp plugs (eq’s) on some of the VEPro tracks. So I guess I can disable those and try again. Hard to have time to experiment when deadlines loom.

As my satellite computer (5,1 [email protected] GHz) is getting long in the tooth (my “2013” Mac is from 2016) I’ve been looking at building a PC just for VEPro, but I’m wondering if it’s going to buy me anything in terms of responsiveness - if it’s a monster I should be able to lower its buffer multipliers, which will help, but not much. So I’ve been taking a hard look at what I need the hardware for - and since one can live-track through most if not all native-styled interfaces using internal no-latency monitoring, I’m asking myself how much I need the DSP. (Even if I had it in a UA or Antelope interface I wouldn’t use it much - real-time is boss here.)

Any thoughts welcome. I’d like to be at 128 also but the size of my template kind of obliterates that possibility.






Sent from my iPhone using Tapatalk

[Darryl Ramm]

What I don’t get is why it’s worse with the hardware - unless it’s all about trips back and forth between the card and the native stuff

It sure is about that. You have to go though a buffer on each trip between the DSP and native worlds. What benefit did you expect HDX to add here? Whole different argument if you were say doing live audio tracking with monitoring.

[Marsdy]

Originally Posted by melodydetective

So what’s a huge template?

I’m very close to maxing out HDX’s voices, 256 in my case, with a number of tracks made inactive above that. 90GB or so of Kontakt libraries spread across VE Pro running on the same Mac as PT and a satellite VE Pro PC. There’s a LOT of Spitfire in there, some Orchestral Tools and Vienna, Output, BFD or Superior Drummer, Maschine, Omnisphere plus the hardware synths. I’m getting thousands of Kontakt voices and they soon add up with Spitfire.

I’m not sure what I’m doing that is hugely different. I’m also running VE Pro with a buffer multiple of x2 which is effectively doubling PT’s buffer or course.

One thing I do make sure of is that any VE Pro/VI tracks NEVER go back to native. It’s always HDX DSP processing and every track has a DSP EQ even if it’s not doing anthing. Most of the time I’m fine with a buffer of 256 even with Kontakt polyphony running into the thousands. Latency feels fine to me at 256, even for finger drumming on Maschine or Octapad overdubs of trailer percussion.

I also don’t buss sends to native reverbs until the last minute. I’ve mocked up my favourite Altiverb IRs with Revibe DSP and swap them out for Altiverb near the end of a mix.

My satellite PC is reasonably well spec’d, HP Z4 3.5Ghz 4 core (I think!) 64GB RAM, NVME drives. Nothing special except the drives are really fast.

The BIG bottleneck for me is not so much buffers and latency but certain, mostly Kontakt instruments that overload one core in PT when record enabled. My favourite piano (Imperfect Samples) is a killer for example.

[melodydetective]

Originally Posted by Marsdy

One thing I do make sure of is that any VE Pro/VI tracks NEVER go back to native. It’s always HDX DSP processing and every track has a DSP EQ even if it’s not doing anthing. Most of the time I’m fine with a buffer of 256 even with Kontakt polyphony running into the thousands. Latency feels fine to me at 256, even for finger drumming on Maschine or Octapad overdubs of trailer percussion.

I also don’t buss sends to native reverbs until the last minute. I’ve mocked up my favourite Altiverb IRs with Revibe DSP and swap them out for Altiverb near the end of a mix.

Well, with a few little changes I’ve reduced my latency by more than two-thirds - primarily because of the native stuff in the session. I converted the offending plugs to DSP from native and went from a reported system delay of 3600 samples to 834 samples. (Really handy to see it there in the command-2 window). I am approximating the reverbs with things that run on DSP (about to try out Space today but I don’t know if there are any stages in the library - may have to run an impulse through what I’m using and see about that), with an eye towards importing session data for the reverb returns or using track presets before printing.

Thanks for that bump in the right direction. Now that I’m also switching to Video Slave 4 for picture, the system is much much better. Wouldn’t you think a video company would have better... never mind.

[LDS]

Originally Posted by melodydetective

Now that I’m also switching to Video Slave 4 for picture, the system is much much better. Wouldn’t you think a video company would have better... never mind.

Oh man. That gave me a giggle.