Low Latency Mode (and power mode?) for QC

I like that the OP is thinking out of the box while recognizing that “making the QC more efficient” is the way to go. While @MortenRL does propose an innovative workaround, grabbing half the processing power to solve the latency issue may not be a good way to approach this. Offering this proposed “efficiency” mode might have the unintended consequence of encouraging the writing, or persistence, of inefficient code that has not been properly optimized and slowing delivery of better code. To me this is like saying, instead of developing a more efficient mode of transportation, let’s just keep everything parked.

Frankly the last thing I want is to give up a significant portion of processing power, which might include way fewer blocks, or having to exclude more complex and resource intensive amps or effects from the signal chain. IMO this is a terrible way to go about things. The code needs to be optimized going forward so that latency is lowered while leaving the ability to have long and/or complex signal chains intact! All the other major modeling companies have managed to pull it off. If, after optimization is delivered, they want to provide this option for users who value super low latency over flexibility in their signal chain, I think that would be a grand idea.

1 Like

I agree that optimizing is the way to go!

My point is that until Neural gets there, this would be a nice temporary solution (emphasis on temporary). And as soon as they are there, it would take on new life as just a nifty feature.

Considering the “most powerful” slogan, I think being able to achieve super low numbers would be great for marketing as well…

2 Likes

Ok, so after some back and forth with support, this is their reply after sending my results:

“When you’re using the QC as a modeler, the round trip latency is usually between 2 - 5 ms, which is unnoticeable by the human ear. Even 7.8 ms is unnoticeable.
The latency inherent to the QC is the value mentioned above. Any additional latency will come from external sources.”

To which I cannot even…
For reference, this is 7.8 ms of delay. It´s not an “echo” of course, but there is no way that´s “unnoticable”. If you´re trying to be right on the beat, but you´re that much behind or in front… That makes a difference. Even 5ms is perceivable as separate transients. When we´re getting down to 4ms, the transients start to become indistinguishable.

Also blaming external sources is such poor taste. I´ve made it clear that there are no external sources (guitar → cable → QC → passive in-ears).

I´m not expecting anyone to fix the issue this instant, but for support to just flat out deny that it´s a potential issue… Well, it´s dissapointing. Hoping to see some unexpected improvement in 2.0…

3 Likes

@MortenRL it’s very subjective, so I guess it’s difficult to find a common opinion.

7ms equals around 2m of distance from a speaker. I often have this when playing live and I have no problem playing like that.
When I use headphones, I find the same latency irritating, for whatever psychological reason.
I imagine that people more sensitive than me will have even more problems.

I don’t agree with Neural’s statement that the maximum is 5ms, I have measured much more and, as you, I can quite exclude external influences.

So, for me it’s not an issue, but I understand if it is one for you and I believe it could be optimized.

2 Likes

Just for the record, latency and DSP are not directly proportional. You can use a lot of DSP and still have lower latency, just like you can get higher latency with less DSP. It’s more about specific items and how you’ve routed the grid than it is about total power. I noticed a custom IR that was introducing nearly 20ms or more all by itself, for example.

The average I see is around 5-12 for most presets I’ve built (many with a lot of row splitting). Each FX loop adds 2-3ms by itself even disabled, so that’s another thing to keep in mind.

1 Like

Yup, I understand that it’s not directly proportional.

For example when testing, I discovered that removing one out of three different delays did very little to the latency. Removing two made a little bit. But then when you remove all three it suddenly drops considerably. This seemed to be the case with other “groups” of fx as well.

one thing I’ve noticed is you probably need to set mix level on those to zero or something to measure that, or bypass if it doesn’t affect latency. Otherwise you’re probably confusing the measurement instrumentation because of the actual delay effect? Not sure if true, just a thought

Does a FX Sent Block (that is never receiving anything) add Latency?

I measured a 2.54ms latency on an FX Loop with a patch cable between Send & Return.

It’s the DA conversion to Send and AD conversion to return that adds latency.

No, its only if you return

When I first got my QC I did several latency tests against other devices. Now this was on one of the earliest operating systems. So I can’t say, but maybe things have changed sense then.

I notices that the more captures I had in line, the more latency I measured. So I started measuring the latency of different blocks and found some to be slightly more than others. For me, I decided to make sure my patches were as tidy as they could be to combat any latency I might be feeling. Get rid of any unused muted blocks that might be hanging around. Even if you’re not using them, they are adding up.

I am curious now, I’ll have to go back and do another test with the new OS to see if anything has changed.

I measured QC empty to 4.6ms (Accordingly to Leo Gibson on yt).
Add wireless instrument, wireless monitoring and… regret the boss gt1000.
But I was aware of that…
My real problem is the ASIO drivers…2.0 a little better but… latency is unacceptable to me when recoding processed audio from midi keyboard at the minimum buffer required to avoid artifacts.
I should keep my interafce just for that and is a shame!

I’ve done some experiments trying to identify the latency of specific blocks and found it quite challenging because it appears as if QC bumps up the latency in certain increments that don’t correspond directly to what is required for an effect, but rather for a set of effects if that makes sense.

For instance, sometimes I would add a block and observe 0 increase in latency. However, if I removed some other block first that would cause a decrease in latency, and then add a block that previously appeared to be “latency free”, the overall latency would increase. In one particularly weird case it looked like I could get slightly different latencies for the same exact preset depending on the order in which I constructed it.

I was doing these tests on a single line in the grid to make sure the result isn’t affected by routing through other DSP cores, etc. I’ve also measured multiple times to make sure the results are stable.

From a technical standpoint, it kind of doesn’t make sense to me how the latency may in any way be dependent on DSP load. At the end of the day, the device has to process a buffer within a fixed time budget that doesn’t exceed its length, otherwise it wouldn’t be possible to achieve uninterrupted sound. Unless QC actually increases the internal buffer size for more complex presets…

I only checked quickly that is better to have parallel lanes than serial and don’t keep there unused block that are latency sensitive. I always was under 7ms on typical use (bass).

I don’t know if this has been said…

I find an illusion of latency is created if the pre delay on reverb is too long. Really weird. Shortening that gets rid of it.

Ok, so a while ago I sold my QC because of the issue discussed in this thread. I still keep an eye on updates out of curiosity and I just saw that the new update claims to have improved latency performance. Can anyone comment on this? Some measurements (compared to the previous version?) would’ve been awesome!

This thread had some comprehensive testing, with the post I linked using updated numbers from 2.1.0.

1 Like

Awesome! Looks like it’s going in the right direction. Not a significant enough improvement for me to consider getting the QC again, but maybe in the future. I still think a dedicated low latency mode would be awesome (if it is possible of course).

Make sure youre not hitting the output limiter. Makes things feel very weird/off.

My personal rig is a pedalboard with analog pedals and some tube amps. I’ve played through the UA FX amp pedals, line 6 stuff and others. I love the tones I’m getting. But I wanted something flexible and light that I can take with me while traveling and this seemed to fit the bill perfectly. And so I got a QC a few days ago after seeing a ton of videos of how good it sounds but after downloading a few famous presets and making my own I noticed the notorious latency and ended up on here. it’s really off putting considering the price of this unit and the fact that other multi effect procs don’t deal with this issue at this scale. Even though the unit is on the latest firmware, there is still a lot of latency when using a preset with multiple rows and it’s particularly noticeable when playing clean with delays and reverbs. And FX loops…not even getting into that. I’m debating if I should return the QC or wait for improvements. Neural if you’re reading this, please try to fix it as for a lot of guitar players like me, the feel of the tone is often more important than the tone itself. Adding a low latency mode like MortenRL said would be great. I know there’s no perfect pedal out there so I’m good with compromises. “Whatever it takes”!