Jim Roseberry

On 8/10/2019 at 5:27 PM, Pete Brown said:

Noel ping me about this thread.

We released a fix for the ntoskrnl 1903 very high DPC latency issue late last month. Not all of these things make it into announcement posts, so follow me on Twitter if you want info earlier.

If after installing that (or the roll-up that contains it), you still get high latency spikes, it's likely something else. Best way to diagnose that is to take a glitch trace and make us aware of it by sending me a link to the Feedback Hub entry.

Instructions are on Matthew's blog. Make sure you can hear the glitch when taking the log/trace. Sometimes we get traces with no audio, and that doesn't help.

https://matthewvaneerde.wordpress.com/2016/09/26/report-problems-with-logs-and-suggest-features-with-the-feedback-hub/

Hi Pete,

The latest Win10 install discs are version 1903.

Installing on socket 1151/Z390 based machines (numerous different motherboards), with all available patches (thru Windows Update procedure), high DPC Latency persists.  

Installing from an older Win10 disc, there are no DPC Latency issues with v1803 or v1809.

I've downloaded the KB4505903 fix from your link above... and will test to see if that resolves the issue.

We appreciate your presence here on the forums!

On 8/10/2019 at 9:00 AM, Noel Borthwick said:

@Jim Roseberry have you filed a feedback hub report? @Pete Brown may be able to follow up.

Hi Noel,

I have not filed a feedback hub report.  

I'll do so ASAP.

On 8/10/2019 at 7:25 AM, Ze Carlos said:

Yes. I find myself using the PDC button very often . I usually use a desktop computer but i have a better and faster laptop also with the 1903 build and the latency issue is not that noticeable.

FWIW, Don't confuse DPC Latency with Audio Latency (two completely different things).

You need low/consistent DPC Latency to effectively work at low audio latency settings.

All popular DAW applications feature Automatic Plugin Delay Compensation (Automatic PDC).

If a latent plugin is inserted *anywhere* in a project, all other audio is delayed by that amount (to maintain sample-accurate sync).

There are two ways to work around the issue:

• While tracking, avoid latent plugins
• CbB (Sonar) has a global Automatic PDC bypass feature (enable this while tracking)

Latency has but two sources (unless the DAW application itself uses additional buffering):

• Audio Interface
• Latent Plugins

Some DAW applications use extra buffering (which adds additional latency).

Ableton Live uses additional buffering (which can't be disabled).

Cubase has "ASIO Guard" (which can be disabled)

StudioOne has "Dropout Protection" (allows setting the additional buffer size from 128-samples up to 2048-samples - the green Z button bypasses the extra buffer)

Though not directly related to your issue, Win10 build 1903 has been problematic on many current build machines.

High DPC Latency...

If you have a Yamaha keyboard (Montage, ModX), it can function as both a MIDI controller and audio interface.

Yamaha owns Steinberg... and users their audio interface/driver technology.

When you load the drivers for your Yamaha keyboard, the "Yamaha Steinberg USB Driver is installed".

FWIW, I've seen a similar issue when a Windows update was (first) released.

In the short-term, had to roll-back to the previous Windows build (everything then worked fine).

Long-term, the issue was resolved.

Any meta-data embedded with the kick sample?

Does it happen with any kick sample... or just a particular sample/library?

If you're talking loops, they're being time stretched/compressed to match the current project's tempo.

I'd try deleting the Aud.ini file (stores information about audio settings)... then re-open CbB and see if the issue persists.

If it were TI, it would mention it in Device Manager.

Yeah, it's most likely a Via or Ricoh chipset Firewire controller.

In the meantime, if you go to Preferences>Audio Driver>ASIO Panel... and change the ASIO buffer size (to another value and then back to what it was), this may clear the distortion without having to close CbB (Sonar).

Are you using a TI chipset (Texas Instrument) Firewire controller?

In almost every case regarding a problem with a Firewire audio interface, the end-user isn't using a TI chipset Firewire controller.

On 8/4/2019 at 4:51 AM, Ludwig Bouwer said:

So my question is this: Which components do I need to take a look at to improve each of the following scenarios?
1: Faster Bouncing and Freezing of tracks
2: Faster Loading of projects with large plugin and track counts.
3: Ability to run more tracks and plugins before buffer has to be enlarged

• Effects count - processor speed is the largest factor
• Track count - disk speed is the largest factor

1.  Faster bouncing/freezing of tracks would be mostly down to CPU speed.

2.  Faster loading of projects would be affected by disk speed and CPU speed.  If you're dealing with large sample-libraries (that load particularly slow), you can put those on a M.2 Ultra SSD (sustain ~3500Mb/Sec).

3.  Ability to run more tracks and plugins (as you can probably guess) is down to faster disk-speed and faster CPU.

As a point of reference:

• Conventional HD sustains ~200Mb/Sec
• SATA SSD sustains ~540MB/Sec
• M.2 Ultra SSD (using 4 PCIe lanes) sustains ~3500Mb/Sec

When it comes to CPU speed:

Not all processes in a DAW can be multi-threaded.

• Playing/monitoring in realtime thru an AmpSim plugin at 96k using a 32-sample ASIO buffer size... isn't something that lends itself to being heavily multi-threaded
• Some plugins/instruments like UVI Falcon only use a single core

This is why clock-speed is the single most critical factor when choosing a CPU for DAW purposes.

Note that CPU core performance  doesn't scale 1:1 

IOW, Doubling the number of CPU cores doesn't double performance.

Having more cores is beneficial... but not at the expense of significant clock-speed.

This is why Xeon CPUs are typically a poor choice for DAW purposes.  They have more cores... but often significantly slower clock-speed (resulting in significant performance hit).

In a perfect scenario, you want highest available clock-speed... and the most cores you can get.

5 minutes ago, pwalpwal said:

i do this by default on almost every track...

It's one simple thing that can make a HUGE difference in the clarity of your mixes.

One use of EQ before compression is to use a high-pass filter (to roll out unwanted low frequencies).

Doing this prior to compression can ensure the compressor doesn't respond to those (unwanted) low-end frequencies.

Unfortunately, Steinberg installs the Generic Low Latency ASIO driver (by default).

This driver can bump your desired ASIO driver out of position.

IOW, If the proper RME ASIO driver was selected in CbB, it may now be "bumped" out of place (leaving the Generic ASIO driver as the selected driver).

In the locations scook mentioned above, delete the Generic ASIO driver entry:

• HKEY_LOCAL_MACHINE\SOFTWARE\ASIO
• HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ASIO

Once deleted, no application can see/select the Generic ASIO driver.

This works for ANY ASIO driver you don't want to use.

ie:  Many hardware guitar processors, drum modules, and synths now function as an ASIO audio interface.

If you know you never want to use your Helix, AxeFX, GT-1000, TD-50, Montage, etc... as an audio interface, this is a quick/easy solution.

Latency has but two sources:

• Audio Interface
• Latent Plugins

If sounds like you're trying to monitor via software (vs. the audio interface's onboard hardware based mixing which is close to zero latency).

If that's the case, you're dealing with round-trip latency.

Round-trip latency is the sum of the following:

• ASIO input buffer
• ASIO output buffer
• The driver's (often hidden) "Safety" (sometimes called "Streaming") buffer
• Latency of the A/D and D/A converters

To reduce Round-Trip Latency:

• Set your ASIO buffer size as small as possible
• If the audio interface allows you to change the Safety Buffer size, set it as small as possible
• You can also reduce round-trip latency by using higher sample-rates

Note that reducing Round-Trip Latency comes are the expense of higher CPU use.

Regarding Latent Plugins:

All popular DAW applications feature Automatic Plugin Delay Compensation.

If you have a latent plugin inserted ANYWHERE in the project, Automatic Plugin Delay Compensation (Automatic PDC) delays all other audio to maintain sample-accurate sync.  

To work around this issue:

• Avoid latent plugins while tracking
• Some DAW applications feature a global PDC bypass feature (enable this when tracking)

You can remove short spots of digital and analog clipping.

What you can't do is take a constantly/heavily saturated recording (like distorted guitar) and remove it.

Samplitude Pro X Suite comes with declipping capabilities.

There's also Izotope Rx.

My advice...

If you want a smoother ride, stay on the backside of the update wave.

If you ride the crest, sometimes you're gonna wipe-out.   (cue that tom intro)

14 hours ago, Davydh said:

What about virtual instruments? What's the latency like with them?

When playing virtual-instruments, you're dealing with one-way (Playback) Latency.

Playback latency is (roughly) half the total round-trip latency. 

Certainly workable (decent) with the Apollo...

The RME Fireface UFX+ can achieve lower Round-Trip and Playback Latency.

The Presonus Quantum can achieve even lower Round-Trip and Playback Latency than the UFX+. 

If lowest possible latency when using 3rd-party EFX/Instruments is a paramount concern, Apollo isn't the interface you want.

Apollo's forte' is fidelity... and being able to run UAD plugins at ~2ms round-trip latency.

By very definition, ASIO can't use more than 1 audio interface simultaneously.

Some manufacturers get around this by allowing using two (or more) of that same/similar model of audio interface... that each use the same ASIO driver.

IOW, The additional audio interface shows up as more audio I/O... using the same (single) ASIO driver.

You can create an aggregate audio device using ASIO4ALL, but then both devices would need to share a common clock (otherwise tracks would drift apart over time - due to the slight difference between the two clocks).  It's (at best) a half-baked solution.

If you need more I/O, you're infinitely better off getting a single audio interface that has the necessary I/O.

You'll want either the Apollo x8 or x8p.

• x8 has four onboard mic preamps
• x8p has eight onboard mic preamps

Both will allow playing/monitoring thru UAD plugins at ~2ms total round-trip latency (using their  "Unison" technology).

Apollo's only real downside is if you're trying to achieve lowest possible round-trip latency when using 3rd-party plugins.

Apollo can achieve ~3.7ms total round-trip latency.

That's not particularly bad... but you can achieve about the same with a top-tier USB-2 audio interface (ie:  RME Fireface UFX).

14 hours ago, Craig Anderton said:

I hear you, Jim. But with a 64-bit engine, I've found that changing levels on a normalized signal  doesn't really seem to have any impact. 

Hi Craig,

I'm sure the 64Bit mix engine makes any rounding error moot.  😉

With CPU power available today, it seems unnecessary to make Normalize a destructive process.

I'd like to see (per-clip) Normalization and Static Gain... as those features combined would (non-destructively) address any Normalization need... and allow quick means to level out a performance.

13 hours ago, msmcleod said:

Actually, this is a really good idea.

Even if the clip gain was tied to a normalization function, that would work really well. So you could "soft" normalize the signal to -3db, and it would automatically adjust the clip gain accordingly.

I agree.   

Non-destructive Normalize and Static Clip Gain should be tied together.

Make it so!    

FWIW, Thunderbolt-3 is rock-solid on the PC side.

I've been running Thunderbolt audio interfaces on PC for a good while (UA Apollo-8 and Satellite, Antelope Zen Tour, RME Fireface UFX+, Presonus Quantum).

All ran flawlessly...

I'm currently using Quantum and UFX+

• Quantum for when I want ultra low round-trip latency
• UFX+ for when I want hardware based monitoring

We have many clients running Thunderbolt audio interfaces.