Welcome, Guest
Username: Password: Remember me

NOTE: This is a "Community" forum. Please be mindful that community members are here to help as part of a community effort. We therefore appreciate your effort in keeping this forum a happy place!

If you have a specific issue (e.g. hardware, failure) and want help from our support team, please use our tech support portal (Support menu - > Contact Us).
Thanks a lot of your help in making a better community.
  • Page:
  • 1

TOPIC:

DRC Latency 11 months 1 week ago #51193

  • atlmsc
  • atlmsc's Avatar Topic Author
  • Offline
  • New Member
  • New Member
  • Posts: 5
  • Thank you received: 0
Hi!

In cubase when playing guitar trough an amp simulator the highest acceptable latency is 4 ms to feel good. I can do 2ms also but no need. When mixing the soundcard runs best at 12ms.

Concerning OpenDRC-DA8

What is the input latency when running the minisharc?
What is the input latency when running 4way FIR filter?

Thank's!


Attachments:

Please Log in or Create an account to join the conversation.

Last edit: by atlmsc.

DRC Latency 9 months 2 weeks ago #52189

  • Richard
  • Richard's Avatar
  • Offline
  • Premium Member
  • Premium Member
  • Posts: 136
  • Thank you received: 72
The latency through the S/PDIF input and basic machine's internal DSP path is probably something less than 1ms.
The latency through the 8 output D/A converters probably adds another 0.5ms.

However, the convolution FIR filter block may or may not add considerable latency, depending on the nature of the impulse file you choose to load into it and run. In theory, anywhere from zero up to the whole duration of the impulse file. I'll explain...

I believe OpenDRC DA8 model offers 1200 taps per channel at 48kHz sampling rate - ie. if those 9600 total available taps are allocated equally between the 8 channels. In that case, the impulse file for each would be 25ms in duration.

You can also instead allocate 2048 taps max to certain channels (perhaps for subwoofers, giving you more taps to work with for better low frequency resolution) but leaving you less remaining taps for other channels, if you prefer to share your taps out unevenly between different channels like that, to maximise your resources, rather than a one-size-fits-all equal allocation. And you don't have to use all the taps either, it will accept smaller size files too. But in this case of 2048 taps at 48kHz your impulse response length is now 42.67ms, which is the longest possible duration impulse file the DA8 can handle.

Running at optional 96kHz sampling rate obviously HALVES the duration of your impulse file (for the same number of taps available) and thus substantially reduces the FIR resolution at lower frequencies, so isn't really a good idea for practical convolution jobs like loudspeaker correction, unless you desperately need 96kHz for some reason.

So, I guess you're probably running 48kHz and will either have a shorter impulse file of 25ms using 1200 taps, or longer file of 42.67ms using 2048 taps.

How much latency does that give?

At best, if your impulse file just contained a single sample Dirac spike at the very first sample - effectively a digital bypass which does nothing - then this FIR block convolution would not add any latency at all. 0ms. Zero. Bit of a useless convolution though, what's the point?

At worst case latency, if your impulse file just contained the same single sample Dirac spike at the very last final sample, it would be the identical sounding digital bypass, but would have added 25ms total duration as a delay onto your signal, so you'd hear 25ms extra latency through the DSP with this 1200 tap FIR block running. Likewise if you created the 2048 tap version of this "last sample spike" instead, you'd hear the entire file duration 42.67ms of delay or latency added by this FIR action. Still a bit of a useless convolution though...

Since neither extreme case "bypass" convolution for zero or max theoretical latency is of any practical worthwhile use to anybody in the real world - and OpenDRC anyway includes a separate dedicated delay function elsewhere in the software if you do need extra pure time alignment delay - then obviously, in the real world, you're going to want to create an FIR impulse file which does something useful, like loudspeaker or room correction with a complex EQ function, and / or a complex phase shift, or some linear phase shift EQ or correction.
This arbitrary FIR impulse function - whatever you decide to create - will therefore have some arbitrary amount of latency which falls somewhere inbetween these two extremes, but it entirely depends what shape FIR filter you create - it's latency value is not a fixed spec-sheet figure anyone can quote you.

Latency may be defined / measured from the start of the file (first sample) to wherever the effective peak of this impulse occurs (that is the reference t=0 point of the function) remembering that with FIR linear phase filtering, it doesn't have to be at the beginning. It allows you to have audio energy build up earlier than t=0, so negative phase shift corrections can move audio energy "backwards in time" to occur before the main peak, rather than after it (which you'd always get from classic minimum phase filters like analogue EQ. ) Of course, it isn't magic and it doesn't really travel back in time (!) but simply the whole filter is relatively delayed so the peak occurs later in time allowing something else to occur before the peak. You pay the penalty of latency for messing around with negative phase corrections.

Now if you've created just a classic textbook basic IIR function like "normal" minimum phase EQ or crossover filter (with "normal" phase shift) then the effective peak (t=0) of the impulse can still be right at the start of the FIR impulse file, and thus will not add any extra latency.
If that's all you need from FIR convolution , maybe just a very detailed custom EQ curve, like having a one thousand band graphic equaliser to play with, then yes it can run those filters without any latency worries.

If, on the other hand, you're making a textbook linear phase filter with phase shift occurring symmetrically both before and after the impulse peak, then the effective peak (t=0) is usually in the centre of the impulse file duration. (ie. halfway at 12.5ms or at 21.33ms in each example) so you will hear that amount of latency added, ie. the latency is now exactly half the total FIR impulse file duration.

Most likely real world situation, if your impulse file is an FIR correction for your loudspeakers or room based on your mic measurements, and you've manually generated it using rePhase or similar software, you'll have a rather complicated mixture of both minimum phase EQ and linear phase EQ correction filters going on, phase shifts filters, crossover slopes maybe, etc. and chances are the effective impulse peak (t=0) might fall somewhere near the middle approx but perhaps be offset slightly nearer the start. (rePhase will automatically calculate the best offset value to squeeze the most amplitude bulk of your filter within the given impulse duration, and will display the calculated offset values - you should make a note of them, or you can specify your own custom offsets too.)
This means your FIR filter latency will be the measured length from the start of the file to wherever the calculated effective peak is (the t=0 point) and nobody knows exactly what your latency measurement will be, because it depends on your loudspeaker & room measurements, your choices of EQ and filtering, and your settings in rePhase, etc. It will probably be a little less than half the filter duration, but half is a nice rule of thumb if you want to rough guess a typical value. Once you generate the actual FIR filter, rePhase will calculate the exact offset value for you - allowing you to work out the exact latency figure.

If you're making a 4 way crossover, you should note all your impulse peak offsets and pay attention to understanding them to ensure you have correct time alignment. You'll probably need to add or subtract relative amounts to achieve the perfect desired time alignment correction between tweeter, midrange and woofers, etc. I could write pages about that, it's a big subject too. Depends where your measurement mic is located also.

Bottom line, expect a typical working latency of approx 10ms to 14ms from the OpenDRC DA8 in normal use, for typical loudspeaker correction duty, S/PDIF in to analogue out running FIR with 1200 taps at 48kHz.

For live music performance, 10ms to 15ms isn't too bad. eg. Yamaha's DSR112 speakers for PA use with FIR crossover have 10ms latency.
Sound travels approx 1 foot per millisecond, so 10ms latency is only like standing 10 feet further back from the loudspeaker.

You could always design your filters to have smaller latency (as custom hybrid FIR + IIR mix) if you're willing to compromise and accept less phase correction accuracy at lower bass frequencies.
You can also make TWO sets of filters: A higher latency / maximum correction FIR filter for quality audiophile listening, and a lower latency / slightly less accurate but still pretty good correction FIR for live music performance.

Please Log in or Create an account to join the conversation.

Last edit: by Richard.

DRC Latency 9 months 2 weeks ago #52234

  • atlmsc
  • atlmsc's Avatar Topic Author
  • Offline
  • New Member
  • New Member
  • Posts: 5
  • Thank you received: 0
Oh dear, this was intense :)
Thank you very much!

Please Log in or Create an account to join the conversation.

DRC Latency 9 months 1 week ago #52355

  • Richard
  • Richard's Avatar
  • Offline
  • Premium Member
  • Premium Member
  • Posts: 136
  • Thank you received: 72
Hi atlmsc,
Yes, sorry, it certainly took some explaining! Probably would have been simpler if I just had a diagram or two to illustrate. A picture's worth a thousand words. Hopefully it still made sense though.

Anyway, assuming you're trying to use FIR for loudspeaker / room corrections, then yes, the FIR latency will probably be too long for comfortably recording live guitar.

But surely recording live guitar along to a studio track you'd use monitor mix headphones anyway? Or you'd be hearing the actual guitar amp combo live if it's miked up and you're in the same room?
So the experience of recording live guitar is unaffected, because you wouldn't normally be monitoring through OpenDRC for that anyway.
(Although I realise you may just have been quoting that as an example of latency figures you're familiar with.)

Listening through your main loudspeakers with FIR correction afterwards for playback / mixdown / post production, the latency won't make any difference because it's playback only, not live.

Please Log in or Create an account to join the conversation.

DRC Latency 5 months 2 weeks ago #54970

  • RyanC
  • RyanC's Avatar
  • Offline
  • New Member
  • New Member
  • Posts: 4
  • Thank you received: 0
I use them in a recording studio-

A couple things. First, in your screenshot your are only considering the input latency. If you are monitoring through cubase, your full RTL (round trip latency) with that setting is 4 + 6 - input plus output. So 10, which is typically considered right around the threshold of detection and is a bit on the high side. Do you use ASIOguard?

2nd, on the OpenDRC you can make a IIR preset that is low latency, and an FIR one that is high. This is the same thing you see with Dutch and Dutch, Kii etc. Just like for mixing with the higher buffer, you can switch to your higher latency FIR/impulse corrected setting and then back to IIR low latency.

2nd, don't forget that your interface dac will be bypassed if you use spdif out. IE, if you use the oblique audio RTL tool (free) you can compare a dead patch (output to input) for your round trip latency via analog, and via spdif. Typically spdif only is about 1ms faster. So keep this in mind, you only add the processing time of the OpenDRC, not the dac time.

Hope that helps

Please Log in or Create an account to join the conversation.

  • Page:
  • 1
Moderators: devteam