WHOA! Something's not right here! (ASIO load)

For years, I’ve been using ASIO4All. With a cheapo 16 bit interface built into my monitors. Yesterday, I bought a Focusrite Scarlett 2i4, and that’s supposed to be really good right? On a project I was working on in the cheapo interface, my Asio load meter was maxing at about half in Cubase 8.5 Pro. ASIO4all buffer was about 800 ms or so. I just opened the same project using with the Focusrite Scarlett…AND THE ASIO METER IS NEARLY MAXED OUT! WHAT? Same number of effects, same everything. Just with what’s supposed to be a better interface.

Is there something I should try to get the Asio meter load down? This is off.

Windows 10 x64
12 GB DDR3 ram
7200 rpm HDDs
Core i7 3770

Which ASIO driver are you using? if you have a proprietary one for the 2i4 then it’s probably a good idea to use that as it will be specifically written for that device and not a generic driver such as asio4all.

After a very quick google i found this… https://us.focusrite.com/usb-audio-interfaces/scarlett-2i4/downloads it’s the latest driver.
Also once you have the 2i4 driver installed/selected take a look at your buffer size to make sure it’s not too small.

It’s also worth spending a bit of time learning to understand your setup a little better as it will save you a LOT of time and potential headaches down the line.

Hi,

Also check, the Buffer Size is the same, you used with ASIO4ALL.

Btw, unfortunately from the driver point of view, Focusrite is not very good.

Try disabling ASIO Guard.

I have the latest driver and the buffer is set to it’s maximum, 10ms. I have some heavy FX in there (Thermionik amps, VMRs, a few instances of Bias FX as a pedal board before the Thermionik amps), but that still doesn’t explain why the performance is worse on this “high quality” interface than it was with ASIO4all.

After just trying this, this improved the performance somewhat.

What are some tweaks I could try on my system to improve the overall VST Performance in Cubase?

It’s a bit upsetting that I googled this interface prior to buying it (for reviews), and I’m just now hearing about bad USB drivers post-purchase. D’oh!

HI again…
Hmm that’s quite disappointing for you that the asio4all gives better performance then the propitiatory driver… Martin j above appears to know more about focus rite drivers than myself… he’s an extremely knowledgable guy so i would believe what he says.
This is the main reason i use a PCIe interface because of the insanely low latency it provides even at high loads… but that’s of no comfort to you unfortunately.
If there is a focusrite forum i think i would either start or join an existing ‘moan’ post or possibly email them to complain, i’d be ashamed and embarrassed if i were them that asio4all outperforms their own driver!
I’d be inclined to use the freeze and render in place options, you should be able to run insane amounts of VMR… i have all the modules and frequently run well over fifty or instances with other plugins as they are insanely light on resources, i can’t comment on your other plugs though.
I’m guessing your interface is on it’s own USB bus allowing you to utilise all the bandwidth on that bus?

If you haven’t had the device for very long perhaps you could return it for a refund?

If you MUST go the USB route it’s well worth checking out one of the RME BabyFace line…

Hi.
You said you have your buffer set to maximum, 10 ms.
That seems pretty low buffer setting to me. Compared to 800 ms with asio4all in your first post.

I apologise if I misread something but maybe you could check the buffer settings again.

The maximum the Focusrite driver allows is 10ms. I hear it used to go to 20ms, but then it was limited. I have a big feeling that this is the source of my problem.

The good part: I’m using ASIO4All with the Scarlett on the same buffer and am getting better performance than I was with the Scarlett’s proprietary driver. Seriously.

The bad part: I can’t go above 44.1khz sample rate in ASIO4All, correct me I’m wrong. It’ll have to do though, at least for a while. I’m not happy that I’ll have to upgrade this, but that’s the kind of world we live in.

Is there an official Focusrite forum where I can report this? I feel I should say something about a free Asio driver outperforming a driver made for a $279 audio interface. That’s utterly ridiculous.

This is the closest thing i can find Focusrite Forums - Audiofanzine

I would look at your whole system setup very closely and follow recommended setup instructins. What setup did you do to your BIOS? Cubase and ASIO is dependant on certain things properly setup.

For USB troubles, you could try variation in the driver there as well such a other known good driver. Just a shot in the dark.

My current system is a custom build. The mobo is a Gigabyte B75M-D3H and I never really messed with the BIOS (this is actually a Dual Bios mobo). Are there any suggested tweaks that I should do?

Try to check your system by LatencyMon utility.

Hi all

This does seem somewhat strange, I recently purchased a Scarlett 18i8 for live use and got excellent performance with my stage laptop (in 2.4 ghz quad core) with latency at the best possible setting of 1ms with Focusrite’s ASIO driver. Have you tried it at a faster setting? I did once have a situation where performance degraded with a larger buffer setting

Hope you sort it

Best regards

Dave

Hi xphen0m,

I Have a Scarlett 2i4 which is working incredibly well with my really cheap old i5 computer. Are you using the 3.2.2 driver because it’s great? http://beta.focusrite.com/

When recording my midi parts via my keyboard I set my buffer size to 128 samples which gives me an input/output latency of 9.146 ms which is Ok for recording and when I’ve finished recording all the parts I reset the buffer size to 2048 samples for playing back and mixing and mastering and everything works like a dream!

Hope this helps?

Kind regards

James Colah

http://www.twitter.com/jamescolah

Power-saving and CPU-throttling turned out to be the cause of the high ASIO levels I had when I bought this machine. They were defaulted to save-the-planet mode, which, while worthy, isn’t Cubase-friendly. I ended up changing C-State OFF, SpeedStep ON, TurboBoost OFF, I even messed with the Hyperthreading setting, so maybe you should look for equivalents on your machine and change them one at a time to see what works. Since then Cubase has run like a dream and I can throw anything at it…

Most guides seem to recommend both C-States and Speedstep off in the bios.

USB selective suspend disabling is important with usb interfaces (in win advanced power settings) and disabling core parking (needs a registry tweak) may help.

But there is some confusion from the OP as to the Focusrite settings…there is no such thing as this 10ms max setting as they describe. The buffers are in samples and as James pointed out go at least up to 2048 which would give much higher than 10ms latency.

Here’s the summary


CONCLUSION


Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for 0:01:47 (h:mm:ss) on all processors.

\


SYSTEM INFORMATION


Computer name: DESKTOP-F3O6VTK
OS version: Windows 8 , 6.2, build: 9200 (x64)
Hardware: Gigabyte Technology Co., Ltd., B75M-D3H
CPU: GenuineIntel Intel(R) Core™ i7-3770 CPU @ 3.40GHz
Logical processors: 8
Processor groups: 1
RAM: 12163 MB total

\


CPU SPEED


Reported CPU speed: 3392 MHz
Measured CPU speed: 1 MHz (approx.)

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.

WARNING: the CPU speed that was measured is only a fraction of the CPU speed reported. Your CPUs may be throttled back due to variable speed settings and thermal issues. It is suggested that you run a utility which reports your actual CPU frequency and temperature.


\


MEASURED INTERRUPT TO USER PROCESS LATENCIES


The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 112.291988
Average measured interrupt to process latency (µs): 3.821007

Highest measured interrupt to DPC latency (µs): 110.782687
Average measured interrupt to DPC latency (µs): 1.115504

\


REPORTED ISRs


Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs): 18.581368
Driver with highest ISR routine execution time: ataport.SYS - ATAPI Driver Extension, Microsoft Corporation

Highest reported total ISR routine time (%): 0.002264
Driver with highest ISR total time: ataport.SYS - ATAPI Driver Extension, Microsoft Corporation

Total time spent in ISRs (%) 0.004134

ISR count (execution time <250 µs): 7260
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 0
ISR count (execution time 1000-1999 µs): 0
ISR count (execution time 2000-3999 µs): 0
ISR count (execution time >=4000 µs): 0

\


REPORTED DPCs


DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs): 180.077830
Driver with highest DPC routine execution time: tcpip.sys - TCP/IP Driver, Microsoft Corporation

Highest reported total DPC routine time (%): 0.007515
Driver with highest DPC total execution time: rspLLL64.sys - Resplendence Latency Monitoring and Auxiliary Kernel Library, Resplendence Software Projects Sp.

Total time spent in DPCs (%) 0.041861

DPC count (execution time <250 µs): 112605
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 0
DPC count (execution time 1000-1999 µs): 0
DPC count (execution time 2000-3999 µs): 0
DPC count (execution time >=4000 µs): 0

\


REPORTED HARD PAGEFAULTS


Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count: latmon.exe

Total number of hard pagefaults 82
Hard pagefault count of hardest hit process: 66
Highest hard pagefault resolution time (µs): 129776.451061
Total time spent in hard pagefaults (%): 0.137024
Number of processes hit: 3

\


PER CPU DATA


CPU 0 Interrupt cycle time (s): 0.561307
CPU 0 ISR highest execution time (µs): 18.581368
CPU 0 ISR total execution time (s): 0.035552
CPU 0 ISR count: 7260
CPU 0 DPC highest execution time (µs): 115.589033
CPU 0 DPC total execution time (s): 0.272475
CPU 0 DPC count: 94016


CPU 1 Interrupt cycle time (s): 0.220351
CPU 1 ISR highest execution time (µs): 0.0
CPU 1 ISR total execution time (s): 0.0
CPU 1 ISR count: 0
CPU 1 DPC highest execution time (µs): 89.705189
CPU 1 DPC total execution time (s): 0.003440
CPU 1 DPC count: 1192


CPU 2 Interrupt cycle time (s): 0.214136
CPU 2 ISR highest execution time (µs): 0.0
CPU 2 ISR total execution time (s): 0.0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 122.099057
CPU 2 DPC total execution time (s): 0.012594
CPU 2 DPC count: 3406


CPU 3 Interrupt cycle time (s): 0.202204
CPU 3 ISR highest execution time (µs): 0.0
CPU 3 ISR total execution time (s): 0.0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 106.559552
CPU 3 DPC total execution time (s): 0.006216
CPU 3 DPC count: 1716


CPU 4 Interrupt cycle time (s): 0.207690
CPU 4 ISR highest execution time (µs): 0.0
CPU 4 ISR total execution time (s): 0.0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 180.077830
CPU 4 DPC total execution time (s): 0.017204
CPU 4 DPC count: 3778


CPU 5 Interrupt cycle time (s): 0.197291
CPU 5 ISR highest execution time (µs): 0.0
CPU 5 ISR total execution time (s): 0.0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 88.614387
CPU 5 DPC total execution time (s): 0.006027
CPU 5 DPC count: 1399


CPU 6 Interrupt cycle time (s): 0.218322
CPU 6 ISR highest execution time (µs): 0.0
CPU 6 ISR total execution time (s): 0.0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 147.978184
CPU 6 DPC total execution time (s): 0.027459
CPU 6 DPC count: 4838


CPU 7 Interrupt cycle time (s): 0.204135
CPU 7 ISR highest execution time (µs): 0.0
CPU 7 ISR total execution time (s): 0.0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 173.798349
CPU 7 DPC total execution time (s): 0.014591
CPU 7 DPC count: 2260


The drivers screen looked like this: Dropbox - latmonsnippet.PNG - Simplify your life

So, disabling C-States and Speedstep didn’t really offer an increase in performance on my end.

I’m testing the beta driver and it seems to offer a little relief but I need to do further testing. My VST performance maxes out completely at anything higher than 44.1 khz. Even at 48khz. But I need to do further testing with the beta driver.

I’m starting to partially chalk this up to some of the effects I’m running. When I’m recording, I do some minor mixing along the way and this helps me mix better when I’m done recording. For an example, on a guitar track or bus I have this:

Bias FX (as a pedal board) → Kazrog Thermionik (any one of the amps) → Recabinet 5 → (and in some tracks) Amplitube 3 for post effects. Then VMR following all this on each track/bus. In this particular project I’m testing with, I have 4 track instances like this.

It’s just strange that ASIO4All performed better with this.

The beta driver linked in an above post wasn’t good with this at a lower buffer setting. I’m really discombobulated right now so I apologize if I’m not making any sense. :S

Use the freeze function until you’re ready to mix down proper… that’s what it’s there for… same as render in place… also up your buffer size when you mix too.
If i’m working with a midi drummer then i’ll drop the buffer to 32 samples for them as they generally need the lowest latency possible for obvious reasons, then turn your buffer up to a much higher amount when you’re ready to do your final mix… when mixing i usually set mine to 2048 samples to give me loads of ASIO headroom.