X2 Audio Engine Improvements?

Sorry if this is an old\repeat question but I've been out of the loop and a quick search did not get me what I would like to know. What does the improved low latency audio engine enhancements in X2 amount to? I have a Presonus Firestudio 10x10 and for the most part have no problems but there are times (when least desired) that the audio engine drops particularly with a number of tracks and additional effects processing. I have found ways to work around it, but is the expectation with X2 that some of these work arounds may no longer be needed?
 
Thanks

You shouldn't be getting dropouts unless you're are running a HUGE number of tracks and/or plugins.

I'd look to your settings before asking about engine improvements.

As an example, I was able to run a project with 75+ audio tracks, well over 100 plugins, many, many instances of live V-Vocal clips on 8.5PE working in XP32 with 4gB of RAM, and the audio engine did not enter into my ability to stretch this project any further

I just hope the "audio improvements" isn't based on Windows 8 Audio improvements. I will not be upgrading to Windows 8 due to the UI being basically a tablet OS.  In the web seminar, they did mention using/getting 2ms latency but wouldn't use it during a live broadcast.

Yea, its a general enhancement most likely. With that said, i'm sure Windows 8 is more efficient than win 7 , Vista and XP, So
you will see better performance using Win 8.. That's just how things work in the software age

Cj

Hey, all. I've been lurking for a while and can't help but notice the awesome, enthusiastic, tight-knit group on this forum.

I've got a show-stopper related to the audio engine that I'm hoping X2 addresses. It sucks that this has to be my first post to the forum, but...

There seems to be an issue in X1, relative to other DAWs, on the same hardware, all things being equal, in terms of lesser audio engine performance. Specifically, with VSTs as instruments (it does not affect effects). I recreated a mastering chain (mostly Softube and Waves VSTs), to exact specifications, within Cubase, Reaper and X1d (all in 64-bit mode) on a newly built screamer of a machine (water cooled Ivy Bridge running at 4.7ghz, 32gb of 1800ddr3, SSD, etc.). I'm getting really great (low) DPC latency on this beast -- below 100 microseconds and even dipping down into the low 40's. It never spikes above even the yellow line.

All DAWs have similar, high latency, buffer settings with my MOTU 896HD audio interface running on a dedicated ti-chipset-based firewire card (SIIG -- I researched this extensively. "ti chipset" is key). Running at the modest 44.1Khz. Latest drivers, Windows 7 64bit Pro up-to-date, etc.

Cubase runs the live VST chain at about 30% CPU utilization with plenty of free CPU left over for a responsive UI and quite a few number of VST instrument tracks before having to freeze.

Reaper does the best at about 20% CPU utilization, on this very same mastering chain. Plenty of free CPU left for VST instruments without having to freeze.

Sonar X1d initially fooled me into thinking it was going to beat Cubase. I recreated this mastering chain in it and played back a test submix (stereo wav file, 24bit, 44.1) into the chain and the CPU was at 25% with a still very responsive UI. I was thrilled and ready to officially switch to Sonar!

Then it happened, the unthinkable, the bizarre, the insidious. I swapped out that stereo submix for a re-creation of my first "real" VST instrument track -- that is, I started recreating the project in Sonar for real. VST instrument track by VST instrument track. The very first VSTi brought this performing-along-quite-well project to its knees -- audio dropouts every 3 seconds. If I disabled large parts of the mastering chain, the dropouts would eventually stop.

So, I didn't panic. I assumed it was a audio driver choice, buffer setting, etc.

4 hours later...

Hmm, does not appear to be.

Maybe it's something strange with this VSTi. So, I tried several others.

Some time later...

Nope. Oh boy. Now, I'm getting nervous.

I then hit the forums. Hard. Searching for any and all tips.

I tried just about every configuration and permutation possible (but perhaps not, a magic setting might still be out there).

Then I called Cakewalk support and after an hour or so of troubleshooting, they, too, were at an impasse. They confirmed that it should not be my audio interface choice or firewire drivers or card. They confirmed my feeling that buying a new audio interface would not change the situation (and, again, it works flawlessly with Cubase and Reaper). In fairness, the next step was to generate a debugging dump to submit to them. This is where I had to stop and put Sonar on the back burner. I ran out of free time. Back to work. Also in fairness, we tried several audio driver settings, but perhaps not every single permutation.

So, I'm back to using Cubase, for now. I'm VERY interested (obviously) to see if X2 magically fixes this template shell project of mine such that I can play even just one VSTi into my real-time mastering chain. If so, I'd be fine with freezing all but one working-track. I am not going to even entertain sacrificing my chain, as I don't have to, Cubase and Reaper will drive it with tons of CPU left over. If it were a close race, I would just accept that it's a slight difference in audio engine performance and would assume my real-time mastering chain goals are too ambitious. But, it's not a close race, there is still like 75% i7 goodness to spare! Sonar *should* be able to handle this project without breaking a sweat.

It's odd that VSTs as *effects* seem to perform on par with what you'd expect, but that VSTs as instruments do not. I'm wondering if there is some kind of cpu-expensive, thread-blocking "wrapper" for the VSTi code that is different than Sonar's VST code.

Then, after more forum searching, I found this (it would appear I'm not alone): http://forum.cakewalk.com/tm.aspx?&m=2068222&mpage=1

I also found this, which seems to support some aspects of my findings (albeit on old version of all the DAWs): http://www.dawbench.com/dawbenchdsp-x-scaling.htm

As it stands, for my very specific purposes, I can't use Sonar X1. I hope X2 addresses this bizarre issue.

I'm open to any and all suggestions (that don't involve me altering my mastering chain :-) ).

Cheers.

Even though i pre ordered x2 im still worried about its audio engine stability. The only reason i still support cakewalk is because i basically started out with it (Waaay back, now i use another daw exclusively) and i'm very interested in the progress of its audio engine. If some form of stability is observed i may start using it again as a "studio d" in one of my empty rooms.

Thanks for the fast weekend reply, Noel.

Bummer. That's a deal breaker for me it sounds like.

To clarify, so only one core for the entire stereo bus? That is, the mastering chain (stereo bus and parent buses) + the one VST. Is that right?

I bet this is why Reaper does so well in this test, as it does some major multi-threading, load-balancing stuff behind the curtain.

So, it sounds like X2 does not change this behavior?

Super bummed about this. My mastering chain is everything to me. It's essentially my "studio" and and my "sound." I have to mix and produce into it. This has changed my entire process and approach (controversial as it may be) for the better (for my style of music) and I'm not looking back.

I consider this to be a huge deal as it relates to competition with other DAWs and modern multi-processor CPUs, right? To have the entire 2bus limited to one core? I mean, the 2bus (and all it's upstream buses) is like 90% of a modern project's workload, but with Sonar, it only gets 25% of your computer. Yikes.

Btw, this also means, for Sonar, it's better to have less cores at a higher clocked/spec'd CPU than a lower clocked/spec'd CPU with more cores.

This also explains why people were able to work around this by running Reaper in rewire mode into Sonar and have it play the VSTi's. 

Well, I can't buy a faster computer for Sonar. i7 Ivy Bridge 3770K watercooled at 4.7ghz is the best possible configuration at this time (until the "X" Ivys hit the market next year).

I'm at least glad this mystery is solved. Thanks for disclosing that info, Noel -- you didn't have to do that.

I appreciate your kind offer to troubleshoot, but I don't think it would be worthwhile. I think it's pretty clear what's going on -- my 2bus, plus its one VST, is maxing out a core. My CPU util. number match up with that (25% of a 4 core CPU is one core). *sigh*

*goes crawling back to Cubase with hat in hand* (Btw, the 6 insert fx limitation in Cubase is killing me, which is why I looked to Sonar. And Cubase is crash-tastic. Sonar seems super stable.)

Best regards.

Thanks again for the reply, Noel.

Yes, with respect, I completely understood what you were saying; about what a "serial stream" is.
And that's what I have going on: One simple track feeding into a stack of insert effects, in series, on the stereo bus. That's it. Super simple. There's our one "circuit" (no multiple tracks).

I get that for multiple tracks (parallel signal paths), or "circuits," they'll be balanced across the cores.

Again, at risk of sounding quarrelsome (not trying to), my observation still stands about how only a single core can be used between, let's call it the, "All Stems" start-point of the circuit -- insert serial mastering effects here -- and the end-point of where it hits the master stereo bus; that's one circuit. I don't think there is anyway of "cheating" that. That is, a "mastering chain" is always going to be limited to single circuit, a single core.

This is not how it works with Cubase or Reaper. The exact same one track + stack of effects (in a serial circuit) is balanced across the cores -- the project plays without hiccups.

Okay, I'll send you a PM with questions on how I should prepare this project (I may have to recreate it using stock Sonar plugins so that we're comparing apples to apples).

Thanks again for the support.

Cheers.

Now that...my friends...is what you call tech support at it's best.. :)

Great support, indeed.

Fear not, Grem, I'll be sure to update this thread with any interesting developments. :-)

>> I will not be upgrading to Windows 8 due to the UI being basically a tablet OS

Touch has been available for many years.

The new START-MENU is a full screen. Showing lots of stuff, if ya want it to. Works fine with a mouse and keyboard. Been doing so for about 6 months.

And, although some of the start-menu-screen is stupid, some of it is useful.

Better audio performance? Good. Won't have to buy a faster computer this year.

SX2 on w8 in about 3 weeks.  Meanwhile: learning, and configuring w8, and playing with SX1.

What more can an old man want?  Other than,.....

j

@jm24 - Well Windows 8 could be great, but my experience (I have worked for years in the IT sector - especially huge networks and mainframes) tells me to wait until the first service pack is out. There are always "hidden" problems with new systems, that become manifest when using systems for a longer time. So - if you are using an OS like Windows 8 in a mission critical environment I advise to wait until the first service pack is tested. If you are using W8 as personal system I guess you can experiment.

I have heard mixing experiences with W8 until now. Some audio and/or video drivers do not seem to play nice (yet). Also some test seem to suggest W8 itself takes some more processor power (and memory) than W7 in same conditions. That would give some slight problems with more heavy projects. I cannot confirm this at this moment, because I do not have run test myself (hey - there are only seven days in a week ;-)). I think it is best to wait until there is more certainty about this subjects.

@Saxon1066 - What I understood (from the video) is that the engine runs smoother although not gapless (witch is good enough for me). Also a lot of plugins are optimized to have lower latency, so you can make adjustments without those little hiccups that proved to be a little problem with the more "heavy" plugins in the past.

wXP had 3 service packs
wV had 2
w7 had 1

w8 had more than a year of preview releases.

I think the major issues we will have to wait to be fixed are from 3rd parties.

And the service pack for w7 was mostly a roll-up of previous releases.

=================

Fur shur, I will not recommend it to my clients until we know their important programs have been updated.

But some clients do want to upgrade their wXP, wV, and w7 computers. And some will buy new computers with w8 installed.

=============
Meanwhile I am installing, and upgrading, on some of the office computers, new and old, and learning.

The music comp is triple boot OS.  It is the newest hardware. And is more specific and tweaked than the other computers. So, it provides lots of bits of what is working and not. (Korg nano drivers do not work. Is this the drivers, or conflict with other hardware, or w8?)

Don't be afraid.   For $40 bucs it is an easy choice to purchase, add a partition, and start learning.

In general, blind, non-reversable, upgrading of ANYTHING is to be avoided. Imaging is your friend.

bitflipper

This is not how it works with Cubase or Reaper. The exact same one track + stack of effects (in a serial circuit) is balanced across the cores

This is a thought-provoking statement. Can anyone explain how a single data stream might be split across multiple cores? I certainly can't. 

Im trying to wrap my head around that too.  What is it that plug-in #2 could process in advance, and in lieu of not having, the output of plug-in #1?  That's a brain-teaser, but maybe there's some other explanation to the statement.  I can't imagine what though...

bitflipper

This is not how it works with Cubase or Reaper. The exact same one track + stack of effects (in a serial circuit) is balanced across the cores

This is a thought-provoking statement. Can anyone explain how a single data stream might be split across multiple cores? I certainly can't. 

I found an interesting article that touches on it. It sounds like it's probably trading latency for core utilization. "Anticipatory" being that it somehow does some kind of "out of order" pre-rendering, or something. Conceptually, I don't get it. It sounds like witchcraft, but it appears to work.

Update/edit: Oh, wait. I think I get it! Maybe it does small, end-to-end (serial, on a single core) chunks within a higher latency buffer and then "assembles" those rendered chunks into the final stream. A half a second here, a half a second there (out of order). Each "job" gets a small slice of time from a "pool" of what was rendered upstream. In this way, you could "weight" the most "contiguous" rendering toward the start of the signal path, the more segmented parts toward the end of the path. This approach would give you more core balancing toward the end of the path and more raw crunching performance toward the beginning (as it's working with larger chucks). If i'm right, first of all, I'm effing brilliant for figuring that out (hahaha), but more importantly, what a genius algorithm/approach.

http://www.soundonsound.c...es/pcmusician_0108.htm


"Reaper's Justin Frankel told me that he routinely does a lot of his development on a dual quad-core Xeon PC, so it's hardly surprising that the default Reaper settings work well with up to eight-core machines, typically offering over 95 percent utilisation of all eight cores. Reaper mostly uses 'Anticipatory FX processing' that runs at irregular intervals, often out of order, and slightly ahead of time. Apparently, there are very few times when the cores need to synchronise with each other, and using this scheme he can let them all crank away using nearly all of the available CPU power. Exceptions include record input monitoring, and apparently when running UAD1 DSP cards, which both prefer a more classic 'Synchronous FX multi-processing' scheme."