Asio Fx Processor Level
I'm using the ASIO FX Processor (SpinAudio) VST host along with my guitar. When I load the AmpliTube plugin, all it's ok. In fact, if I turn down the Output Level of AmpiTube, the sound of the preset turns off but then I can hear clearly the dry sound of the guitar. I've read the manuals and tried different. How to minimize latency from my guitar? I recently got myself a Focusrite Scarlett 2i2, really excited to record some stuff in my bedroom. I have BIAS desktop (an amp simulator) running through REAPER, my guitar's hooked up through the Focusrite and it works great.
Has anybody had any experience with ASIO performance under heavy load/processing demands on C7.5? More specifically, can anybody assertain that their multicore CPU capacity is properly utilized by Cubase under high-load conditions? As my standard VSTi template has grown larger over the last year or so, I've also grown more concious that Cubase's processing performance was more easily reaching its max 'capacity', which I define as the point where I start getting real-time audio playback drop-outs. Since moving to C7.5, I decided to formally assess my 'system's capacity'. Two scenarios: Cubase in standalone, and then Cubase with Vienna's VEP5 hosting all my VSTi template (which is the way I traditionally work). I've recently run a lengthy series of tests for the two scenarios (C7.5 standalone, then C7.5+VEP), under same conditions: a number of concurrent audio tracks plus insert FX's, and a number of VSTi's plus insert FX's, and a number of FX's on the master bus.
Fairly simple tests. Then two different set of tests: First, point was to increase number of FX's keeping audio and VSTi tracks fixed until ASIO drop-outs in realtime playing started to show (by hearing and red indicator on Cubase's VST performance meter).
Second, point was to increase number of tracks while keeping FX's fixed. My system: Intel 990X @ 4.34GHz on Intel DX58SO2, 24GB Patriot DDR3 2000, system and multisample/VSTi drives on SSD's, and a couple RAID arrays on SLI card for archiving and multimedia. Running Cubase 7.5 on Win7 x64. Mackie Onyx FireWire 24-bit/48kHz at 128 buffer, 5.4ms latency. On Cubase: Multiprocessing was enabled, ASIO Guard enabled (disabled produced worse performance), audio priority was in 'boost'.
System performance was monitored in several ways, through Cubase's VST performance monitor, using Intel's Extreme Tuning monitor utility, using Windows Resource Monitor. LatencyMon was used before tests to confirm external system drivers/services where not a factor/issue on ASIO latency and performance. Without delving into other details at this point for brevity's sake, my key observations are two-fold: a) C7.5 standalone: I very rarely saw the multicore in-use count go over 2, although VST performance was peaking out. B) C7.5+VEP5: I managed to substantially and importantly increase the VSTi+FX count hosted on VEP before maxing out.
I could see the multi-core count move to 6 during the playback and heavy load. I was even able to add extra audio tracks on C7.5 before maxing out. So VEP as 'middle-ware' proved to be a considerable improvement. Bottom line, my preliminary conclusion is that I'm quite puzzled and very confused about C7.5 multiprocessing capabilities.
Something did not look or feel right, performance was well under what was expected. Has anybody done some research on this? Actual hands-on experience? My observations and preliminary conclusions are based on audible and noticeable drop-outs.
Drop-outs that where visually confirmed on the Cubase VST Performance window. From the Cubase manual, in reference to the VST Performance window:. The “Average Load” indicator shows how much of the available CPU power is used for audio processing. The “Real-time Peak” indicator shows the processing load in the realtime path of the audio engine. On the one hand, there is a CPU-load gauge, on the other, an ASIO-load gauge. Overloads on either one were always associated (audibly confirmed) with drop-outs.
Asio Fx Processor Level 8
So two questions come to mind: 1- on the CPU side, why does the 'Average Load' max out while there is only 2 cores used? (very rarely 3 seen, but still 4 or 3 idle at any time) 2- on the ASIO side, why is Cubase unable to handle VSTi's and FX's to the substantially better extend VEP5 did? I've seen this topic come up several times (and posted about it myself) but am yet to see an answer that is 100% clear. Regarding multithread processing specifically, from my observations (simply looking at the Windows Resource Monitor) all my cores seem to have a roughly equal load. The problem I find is that the the Cubase ASIO meter will max out WAY before the actual CPU will be maxed out. So in other words, a lot of CPU power is going unused. I know, the ASIO METER IS NOT A CPU METER because this is the (unhelpful) response that is always posted when this issue is raised.
But WHAT EXACTLY is the bottleneck here? It's usually blamed on poor ASIO drivers (I run a Steinberg MR816 interface so you would hope it would have a well written driver) but I've read various reports of VE Pro being able to run many extra plugins alongside Cubase so what is it that stops these extra plugins being run within Cubase itself? Why does the ASIO driver allow a higher plugin count when split between two pieces of software as opposed to being run in one single piece of software (i.e. I got burned on another forum by putting this statement online, but i fully agree to the simple fact that combining the VEP with Cubase has much more performance capabilities. What i understood from all the technical replies from developers was that when we use a single DAW with lots and lots of vsti's they (the vsti's) all call for some kind of priority at the same time with a result of peaking asio metering, (a kind of bottleneck) and that this is not the case with VEP where you actually divide the vsts over several servers and instances who handle these priority callings in a (and there seemed to be consensus) very well controlled way trough servers.
Processor Level 15
So it seems that the system setup that VEP gives you is a unique way (for the moment) of handling your VSTI's so that they are spread 'well balanced over the different available cores'. It seems that the vienna guys really do have a winner here with their VEP.
And fact is: they know that too and are asking quite a lot of monney for a vst host. But i indeed love the VEP. VEP seems to be the king of the vst-hosts for the moment. Roel, there are a few loose ends that bother me though, and I'd like somebody with more clarity and understanding than ME to try to enlighten ME and those who may also be concerned about this.
My test used a SINGLE instance of VEP, hosted on my main DAW PC, concurrently with C7.5. No extra servers, no extra instances, no extra audio interfaces, no extra processing power whatsoever. Yet, the performance improvement was substantial. Not 10%, not 20%, not 30%. In rough terms, again without delving into the details for simplicity sake, I managed to more than double the number of insert FX's used on the VSTi's hosted in VEP, plus extra master bus FX's on VEP, plus added several extra audio tracks in Cubase. This is why I undoubtedly call it substantial.
BTW, I actually have a good amount of documented evidence (including screen snapshots) of my tests, should we reach a point they may aid the discussion. Yet, even after my somewhat extensive browsing of the topic on here, and other technical sources, I have yet to find any reasonably solid reference addressing this topic in any meaningful extent. This, aside from vague comments here and there that you can easily dismiss for their vagueness/emptiness. Even consulting older Cubase manuals (v5,6), the concept of multithreading/multiprocessor support has always been very lightly addressed on them, and to an extent that makes the topic sound more like an empirical trial and error hidden art than a technically-supported fact-based set of principles and guidelines. Which I find very frustrating and disappointing. I hope you get the correct answer by a techie because i agreed with you on what you said above.
And i was no referring to extra hardware servers but to the 32 and 64 bit servers that are hosting the plugings on your main system. That is the way i use them and that was appointed to me as the reason of the big difference. A more simple test to show you. Start one f.e. Single omnisphere or other very very powerfull synth you have with its most consuming preset. Watch the asio meter slam to the right in cubase.
Now do the same thing with the same vsti loaded in the VEP. Do you seen ANY movement of the asio meter?? Actually: that wouldn't even be possible because the asio handling is not done by cubase but by VEP. But you do have a processor load indicator in VEP itself.
And that one will definitly slam to the right. But.: their you find the difference you notice. VEP doesn't come up in the way the meter slams in cubase.
They actually show different things. Cubase shows ASIO, and VEP shows processor load. But still, and indeed, as you noticed the ASIO performance in cubase reaches its limits way before the processor load is being reached. That is called 'proces management' as i could understand. The best way to compare this is with the taskmanager in windows since this is one tool to measure two different programs. What you probably will notice is that the way the processes are divided over the different cores is completely different whan using VEP than when using Cubase.
That was what i was trying to explain above. It's 'the way' the host handles processes. The fact that VEP uses seperate servers and instances seems an important difference between DAW handling of the same thing. But again: hope we can find a definitive answer, because it is an important one to understand.
Happy musicing, kind regards, R. Not meant to enter into a debate on this, but your use of the terms 'servers' and 'instances' is very confusing to me, specially on your last paragraph. That's why I thought it was worth making my previous clarification. I'm not sure what you mean by separate 'servers and instances'. Technically, to me, that is inaccurate. There was only ONE VEP server in my case, only one instance.
I do, at this point and with the evidence in hand, agree with the notion that VEP seems to handle multithreading substantially better than Cubase. But not sure why. Any of you know ANYTHING about computers at all? In depth I mean (genuinely curious). Have you actually built your own? You're much better off asking this question on another music tech forum.
If you don't actually know much about computer innards then you're only likely to get confused answers here, but you could get lucky. I'd cut and paste the whole question to the Sound on Sound forum, see what discussion you generate and then bring it back here to fine tune your findings if it turns out that the consensus is that Cubase has a screw loose.
Buchanan wrote:Any of you know ANYTHING about computers at all? In depth I mean (genuinely curious). Have you actually built your own? You're much better off asking this question on another music tech forum. If you don't actually know much about computer innards then you're only likely to get confused answers here, but you could get lucky. I'd cut and paste the whole question to the Sound on Sound forum, see what discussion you generate and then bring it back here to fine tune your findings if it turns out that the consensus is that Cubase has a screw loose.
Much more than you may think. And yes to your second one as well, been doing so since after my first PC, a 8088 CPU, really, many ages ago. Not sure I feel any motivated to try your suggestion. Would prefer relying on experiences from real (specialized) Cubase users here than navigating thorugh tons of fluff from a general user base. General user base will know, collectively, a lot more than anyone here about what might cause what you observe other than Cubase. If you just think it's Cubase you might not get far in a hurry in this forum alone.
If you're sure it's Cubase then repost this in the Issues page of the forum. You'll certainly get bitten a lot less on other forums than here and the answers (the meaningful ones) will be easier to understand if, as your reply states, you are used to building your own rigs. Most here just know Cubase whereas others will know whether it's the computer or Cubase and a lot of times will know what would make Cubase behave that way, what wouldn't and how to fix it if it can be fixed.
PS: An awful lot of very knowledgeable Cubase users are on the SoS forum because this forum can get a bit up it's own sack. I have experienced the ASIO meter maxing out whilst there is plenty of CPU power going unused (according to Windows Resource Meter) on more than one computer. In fact, I have just built a new PC (Intel 4930k to replace my i7 920) and both machines show the same behaviour. The ASIO meter hits max and audio starts to break up but the CPU useage might only be at 40% in some cases, and on my setup, that appears to be spread quite evenly on all cores. One common thing is my Steinberg MR816 audio interface but I have read many reports of the same experience from people with various different computer/interface setups.
Hippo wrote:Why do so many people seem to think the AISO meter indication is any thing to do with the CPU meter in windows? Hippo Well I'll quote myself from the post I made in this very thread: J-S-Q 'And yes. I know, the ASIO METER IS NOT A CPU METER because this is the (unhelpful) response that is always posted when this issue is raised. But WHAT EXACTLY is the bottleneck here?'
Well done for being yet another person to post this unhelpful response. Now please explain EXACTLY what it is that is causing Cubase to run out of steam when there is still a lot of CPU power left. Or please explain why, on the same computer, Vienna Ensemble can apparently run 12 instances of Altiverb with no problem when Cubase can only cope with 4. The i7 990X is basically a CPU sold for that purpose, only. Second hint: My tests included a full round of stock conditions trials, following exactly the same methodology. Absolutely the same effect observed.
Just at different capacity levels. Again, please excuse my brevity here, as I said I have a good amount of documented evidence of my tests. So can tell you OC'ing did not influence the overall observation. In return, could I now be humored and explain what kind of mysterious trouble OC'ing may cause? Is that what you've heard or is it your personal experience? I'm not trying to be a prick, I'd just much prefer to speak in clear(er) terms that can lead us, the conversation, this thread, to somewhere helpful and meaningful. Cubase is a great app.
I want to congratulate all of their developers for the work they've rendered. I've paid them money.
I'm willing to pay them more money for future improvements on this product they've created. I'm not sour about the incidental bugs.
I just want to know what we can do to assist the guys at Steinberg at addressing these sort of issues; the kind of issues that are critical for a minority of their user-base. The kind of issues that directly affect my livelihood, and my ability to do this thing that I love: which is to make music without moving the buffer to 512 samples. So please: could somebody at Steinberg let us know how we can help.
This may or may not be relevant to the problems you are having but I noticed a while ago that the way you have your tracks routed makes a HUGE difference to your ASIO meter and your ability to run high plugin counts. In a nutshell, if you have lots of complex Group channel routing with long plugin chains, your ASIO meter will be higher than if you just have lots of individual channels with the same plugins arranged in short chains. I did some tests a while ago (this was with Cubase 7.5). I had a session with the exact same plugins (24 x Waves Kramer Master Tape) and the ASIO load ranged from 15% right up to 100% depending on how the tracks were routed. ASIO meter at 15%, Windows CPU at 15% 24 x stereo tracks, each with 1 instance of KMT, no group tracks. ASIO meter at 45%, Windows CPU at 11.5% 3 x Stereo tracks, each with 8 KMT instances, no group tracks. ASIO meter at 100%, Windows CPU at 11% 1 Stereo track, with 8 KMT's, routed to two groups in series, each with 8 KMT's.
A continuous chain of 24 Kramer instances. J-S-Q wrote:This may or may not be relevant to the problems you are having but I noticed a while ago that the way you have your tracks routed makes a HUGE difference to your ASIO meter and your ability to run high plugin counts. In a nutshell, if you have lots of complex Group channel routing with long plugin chains, your ASIO meter will be higher than if you just have lots of individual channels with the same plugins arranged in short chains.
I did some tests a while ago (this was with Cubase 7.5). I had a session with the exact same plugins (24 x Waves Kramer Master Tape) and the ASIO load ranged from 15% right up to 100% depending on how the tracks were routed. ASIO meter at 15%, Windows CPU at 15% 24 x stereo tracks, each with 1 instance of KMT, no group tracks. ASIO meter at 45%, Windows CPU at 11.5% 3 x Stereo tracks, each with 8 KMT instances, no group tracks. ASIO meter at 100%, Windows CPU at 11% 1 Stereo track, with 8 KMT's, routed to two groups in series, each with 8 KMT's. A continuous chain of 24 Kramer instances.
Thanks for that. Unfortunately there are sometimes no way to get around complex group routings, etc., and I feel that Cubase should be able to handle whatever you throw at it, just like PT and Reaper do on the same system here (I'm sure you agree with that, I'm just saying it to say it).
Absolutely I agree with you. I think it's clear that there's room for improvement with multithread handling in Cubase.
Yeah I'd be angry too. I built a new PC a couple of years ago and didn't get as much horsepower increase as I was expecting although I did at least get a reasonable improvement. I gotta say, I've heard several people recommend that you go for clock speed rather than core count when it comes to a CPU for DAW use and this thread supports that statement for sure. Does the 12 core outperform the 4 core in a straightforward plugin count test.
How many Ozones can it run when you have individual tracks with one instance per track, and no group routing etc? Not a very real world situation but I would have thought the 12 core wins hands down here. When you're comparing Reaper and Pro Tools plugin counts, is the routing/channel setup the same as what you are doing in Cubase?
Just going from memory, on the DAWbench website, Cubase was one of, if not THE best at plugin counts but that's going back a few years. Peakae wrote:To me it looks like Cubase is only using 1 thread to process each track. One track or channel with a lot of plugins could max out the computer.
If possible it could worth a try, distributing the plugins over more tracks. For example routing all tracks to one or more group tracks and distributing the plugins you normally would use on the master between them. I'm going to try it when I got some time on my hands again. Well yes, I think that's what is shown by the testing that I posted above. It seems that whatever is the complete path of a signal has to be processed by a one core. If you have a channel with some plugins and you route it to a group that also has plugins, that complete chain of plugins has to be assigned to a single core. This means that if you have a long plugin chain through various groups, you can max out the ASIO of a 12 core CPU even if 11 of the cores are completely idle.
Actually I suspect any group channel gets assigned an own thread, thereby distributing the CPU load more evenly. But I'm only guessing here, have to actually test it on some projects that are running near max ASIO load. I have been playing around with Halion Sonic, trying the different number of cores that it is allowed to use, that can make a huge difference depending on the number of instances. A better thread distribution inside Cubase would be appreciated and the only real solution, when comes to workflow and ease of use. I just don't see it coming anytime soon.:-/. Peakae wrote:Actually I suspect any group channel gets assigned an own thread, thereby distributing the CPU load more evenly. Just from my brief tests, I'm don't believe that's right.
As per the tests I posted above, you can see a clear difference in ASIO load when you have the exact same plugins in a group routing situation versus having them just on individual tracks. If I remember rightly, when you make a long chain of plugins running via a group or two with nothing else in the session, you can see a single core being heavily loaded whilst the others are virtually idle. The same seems to apply for FX tracks as well. Take a track full of plugins send it to an FX channel and the whole lot gets loaded up onto one core. Just did another quick test. Empty project, with one audio track and one FX track, both of which have 8 x Kramer Master Tape.
See the attached CPU monitor picture. Whilst the session is playing, CPU 0 is loaded at about 55%. As soon as I enable the Aux send (so the signal passes through all 16 plugins), the load goes up to 100% yet all the other cores remain very lightly loaded. I switch the aux send off and the load drops again as you can see in the picture.
This is just one example, I can't say that this happens ALL THE TIME but speaking as someone who knows very little about computer coding, it doesn't look like the most efficient way of doing things. Attachments (45.4 KiB) Not downloaded yet. Intersting (I made that other post to the Nuendo forum). The detail and comments here about groups & routing etc. Shall check that. It would be fair to say that most of my material is indeed sub-grouped & also making for bounce /export stems ease etc etc. BTW, also agree about the earlier comment about 'CPU speed vs.
In my experience that has been true & in an earlier MP 5,1 I used a 3.33GHz 6 core for exactly that reason. On my 'new' MP however ( a custom refurb) I took this into account and it is a 3.33 GHz 12 core (i.e., identical CPU horsepower); I also went with 6 x Ram slots (48GB) which is recommended as having performance improvements for this machine (6 ram slots vs.
Anyways, the point is that the CPU speeds are identical, the cores doubled, but with apparently no significant performance improvement on Cubase or Nuendo. I did a quick test that has me a bit confused. I ran 20 tracks filled with plug-ins and everything in the strip, 2 groups and 5 fx tracks a total of 225 plugins the 23 of them Ozone 7 on IRC4. The ASIO meter around 85% and the CPU around 75% NO DROPOUTS That is leaves me with one conclusion the ASIO meter is pretty logarithmic, as the same project with a modest 37 plugins shows ASIO around 50% CPU is around 27%. I have to investigate some more, but at least I now know that I can use a lot more plugins than i thought. I7 3770K 3.5Ghz @ 4Ghz I should add.
FWW, did some tests with a VI-only project: with and without auxs and groups. Can't say I found any appreciable performance differences (at least, as identified by the Steinberg performance meters or the Apple Activity Monitor). Cubase forum seems to indicate otherwise, but has't been my experience. I did notice however that Cubase 8.5 seems to do a little better with overall CPU load than Neundo 7 for the same project. Possibly newer code. Otherwise, the 'threading metering' is a little odd: all 12 cores seem equally engaged (vs, different cores showing different loads, some with none etc say like Pro Tools), and, when viewing the 24 'threads' the second thread of each CPU shows as doing bugger-all.
The CPU readout on Apple activity monitor, this would seem to show that there's till a lot of Ram and CPU left idle in the background. One solution that works fine is to rewire slave another DAW as host for VIs etc: Ableton Live or Reaper for example. That certainly puts some serious VI grunt into the system. Anyways, overall I see as just an interesting sideline really.
Nuendo in general is very pleasing to work with overall in my experience. BTW, the Rewire implementation is the best I've used. Just to give some more perspective. As an example of a real world situation, I’ve attached a picture of core loading on the session I’m working on right now. The 12 cores are fairly evenly loaded in this example -all at about 35-65%, with the ASIO meter at about 75%.
(This is a session with 160 tracks including 16 Groups and 12 FX Tracks). Going back a few years, there are lots of tests on DAWBench.com showing Cubase to be competitive with other DAWs on CPU efficiency and often coming out the winner. Maybe just in the last few years, other DAWs have advanced in this department and we now have to wait for Cubase to make an advance and be back on top! I guess it’s a constant arms race and don’t forget, Pro Tools had a revised audio engine quite recently so one might expect it to be ahead in the game right now. I know this is bad timing as you have just bought a new Mac but if you ONLY want to be concerned with plugin counts, DAWBench tests consistently suggested Cubase can run a lot more plugins on Windows. Again, that is going back a few years and obviously there are many other reasons why one might prefer Mac (and I do think it’s a nicer OS myself which is why I’m typing this on a MacBook!). Attachments (63.35 KiB) Not downloaded yet.
BasariStudios wrote:Has anyone noticed that Stiny does not show up here, or on my Thread or on GS or any Topic or Forum that has to do with this particular issue. Imagine how many technical questions people here asked and yet no word nothing, not even a HI nor SCREW YOU GUYS WHO CARES. I don't think it's realistic to expect them to come on this thread and officially say 'Yes, our engine is not as good as our rivals, we're working on that.' No i did not mean that.i meant something normal as any developer, to ask question, to point out things, to do some tests, to send some projects out and stuff. I posted 3 images below from what i did with Latency Monitor test.this stupid dxkrnl.sys thing and one more next to it always shows up on the test.
So you know, my Intel Speed Step is disabled, i don't know why LM mentions it. Now, The whole time my computer is able to perform, that is what LM tells me, the pops happen only when i stop playback or start touching things on the computer.someone who knows computers better please take a look at the images. Thanks Attachments (74.46 KiB) Not downloaded yet (235.95 KiB) Not downloaded yet (148.98 KiB) Not downloaded yet.
1) 'Georg: At the moment, Cubase and Nuendo share their source code for the most part'. 2) There are many reasons why Pro Tools has become the industry standard, but two of the main reasons seemed to be the 'guaranteed processing capacity' and 'I/O latency for professional use' that came with the use of the dedicated DSP card. 3) My main point is that I always find it strange that manufacturers of native processing DAW software do not seem to be making any serious efforts to resolve issues related to latency.
In that regard, they still rely on direct monitoring of the audio interface. In terms of processing power, computers have become more than fast enough, and there is always the option of selecting Universal Audio's UAD if processing power is still insufficient. If only issues related to latency can be overcome, native processing DAW could become a system that could take on Pro Tools HDX. 4) Clyde: This is a very interesting question indeed. The first point I would like to highlight is that as of Cubase Pro 8, we have introduced ASIO-Guard 2 that minimizes input and output latency to a minimum 32 samples. Minimizing latency down to this level was simply not possible with previous versions.I do need to clarify one point here, and that is about not taking issues related to latency seriously.
Overcoming this problem is one of the topics that we have focused on the most over the past few years. Unfortunately I am unable to provide any more details today. Please wait to see what the future has in store for Cubase and Nuendo. FWIW, I find this somewhat misdirected: ASIO guard is about input latency and as they indicate, most now use inout monitoring and an audio interfaces that increasingly allow much control of that process, e.g.: RME, UAD etc with 'print to tape FX if required etc etc. Chasing the necessity to lower input monitoring latency through the DAW would seem well off topic these days & monitoring off-source is old school (to vs from tape), worked well then, works well now. I'd get over that one and concentrate on the mix, routing, output and CPU overheads associated with pretending that a DAW is a studio. Back to the point of this thread: less about ASIO & input buffer then; more focus on multithreading and mix down power and clearly this is where Cubase /Neuendo lag against ProTools, Logic, Reaper and the rest.