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 1 week 2 days ago #45276

  • Delatte
  • Delatte's Avatar
  • Offline
  • Fresh Boarder
  • Posts: 2
  • 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!

The administrator has disabled public write access.

96khZ plug in with FIR 1 week 2 days ago #45284

  • xnwrx
  • xnwrx's Avatar
  • Offline
  • Senior Boarder
  • Posts: 58
  • Thank you received: 11
  • Karma: 0
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 1 week 2 days ago #45285

  • Delatte
  • Delatte's Avatar
  • Offline
  • Fresh Boarder
  • Posts: 2
  • 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

The administrator has disabled public write access.

96khZ plug in with FIR 2 hours 32 minutes ago #45457

  • Richard
  • Richard's Avatar
  • Offline
  • Expert Boarder
  • Posts: 128
  • Thank you received: 68
  • 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: 1 hour 48 minutes ago by Richard.
The administrator has disabled public write access.
Moderators: devteam