• Home

Asio Fx Processor Less Host

 

I was just interested in knowing a little more how ASIO drivers work with the host and their consequence on ASIO metering in Cubase (and other DAW's). Being actually more complex than the buffer-based data exchange, they may be coded in different ways and result in less than nice effects to the final. Demonstrates access to your sound hardware with ASIO drivers. I try the steingberg asio host exemple. REQ: O Deus ASIO Link Pro. This driver allows you to host your real ASIO driver and add. Applications v9r5-R2R SpinAudio asio fx processor se v1.2. VST/AU/VST3/ReWire modular plugin host that can.

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.

Host

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.

Asio Fx Processor Less Host Bus Adapter

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.

Processor

Asio Fx Processor Less Hosting

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.

I was just interested in knowing a little more how ASIO drivers work with the host and their consequence on ASIO metering in Cubase (and other DAW's). I have never entirely understood how important a driver could be for overall meter reporting in Cubase (I presume other DAW's also have 'load meters') Also I understand RME have very stable drivers historically (Still the case?) but I have not to my knowledge had any serious issue related to a particularly bad driver so don't know any different really. Ever since my first real audio interface (Event Gina 20 bit - this card was incredible at the time and marked a real turning point - 21 years old) everything has worked pretty well since.

I am wondering if there can be radical difference in a DAW's performance depending on how the driver is coded and if in reality amongst the larger sound card manufacturers if this even 'a thing' in 2017. Are they essentially all on par?

Of late I have become reinvigorated with music PC's, I still favour slotted sound cards as opposed to USB/Firewire etc. (It may be the case this is completely unwarranted, I suppose I am a little old school in this way) I have a very good experience with my fun machine at home - Cubase 9.0.2, a load of softsynths and effects running on Windows 10 - 64 bit of late. (The machine is not even that well specced, 6 year old i7, 16GB RAM) (I also suspect a SCAN built one that I have awaiting to go into service will also blow me away in equal measure) Frequent Poster Posts: 1088 Joined: Sun Mar 23, 2008 12:00 am Location: South East. The difference in drivers is in clock timing and jitter. For audio purposes, bad timing and jitter causes buffers not not get filled correctly, creating a bottleneck, and causing decreased ASIO Performance.

This is also true within the system. If all components in the signal path aren't counting the same, or all lagging/jumping the beat (buffer) ASIO performance will take a hit. When everything's in time and on beat, ASIO performance reflects it. If you've ever had Firewire interfaces but no TI chipset, it's the same principle. The clocks on other chips are junk and performance is junk.

Just like the components of the system have to play nice, same's true for components of the interface so I can see some effect here. The ratio of component quality vs driver quality and how they contribute to the end result of poor performance is a question. I'm guessing price plays a factor in both, but I'm saying drivers are the biggest difference across same level kit. Frequent Poster Posts: 1104 Joined: Tue Jul 19, 2016 11:42 pm.

Asio fx processor less host windows 10

Interesting post, thanks, sounds obvious now you explain it in those terms. (given it is a timing critical data transfer) Jitter is rarely mention in context of anything other than the ADDA hardware conversion normally. I suppose with this kind of thing at host/ASIO/PC chips level we expect it all to be taken care of and why we pay our dough for what we have resarched or hear as producing the best performance and stability. As far as I gather ASIO tries to circumnavigate as much of the OS code and communicate as directly to the hardware as possible. Steinberg has been at the forefront of a lot of developments in this regards.

ASIO/VST/VST3 etc. Quite impressive.

Frequent Poster Posts: 1088 Joined: Sun Mar 23, 2008 12:00 am Location: South East. SafeandSound Mastering wrote:Interesting post, thanks, sounds obvious now you explain it in those terms. (given it is a timing critical data transfer) Jitter is rarely mention in context of anything other than the ADDA hardware conversion normally. I suppose with this kind of thing at host/ASIO/PC chips level we expect it all to be taken care of and why we pay our dough for what we have resarched or hear as producing the best performance and stability. As far as I gather ASIO tries to circumnavigate as much of the OS code and communicate as directly to the hardware as possible. Steinberg has been at the forefront of a lot of developments in this regards. ASIO/VST/VST3 etc.

Quite impressive. A piece of RME kit (for example) is only as good as the system it's connected to. I don't care how good the build or drivers, it can still have poor performance. It's the whole orchestra combined that is the true factor. The Creators Update of W10 is supposed to have improved WASAPI capabilities, a native path through the OS. ASIO is more of a patch or bridge that filled gaps in native audio connectivity, it provided a more direct path than other standards. I'm putting this simply, someone like Pete Kaine from SCAN will hopefully drop by and straighten out my 'mangalation' of the particulars.

Frequent Poster Posts: 1104 Joined: Tue Jul 19, 2016 11:42 pm. SafeandSound Mastering wrote:I was just interested in knowing a little more how ASIO drivers work with the host and their consequence on ASIO metering in Cubase Here's some background on ASIO - boring and long but you can skip to the bottom. ASIO works in a simple way: a channel of audio is a memory area (a 'buffer') which can be accessed by both the DAW and the driver (which does that under control of the interface hardware).

The specific technique is called 'double buffer' - basically you have two buffers and one of the two (DAW/drivers) writes into it one small piece of information at a time; when the other asks for data, the whole information block get copied in one go in the most efficient manner available and writing continues in the other buffer, until the next request. So basically you have the interface consuming data from the buffers for every channel and requesting data for playback every time it needs more. Obviously the more channels you have, the more work the DAW shall do in order to respond to the interface in a timely manner; likewise, the heavier the amount of processing to produce new data for a single channel (for example because of plugins, but also slow disk access or CPU busy elsewhere or interrupted by hi-priority system interrupts), the smaller amounts of channels the DAW will be able to serve.

The combination of these two gives you the playback limit. For recording, it is the opposite - the interface fills the buffers for each recording channel,and the DAW must be as quick as possible to clear them up for new data.

The system limits are given by the number of simultaneous channels to clear up, sample rate, the number of concurrent processes the CPU must attend to and the general I/O speed available to it for moving data elsewhere than the buffer (processor cache, RAM or hard disk for example). The buffer size is also a factor, since the smaller the buffer, the quicker it will be filled up and the driver, on behalf of the interface hardware, will have to decide what to do - discard the new data, overwrite old data etc. The buffer shared memory can be accessed in the regular way or via direct memory access (i.e. Not involving the CPU), depending on the hardware on both motherboard and interface. If the audio hardware uses DMA, this is critical system aspect in PCs because in PCI every device can ask (and obtain) to become the bus master. Without going into too many details, which devices are present and which DMA channels they use, and how the motherboard's chipset arbitrates conflicting DMA requests is pretty critical for performance. That's why disabling components (say, putting the network card in airplane mode) may improve performance - the less components on the pc, the less potential interrupts and DMA conflicts (f the component had any in the first place).

There's a gazillion details of course but short of writing an example of driver it's too long to list them all. Now, to your questions. First, the simple stuff: ASIO doesn't have any particular effect on the DAW metering, as it simply provides the raw sampled data to the DAW which then can do what it wants with it.

For differences in driver performance, the short answer is 'no': there's very little. Since (as of the above) the interaction between DAW and driver/interface via ASIO is pretty straightforward, and given that your pc hardware is set and the interface hardware is set, the driver can't really do much from the performance point of view. It just has to copy memory here and there - there's not really many different (sensible) ways to code it, and it's almost a Programming 101 task. What adds complications is how the driver handles the ancillary stuff: initializations, allocation and de-allocation of memory, requests of audio from different programs, initialization and de-initialization, all stuff that can go wrong because of programmer errors. Being actually more complex than the buffer-based data exchange, they may be coded in different ways and result in less than nice effects to the final user (say clicks when you switch to a new application) to crashes - which at kernel level, mean blue screen. So there you have it.

The great thing about the PC architecture is that it's modular, and the worse thing about the PC architecture is that it's modular. What is important when looking at a pc that does realtime work (including audio) is really the selection of hardware components (paying specific attention to interrupts, DMA and motherboard's southbridge), and the interface producer reputation for closeness to the hardware and focus in fixing things quickly. If the components play well together, most interface will do for a period (so long the driver's bug-free), but their overall longevity will depend on how much the producer (or the chipset vendor) is invested in maintaining and updating drivers in the face of hardware or Windows changes. That's where RME has the upper hand.

Frequent Poster Posts: 2128 Joined: Mon Nov 26, 2012 12:00 am Location: Oslo, Norway. I shall read that again (and again!). Safe': I too started my messings with a PCI card. The M-Audio 2496 bought because of a review (Martin) in SoS of the AP192 card which I could not afford at the time but Martin pointed out that the M-A drivers were good and although the 192 WAS the better interface, there was little in it. My next purchase was an M-A Fast track pro and once again, I had no problems with the drivers (nor the scary 'IRQ' gremlins!). Much later I purchased the Behringer BCA2000, again on the strength of an SoS review (but NOT Martin!).

Crock of. driverwise! After 2 replacement devices and MUCH hassle with Behr's I got it to work but even then you had to start it and the PC in a certain sequence! Eventually the thing failed electronically. I fixed it once, mic pre chip but then could not be a'ed.

Bellringers were no help. Even though the AI was by then discontinued they would not sell me any spares. (anyone want it? Still in loft) Conclusion? The early PCI, even USB (1.1!) stuff had decent drivers, written I suspect by top people. Then the HR fashion hit and all went to H in a money saving handcart. Jedi Poster Posts: 8314 Joined: Sun May 28, 2006 11:00 pm Location: northampton uk.

Nice explanation CS70, top job and long details is fine for me, is that not how we learn something? Great read and explained well. Being a mastering engineer there is of some pressure that you are supposed to know everything. (clearly not even the case when you hear some ME's speaking about digital audio for example) Which is very clearly nonsense, it is specialist yes and the term mastering gives some lofty impressions and yes you have to know your stuff. I am happy to be humble where gaps in my I.T. And computer knowledge are. I have always had a certain awe when it comes to computers and the fact that this computation happens within microseconds and on chips that can have billions of transistors, yes that is right, billions!

That are invisible to the eye. I suppose there is a bit of a human disconnect between things that are imperceptible to human senses. (cycle times, speed, time intervals, physical size, microscopy) An i7 Skylake supposedly having 1,750,000,000 transistors When you look at a screen with 60 tracks of audio (many of which I being calculated to produce complex synthesis in real time) and then you have the ASIO streams behind this. To me it seems if you are not a little in awe of the miracle before your eyes (even though clearly mathematically proven) you are either very hard to impress, don't care, or don't understand enough about why it is miraculous. It is a privelege to have this kind of control of computing power at ones fingertips. I feel this more now in my spare time music productions (pure synth based at this time) as you realize exactly how much you can do in a modern DAW.

Asio Fx Processor Less Host Free

For myself the pinnacle of music technology is having 10-12 incredible sounding synthesisers capable of a gargantuan sonic textures all working along in perfect sync + jaw dropping effects quality. Whether that is modelling of analogue synths of old or new synthesis types in its own right. Truly fascinating. Ef37a - I have gone through a few soundcards over the years.

RME for the mastering side I/O (+ dedicated mastering converters). EMU1820M, a couple of EMU cheapos on internet PC's etc. The Echo Gina 20bit but as above and on the home music systems a fairly old Layla 3G PCI jobby (of which the 64bit Win7 driver seems to be doing very well under Win10 64) In broadcast work I have used the Lynx cards a lot, also very stable historically) Frequent Poster Posts: 1088 Joined: Sun Mar 23, 2008 12:00 am Location: South East.

All contents copyright © SOS Publications Group and/or its licensors, 1985-2017. All rights reserved. The contents of this article are subject to worldwide copyright protection and reproduction in whole or part, whether mechanical or electronic, is expressly forbidden without the prior written consent of the Publishers. Great care has been taken to ensure accuracy in the preparation of this article but neither Sound On Sound Limited nor the publishers can be held responsible for its contents. The views expressed are those of the contributors and not necessarily those of the publishers. Web site designed & maintained by PB Associates & SOS.