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.

TOPIC: 96khZ plug in with FIR

96khZ plug in with FIR 7 months 4 days ago #45276

  • Delatte
  • Delatte's Avatar
  • Offline
  • Fresh Boarder
  • Posts: 3
  • Karma: 0
Hi there,

i'm a recent Open DRC-DI user (for live shows and education) and i love it!

How about having a 96kHz version of Open DRC 2x2 Plug in? so we could have 96khz FIR ??

Or even better: a clock menu, with clock monitoring of inputs...

Would love it twice more!

Many thanks!

NaHD
The administrator has disabled public write access.

96khZ plug in with FIR 7 months 4 days ago #45284

  • xnwrx
  • xnwrx's Avatar
  • Offline
  • Senior Boarder
  • Posts: 76
  • Thank you received: 16
  • Karma: 1
96 kHz clock does not give better fidelity than 48 kHz. So 48kHz shall be more than enough in all cases.
Anyway, MiniDSP uses ASRC devices to reclock any input whichever its frequency to internal master clock (48 kHz ou 96 kHz depending on plugin). So your input signal will always be resampled.
The administrator has disabled public write access.

96khZ plug in with FIR 7 months 4 days ago #45285

  • Delatte
  • Delatte's Avatar
  • Offline
  • Fresh Boarder
  • Posts: 3
  • Karma: 0
Thanks for your answer!

Im not considering any « fidelity » issue in my purpose.

Im just working with whole systems which are often clocked at 96khz and i’ve no problem with Asrc . I’d just like my dsp to output 96khz if I input 96khz

Best!
The administrator has disabled public write access.

96khZ plug in with FIR 6 months 3 weeks ago #45457

  • Richard
  • Richard's Avatar
  • Offline
  • Expert Boarder
  • Posts: 132
  • Thank you received: 71
  • Karma: 13
96kHz native operation (if it were ever offered as an option) would be losing / wasting half the convolution capacity of this machine - your convolution impulse files would have to be effectively truncated to half their previous duration (compared to 48kHz.)

OpenDRC currently offers 6144 taps at 48kHz which gives you 128ms of convolution capacity to play with.
Running 6144 taps at 96kHz would give you only 64ms of convolution capacity (effectively the equivalent of just 3072 taps at 48kHz)

There's no logical advantage or benefit to doing that...
96kHz may be certainly popular for live sound due to slightly reduced latency - but for realtime hardware convolution wherever the actual need for it exists in most applications where symmetrical linear phase FIR filters or other custom configured EQ and phase corrections (usually for loudspeaker or room corrections) are being implemented, there is almost always a very long latency being introduced by the nature of this very process. The microscopic difference in latency between 48kHz vs 96kHz is dwarfed by the typical application process latency in question - making 96kHz have no obvious benefit anymore.
(That's also why you never see high tap counts in pro audio loudspeaker FIR processors for live sound - 512 taps or 1024 taps is usually the max typically available - because otherwise the FIR process latency is far too high for live sound applications.)

For the highest audible frequencies, 96kHz sampling supposedly moves the steep anti-aliasing LPF filter up another octave further out of the auible range along with the worst of it's associated phase distortions / ringing, so the theory goes, but FIR convolution allows you to correct for any phase distortion and correct the impulse response back to perfect (in theory) so there should be no need for 96kHz sampling with its higher Nyquist cutoff to reduce audible phase distortion or "digital ringing" given a theoretically perfect textbook FIR corrected system running at 48kHz.

The audiophile desire to extend audio reproduction bandwidth beyond 20kHz, purely for the sake of it, is blindly dependent on having good enough spec microphones and super-tweeters to do justice to the extended bandwidth (otherwise we're just capturing nasty ultrasonic mess and reproducing it even more distorted) and yet who could then honestly say they can hear beyond 20kHz and validate this exercise as successful? A two year old child maybe, or your pet dog? Are they really capable of sitting and listening through several blind ABX trials with repeatable test scores?

Where it matters, and where FIR convolution runs out of steam as a powerful corrective tool, is actually in the low frequencies, approaching the deep bass /subwoofer range, where even 6144 taps is not enough for precision, and our overwhelming wish would be for more convolution power, more taps, longer impulse responses... not less! Going to 96kHz makes things worse in this respect, so it's the opposite of a step in the right direction.

We should really be asking MiniDSP to implement DOWNSAMPLING modes that allow us to run at 24kHz or 12kHz sample rates for the bass or subwoofer channels to give us (with the same OpenDRC hardware) the equivalent convolution power of 12,288 taps or even 24,576 taps, and convolution impulse file lengths up to 256ms or 512ms. (Maybe even combine downsampling too with mono mode merging two stereo channels into one super channel to double the convolution capacity again if that were possible.)
Downsampling would be the most significant new step in the right direction for this dedicated convolution platform, if even greater performance and audiophile precision down to the lowest frequencies is the desired goal. That's the weakest area and most noticeable sonic limitation of the current machine.
Last Edit: 6 months 3 weeks ago by Richard.
The administrator has disabled public write access.

96khZ plug in with FIR 6 months 3 weeks ago #45458

  • Delatte
  • Delatte's Avatar
  • Offline
  • Fresh Boarder
  • Posts: 3
  • Karma: 0
Richard,

thank you very much for your long answer.

I really agree with you on all points! (all taps:)
What a great dsp it would be if you could choose the sampling rate of any channel!
I know down sampling is the right direction for LF issues...

Once more... i was not requiring 96khz on digital outputs for quality reasons... but more for psychological :)
Asrc on output could do that after the FIR section...

Anyway I hope one day there ll be optimizations like those you said on minidsp plug ins.

Best Regards
The administrator has disabled public write access.

96khZ plug in with FIR 6 months 3 weeks ago #45460

  • Richard
  • Richard's Avatar
  • Offline
  • Expert Boarder
  • Posts: 132
  • Thank you received: 71
  • Karma: 13
Hi Delatte,

Okay, to better answer your question, perhaps explore the other options...

Assume you've seen the MiniDSP Dirac series which work at 96kHz native, using the same internal hardware as OpenDRC. The stereo Dirac DDRC-22D machine offers 3072 taps at 96kHz if that's really what you're looking for in one piece of kit. Though you might have to find some clever workaround running the measurement mic source instead from some custom line signal path with your desired transfer function already applied to fool Dirac's measure / analyser firmware into thinking it was actually measuring the room like that each time for its 9x measurement and averaging process.

Goes without saying that the 96kHz Dirac range appeals most to the enthusiast home hi-fi market where "psychological" reasons to adopt 96kHz appear to far outweigh any and all logical arguments against such as in post #45457 and IMHO therefore 96kHz Dirac series is less useful as a pure convolution tool - per se - than the 48kHz OpenDRC equivalent. Then again, I'm not trying to bash the Dirac range for appealing to that hi-fi consumer market, and it clearly offers nice user freindly ease-of-use software guiding you through the process which is totally absent with OpenDRC where you have to know how to make your own impulse files from scratch using 3rd party tools.

Apart from MiniDSP Dirac series running 96kHz, other rival companies who offer 96kHz convolution hardware either aim at the expensive hi-fi market like the multichannel DEQX which runs 96kHz (4096 taps = 42.67ms impulse file) at far higher cost(!) - yet still obviously inferior convolution power to the OpenDRC (48kHz @ 6144 taps = 128ms impulse file) - or both pro / hi-fi market like the APL-1S which is switchable 48kHz (4096 taps = 85.33ms impulse file) or 96kHz (2048 taps = 21.33ms impulse file) - but again despite being triple the price it still clearly can't beat the OpenDRC for convolution power.

>Once more... i was not requiring 96khz on digital outputs for quality reasons... but more for psychological
>ASRC on output could do that after the FIR section...


If you really have to feed a subsequent digital machine a 96kHz digital AES/EBU or S/PDIF signal - because it won't accept 48kHz digital ?! - then maybe the cheapest solution it to buy something like a Behringer UltraMatch Pro SRC2496 outboard sample rate converter which can cover all those bases, but once again, there really is no benefit whatsoever. You'd be introducing yet more asynchronous SRC stages, extra jitter, extra wires, extra power supply, more setup complication and hassle, and you'd gain absolutely nothing because all the 96kHz digital signal's extended bandwidth content was already lost going through the 48kHz stage inside the OpenDRC anyway.

Also, as xnwrx says above, the 96kHz clock does not give better fidelity than 48 kHz clock. In fact, the effect of any jitter will be doubly worse news for 96KHz sampling (and internal re-sampling by ASRC) than for the same jitter clock running at 48kHz.

Putting everything though yet another additional Asynchronous SRC on the output of the OpenDRC after the FIR section, as you suggest, is the last thing I'd want, unless it was totally bypass-able, because it would further unnecessarily degrade the signal quality and introduce more jitter and clock drift etc. It's bad enough that everything is forced through the input asynchronous SRC on the OpenDRC already and you cannot bypass that even for source 48kHz material, let alone putting a second one(!) on the output as well.
If they were going to change anything, I'd rather MiniDSP offered a way to bypass the input asynchronous SRC altogether and accept native 48kHz in synchronous mode from the input digital source clock. (The APL-1S is switchable to either mode like this.)

Best regards,
Richard
Last Edit: 6 months 3 weeks ago by Richard.
The administrator has disabled public write access.
Moderators: devteam