You are here

ASIO drivers - CPU and efficiency - Stability

For anything relating to music-making on Windows computers, with lots of FAQs. Moderated by Martin Walker.

ASIO drivers - CPU and efficiency - Stability

Postby SafeandSound Mastering » Sun Jun 18, 2017 11:47 am

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)
User avatar
SafeandSound Mastering
Frequent Poster
Posts: 1063
Joined: Sun Mar 23, 2008 12:00 am
Location: South East
 

Re: ASIO drivers - CPU and efficiency - Stability

Postby mashedmitten » Sun Jun 18, 2017 12:06 pm

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.
mashedmitten
Frequent Poster
Posts: 713
Joined: Tue Jul 19, 2016 11:42 pm
Nate

My sole goal in life is to make people projectile spew their beverages, from mouth and nostrils, all over their screens, keyboards, themselves and others, over my incessant bollox.
 

Re: ASIO drivers - CPU and efficiency - Stability

Postby SafeandSound Mastering » Sun Jun 18, 2017 12:46 pm

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.
User avatar
SafeandSound Mastering
Frequent Poster
Posts: 1063
Joined: Sun Mar 23, 2008 12:00 am
Location: South East
 

Re: ASIO drivers - CPU and efficiency - Stability

Postby mashedmitten » Sun Jun 18, 2017 1:25 pm

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. :lol:
mashedmitten
Frequent Poster
Posts: 713
Joined: Tue Jul 19, 2016 11:42 pm
Nate

My sole goal in life is to make people projectile spew their beverages, from mouth and nostrils, all over their screens, keyboards, themselves and others, over my incessant bollox.
 

Re: ASIO drivers - CPU and efficiency - Stability

Postby CS70 » Sun Jun 18, 2017 10:10 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.
User avatar
CS70
Frequent Poster
Posts: 1804
Joined: Mon Nov 26, 2012 12:00 am
Location: Oslo, Norway
Silver Spoon - Check out our latest video  and the FB page

Re: ASIO drivers - CPU and efficiency - Stability

Postby ef37a » Mon Jun 19, 2017 7:54 am

Thanks CS70. Phew! 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.

Dave.
ef37a
Jedi Poster
Posts: 7816
Joined: Sun May 28, 2006 11:00 pm
Location: northampton uk

Re: ASIO drivers - CPU and efficiency - Stability

Postby SafeandSound Mastering » Mon Jun 19, 2017 10:42 am

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. 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)
User avatar
SafeandSound Mastering
Frequent Poster
Posts: 1063
Joined: Sun Mar 23, 2008 12:00 am
Location: South East
 


Who is online

Users browsing this forum: No registered users and 2 guests