Yes, I know that video I saw many years ago, and I saw it again with great pleasure because it is both interesting and accurate but sometimes a bit reductive (I did live VJing for years and managing video latency in real time was more important to me than audio since my images had to be matched in real time to the sound. Video and audio in real time have the same constraints).
But maybe I misspoke about the choice of a processor or maybe you didn’t read the Intel link: I did say to choose the type of processor to use for audio, I didn’t talk about processor power.
I’m using GP as a spare on a 2012 laptop with a third generation i5 processor (we’re on the twelfth) and it’s more than enough to play live without annoying latency.
Why is that? Because I chose the type of processor, not for its power. I chose a processor optimized for computation and not for i.e. video or energy saving. The latter, as shown in the video, will go through a set of routines to constantly scan for opportunities to interrupt its work to consume less power, quickly causing audio artifacts and forcing latency to increase.
And of course, as you said, it is a set to manage for the best performance, proper processor, efficient bios, stable drivers, sufficient ram, optimised OS, properly written software and plugins. One thing can disrupt the whole thing (I recently went back to a bios previous version).
Finally, don’t forget that, as stated in the Richard Ames video, cpu benchmarks are not the best way to determine daw performance
Thanks for the feedback. I just check the link as i am kind of familiarized with such nomenclatures so it is also good to have a refreshments.
The thing is, now with intel and its hybrid processors, starting with gen 12, it will be even harder to optimize windows pc/laptops as there are more things to optimize. Sadly, and just in my opinion, macs are more and more relevant for audio as windows PCs looks just worse every year for real time tasks. But at least there are options.
The round trip latencies mentioned above are really hard to get in a “non standard” pc/laptop, so probably my next computer will be a mac.
Best possible theoretical latency in each direction is [buffer size / sample rate]. With 128 samples @ 48kHz you’re looking at 2.667 ms in each direction just for the A/D conversion. You’d have to be down around 24 samples to get 1ms RTL at 48 kHz.
You may have had something set up incorrectly for the RTL test, where an output is getting routed back to an input without ever going through the A/D and D/A conversion process.
Watch out here: far from all iOS apps run under macOS on Apple Silicon hardware.
It’s up to the developer to opt-in to (or perhaps -out of) this possibility. When I check in the App Store on macOS, there’s no TriplePlay app for iPhone/iPad - but I see it in the iPad’s App Store.
