Like a 1 second Input Monitoring delay

[Noah Moore]

So I'm trying to hear myself because i'm using autotune but whenever I say something, it sounds more like an echo which totally throws me off beat. I have windows 10 eight core processor 8 GB Ram and its 64 bit op system. I also included photos of my settings from CW. Any help would be greatly appreciated.

 

[ecc83]

So I'm trying to hear myself because i'm using autotune but whenever I say something, it sounds more like an echo which totally throws me off beat. I have windows 10 eight core processor 8 GB Ram and its 64 bit op system. I also included photos of my settings from CW. Any help would be greatly appreciated.

If those screen shots are correct you are NOT using ASIO drivers. Not using the Focusrite AI for playback and are using a 192kHz sampling rate!

Just because a processor has 8 cores does not mean the software or interface uses all or even more than one of them and one poor little core trying to handle 192kHz is going to fail IMHO.

The shots we really need are from the DAW showing the exact driver and sample rate settings and also what is handling the audio.

Dave.

 

[gecko zzed]

Also, turn off autotune when you record. Apply it after if you need to.

You're doing a whole bunch of things that are working against you.

Select 44.1 or 48 khz sampling rate, use ASIO drivers, plug headphones (and speakers) into Focusrite, and record without effects. Keep ti simnple to start with. Once you've got stuff working ok, then you can be more adventurous with settings.

 

[bouldersoundguy]

Using a higher sample rate will tend to reduce latency, unless you're doing some heavy processing like pitch correction. It takes half the time to move the same number of samples at twice the sample rate. But when you add processing that higher sample rate probably starts to work against you since now the CPU has twice as much data to process.

 

[keith.rogers]

Using a higher sample rate will tend to reduce latency, unless you're doing some heavy processing like pitch correction. It takes half the time to move the same number of samples at twice the sample rate. But when you add processing that higher sample rate probably starts to work against you since now the CPU has twice as much data to process.

This makes no sense to me.

At 192kHz sample rate, the bus and computer have to move 4x as much data through any plugins (that are turned on have to process) and write that to disk, vs 48k sample rate over the same 1 second of audio input. No way does that happen faster. As [MENTION=45599]gecko zzed[/MENTION] says, it's asking for trouble.

 

[TalismanRich]

I think the biggest problem is using MME. MME was the first audio driver released when Windows 3.1 was released. Most built-in audio cards run on the MME driver protocol.

Definitely change to an ASIO driver for your Focusrite. ASIO was created to reduce recording latency.

Also, make sure that CW is set to use multithreading, as that will improve performance if its available.

 

[bouldersoundguy]

This makes no sense to me.

At 192kHz sample rate, the bus and computer have to move 4x as much data through any plugins (that are turned on have to process) and write that to disk, vs 48k sample rate over the same 1 second of audio input. No way does that happen faster. As [MENTION=45599]gecko zzed[/MENTION] says, it's asking for trouble.

I addressed that. If it's purely a matter of analog to digital to analog (i.e. direct monitoring), higher sample rates have the potential for lower latency. A buffer of a given number of samples adds half the time at twice the rate. It's only when there's processing involved, especially if the processing requires a trip to the computer's CPU (rather than using processing onboard an interface, e.g. UAD), that higher sample rate have the potential for higher latency due to the greater amount of data. Interfaces that have onboard processing are generally optimized to handle audio at low latency, even when adding effects.

 

[keith.rogers]

I addressed that. If it's purely a matter of analog to digital to analog (i.e. direct monitoring), higher sample rates have the potential for lower latency. A buffer of a given number of samples adds half the time at twice the rate. It's only when there's processing involved, especially if the processing requires a trip to the computer's CPU (rather than using processing onboard an interface, e.g. UAD), that higher sample rate have the potential for higher latency due to the greater amount of data. Interfaces that have onboard processing are generally optimized to handle audio at low latency, even when adding effects.

Hmm, well, the same number of samples at twice the sample rate is, yes, sample half of the real-time audio, but the reality is that how fast it moves across the bus, into a buffer, and then to disk is fixed, and not half the time, i.e., it's the *same* time that 2x of real-time audio would require at 1/2 the sample rate. So, at 2x the sample rate, you are taking 2x bandwidth (maybe no more time there), but moving the data to disk, even SSD, is a multiple of some sorts. Does it choke there? I don't know - lots of variables, but it could.

Yes, if we assume direct monitoring, sure, a whole lot goes out the window, but if there's any round trip, then the data on the bus and driver and app cycles all get multiplied by 2x, or 4x in the OP's case. The driver stack, in particular, gets very busy and system interrupts increase at least arithmetically.

If your point is that with hardware/firmware DSP in the interface and direct monitoring, you can dial up sample rate, sure. But, I'd start with going back to a (historically typical) lower sample rate and using the plugins appropriately, and then see what happens.

 

[bouldersoundguy]

My point, which I think we agree on, is that the place to look when trying to solve the latency is in the CPU. Either reduce the processing load or simply bypass the round trip.

 

[ecc83]

The bare mats of of is: Latency (time) = buffer/sampling rate.
So, 512/44100= 11.6mS and 512/96000= 5.33mS. But, as has been said, that is the minimum if nothing else is going on and there can be 'hidden' buffers and at 192kHz the poor little core might not cope.

Active monitors with DSP often use 96kHz presumably to keep latency low but also I suspect to have a system bandwidth well in excess of 20kHz? If only for advertizing purposes!

Dave.