MiniDSP OpenDRC-DI being weird (measurements via SPDIF look rather atrocious)

[Daltong]

Okay, so I was using that OpenDRC-DI thing as equalizer and kind of annoyed by the sound. Something not quite right (qudelix sounded better, if not for the constant clicking it gives me on Linux and level adjustment weirdness that is part of their brand of DSP)

I decided to measure it using RMAA. TOSLINK from PC to MiniDSP, then TOSLINK from MiniDSP to ESI U24 XL on another PC.

First I of course measured just my sound card (TOSLINK from PC to another PC with ESI U24 XL )

Here's what it looks like PC(source) to ESI U24

Spoiler: card measurements

	Left​	Right​
From 20 Hz to 20 kHz, dB	-0.00, +0.00​	-0.00, +0.00​
From 40 Hz to 15 kHz, dB	-0.00, +0.00​	-0.00, +0.00​

There are also two THD graphs that don't get included in the report, also don't look too terrible

not too bad, it seems

Now let's see what OpenDRC does (I did mind the fact that OpenDRC always outputs 48 khz, tired recording both 16 and 24 bit, same result

NO EQUALIZATION WAS APPLIED AND OPENDRC WAS FULLY FACTORY-RESET BEFORE MEASUREMENT (all presets cleared)

Spoiler: OpenDRC-DI being more than a little bit insane it seems

Left​	Right​
From 20 Hz to 20 kHz, dB	-3.24, +1.53​	-3.24, +1.53​
From 40 Hz to 15 kHz, dB	-1.95, +1.53​	-1.95, +1.53​

The respective THD graphs are also completely out of whack pardon my french

ouch!

ouch ouch ouch

Oddly, report for OpenDRC measurement still states

THD, %	0.00054​	Excellent​
THD + Noise, dB (A)	-89.0​	Good​

Since it was all TOSLINK from source to recording soundcard, and since original soundcard recording isn't too terrible, I have to ask... what's going on here?
is there some kind of measurement misconfig I am woefully doing, or is my OpenDRC-DI really doing quite not too little frequency skew of its own and also adding suspicious amount of distortion?

And why with additional THD graphs being that ummmm... weird overall THD measurement in the report still claims decent distortion values?

Am I just being needlessly paranoid ?

 

[abdo123]

Sometimes the factory reset does not fully reset and you might want to use reset config for each individual config instead.

 

[Daltong]

Will try that, but like, the frequency response still doesn't look like anything of the EQs I've used and what's up with that huge, unreasonable THD in the THD vs freq graph? It is so massively different from what I get when testing the source itself it has to be either measurement error or MiniDSP device going insane ...

 

[Morpheus]

Hi,

I am afraid I don't have an explanation or measurements to share...
However, I have one of these, and after using it for EQ (IIR) it made an improvement but something sounded off.
Baffled by it, I experimented with using it just inline, with no EQ applied, just it taking SPDIF in, outputting SPFIF out to DAC and it sounded bad. Did it a lot of times back and forth, and every single time it sounded worse than SPDIF directely into DAC, just a collapsed illusion of soundstage and somewaht fatiguing sound. Maybe is the 48KHz upsampling or what you show, but this being an objectivist forum, decided not to post my findings, although at a certain point thought of asking Raydunzl about it...
Nowadays, just use RME ADI 2 DAC for both duties, much better.... just have it still to try and get FIR to work and see how that sounds.

 

[Daltong]

@abdo123
just painstakingly reset every preset separately, cleared and reloaded the firmware (with the one that came with plugin) and physically rebooted the OpenDRC - exactly same measurements bit for bit down to every digit.

Also tried using 16 bit in the recording settings of the ESI card (that does the recording), literally no impact at all. Not even a tiny bit.

This thing cost me three hundred dollers . I am quite upset. WTF I just want to have a reasonable EQ solution that takes in toslink and spits out toslink...

@Morpheus
I guess with that odity in frequency response right above 10 khz and weird THD behavior in swept sine and swept freq tests it would do things people with more listening skills than mine call "tiresome sound and collapsed illusion of soundstage"

Guess I'm not too bad at this listening thing after all, lol

 

[mdsimon2]

I have measured these in the past and have never seen such issues but I have always used the miniSHARC plugins, not the OpenDRC-DI plugin.

I would use REW for the measurements as it will give you more control and will help you confirm that what you are seeing is not a meausurement software issue.

EDIT: For reference here is an old measurement of an OpenDRC-DI. IIRC this was a mac mini TOSLINK out to OpenDRC-DI to TOSLINK mac mini TOSLINK in using the miniSHARC-4x8 plugin.

Michael

 

[mdsimon2]

Also another interesting test would be to use the OpenDRC-DI output to the DAC you were using and then measure the analog output with the ESI. This would eliminate any weird clock sync issues between the OpenDRC-DI / ESI and be more representative of what you are actually hearing.

Michael

 

[Morpheus]

@abdo123

I guess with that odity in frequency response right above 10 khz and weird THD behavior in swept sine and swept freq tests it would do things people with more listening skills than mine call "tiresome sound and collapsed illusion of soundstage"

Well, now I recall some older thread on this, when someone had even worse and nastier looking graphs, it was member Ray Dunzl that debugged that, if memory serves...I think that was the reason I let it slide, and ascribed what I heard to my own bias...but at least I am consistent, I still hear that mess on soundstaging when inserted, just doing in and out.. . Of course, when you get the EQ in per REW analysis, things go " one step back, two steps forward," kind of, but I am still aware of that first hit, and the RME sounds better doing it all instead of just DAC post DRC DI.
Regarding your suggestion, I did measure the speakers repeatedly both before and after, with it or without out,it, online and no EQ, and with EQ enabled ( talking about Minidsp of course) and never was a suggestion of something weird, even of that huge peak at 10K, therefore I shut up in spite of what I heard... I did have a small peak of distortion at 9,5 k or thereabouts in one speaker, probably related to a small dent in that speaker tweeter, as that is present in every scenario I have ever tested ( different amps, pre's, etc)
Anyway, meauring at the speaker probably swamps the electronics anomalies with its own distortion and other issues, so it may not readily show everything happening upstream, although those poste look too big to go unnoticed if they are for real and not just some setup artifact.

 

[mdsimon2]

I guess with that odity in frequency response right above 10 khz and weird THD behavior in swept sine and swept freq tests it would do things people with more listening skills than mine call "tiresome sound and collapsed illusion of soundstage"

Well, now I recall some older thread on this, when someone had even worse and nastier looking graphs, it was member Ray Dunzl that debugged that, if memory serves...I think that was the reason I let it slide, and ascribed what I heard to my own bias...but at least I am consistent, I still hear that mess on soundstaging when inserted, just doing in and out.. . Of course, when you get the EQ in per REW analysis, things go " one step back, two steps forward," kind of, but I am still aware of that first hit, and the RME sounds better doing it all instead of just DAC post DRC DI.
Regarding your suggestion, I did measure the speakers repeatedly both before and after, with it or without out,it, online and no EQ, and with EQ enabled ( talking about Minidsp of course) and never was a suggestion of something weird, even of that huge peak at 10K, therefore I shut up in spite of what I heard... I did have a small peak of distortion at 9,5 k or thereabouts in one speaker, probably related to a small dent in that speaker tweeter, as that is present in every scenario I have ever tested ( different amps, pre's, etc)
Anyway, meauring at the speaker probably swamps the electronics anomalies with its own distortion and other issues, so it may not readily show everything happening upstream, although those poste look too big to go unnoticed if they are for real and not just some setup artifact.

Here is the thread for reference -> https://www.audiosciencereview.com/...sp-opendrc-di-rew-measurements-problem.14180/.

It was a measurement artifact caused by using different input / output sample rates on a MOTU 8A, he was sending 44.1 kHz TOSLINK output (clocked from the MOTU's internal clock) to an OpenDRC-DI which ASRC'd the signal to 48 kHz (clocked from the OpenDRC-DI's internal clock) and then attempted to record the signal from the OpenDRC-DI with the MOTU TOSLINK input but it did not work well because the MOTU was still clocked to 44.1 kHz using it's internal clock.

This is why I recommended measuring the DAC output as digital I/O measurements can be tricky especially when you have an ASRC in between.

Michael

 

[Daltong]

Measured it through the DAC (E50) after adjusting levels so that the red led doesn't come on during measurement (just to make sure no clipping ever) with 48 khz plugin and 96 khz plugin

48 khz plugin - surprising compliance with previous measurement, exactly same "deformed" frequency response (slightly more channel difference) and weird THD readings under swept sine and swept frequencies test (almost exactly same)

96 khz plugin - frequency response (multitone) improved, almost normal

Frequency response (swept sine) and THD (swept sine) got MUCH worse under 96khz plugin
THD (swept freqs) - still deranged (up to +6, WHAT) but I guess better than it was.

It does seem like my OpenDRC is broken...

 

[mdsimon2]

Hmm, that is too bad.

I assume you've done the obvious and gone through the plugins and made sure all processing is defeated (I believe they have some x-overs enabled initially and I do not remember what the default routing matrix is)? If you want to send me your configuration I can open it up on mine and see if there are any issues.

When you run RMAA do the output meters input / output meters in the plugin act like you expect?

Honestly probably best to reach out to miniDSP, they are usually pretty good at resolving issues. Only possible explanation other than a broken OpenDRC-DI at this point is some weird measurement issue with RMAA. Again I would try REW as you will be able to run more manual measurements and would help you rule out RMAA as an issue. For reference I found some 1 kHz FFTs of my OpenDRC-DI, clearly no THD+N issues.

Michael

 

[Daltong]

Yeah, the meters behave about the way I expect, and all crossovers are set to bypass. I'll post the config but I doubt there is anything interesting going on there.
Maybe I am interpreting the "swept-sine" frequency response in RMAA (sadly it is not the best documented software)
I'll try to figure out REW and see what it produces...

 

[Daltong]

Here's the 96k config. https://file.io/KX8NB0nKMPEV

 

[Daltong]

Here's a new measurement taken on 96k plugin, RMAA, the "problematic" sine sweep test
It looks absolutely insane. Deranged really.

 

[mdsimon2]

I’d start with playing a -3 dB 1 kHz tone with the signal generator in REW and seeing what the spectrum looks like in the RTA. I’d do this with and without the OpenDRC-DI in the chain. If those RMAA results are real the spectrum will look terrible with the OpenDRC in the chain.

Michael

 

[Daltong]

I've played around with REW and it yes, does not look good.

BUT I think I've found which part of the OpenDRC broke (or maybe never worked )


it's the asynchronous resampler.

Looks like it ain't able to do much of resampling anymore (never did?), so in a sense it IS a clock issue, just a clock issue that a reasonable person would have assumed impossible based on docs.

It only works "as expected" when fed input matching the sample rate AND sample bit depth of the plugin (48 khz 24 bit for MiniSHARC48 and "native" OpenDRCx2 plugin, and 96khz 24 bit for the MiniSHARC-96 plugin)

Change source bit depth below 24 or sample rate (whether upwards or downwards) and it starts bugging out.

But if fed proper rate it produces very clean results, both in REW (as far as I can tell, I am still struggling with it a bit, lol) and in RMAA (the insane THD readings are gone and the weird frequency response skew is also gone, frequency response skew is literally +0.0 / -0.0 now)

This is to put it mildly incredibly annoying (one of the joys of having this beast in the chain on my workstation was reducing CPU load associated with upsampling, I run a lot of virtual machines when working and additional CPU load when dealing with 44.1 sources is not welcome, even if perhaps paranoid and inconsequential on a huge modern CPU)

Also mighty weird (clocks between source PC and measurement PC in my measurement setup cannot align perfectly - one has builtin audio, the other uses the ESI card - so the OpenDRC is doing some resampling anyhow, it's just being incredibly weird and dumb about it)

 

[abdo123]

I've played around with REW and it yes, does not look good.

BUT I think I've found which part of the OpenDRC broke (or maybe never worked )


it's the asynchronous resampler.

Looks like it ain't able to do much of resampling anymore (never did?), so in a sense it IS a clock issue, just a clock issue that a reasonable person would have assumed impossible based on docs.

It only works "as expected" when fed input matching the sample rate AND sample bit depth of the plugin (48 khz 24 bit for MiniSHARC48 and "native" OpenDRCx2 plugin, and 96khz 24 bit for the MiniSHARC-96 plugin)

Change source bit depth below 24 or sample rate (whether upwards or downwards) and it starts bugging out.

But if fed proper rate it produces very clean results, both in REW (as far as I can tell, I am still struggling with it a bit, lol) and in RMAA (the insane THD readings are gone and the weird frequency response skew is also gone, frequency response skew is literally +0.0 / -0.0 now)

This is to put it mildly incredibly annoying (one of the joys of having this beast in the chain on my workstation was reducing CPU load associated with upsampling, I run a lot of virtual machines when working and additional CPU load when dealing with 44.1 sources is not welcome, even if perhaps paranoid and inconsequential on a huge modern CPU)

Also mighty weird (clocks between source PC and measurement PC in my measurement setup cannot align perfectly - one has builtin audio, the other uses the ESI card - so the OpenDRC is doing some resampling anyhow, it's just being incredibly weird and dumb about it)

This is not the MiniDSP bugging out it’s REW.

Samples going out should always be the same as samples going in.

Even with accoustic measurements.

 

[Daltong]

Um, isn't MiniDSP supposed to, uh, resample stuff automatically regardless of what the soundcard feeds it via TOSLINK?

 

[mdsimon2]

I've played around with REW and it yes, does not look good.

BUT I think I've found which part of the OpenDRC broke (or maybe never worked )


it's the asynchronous resampler.

Looks like it ain't able to do much of resampling anymore (never did?), so in a sense it IS a clock issue, just a clock issue that a reasonable person would have assumed impossible based on docs.

It only works "as expected" when fed input matching the sample rate AND sample bit depth of the plugin (48 khz 24 bit for MiniSHARC48 and "native" OpenDRCx2 plugin, and 96khz 24 bit for the MiniSHARC-96 plugin)

Change source bit depth below 24 or sample rate (whether upwards or downwards) and it starts bugging out.

But if fed proper rate it produces very clean results, both in REW (as far as I can tell, I am still struggling with it a bit, lol) and in RMAA (the insane THD readings are gone and the weird frequency response skew is also gone, frequency response skew is literally +0.0 / -0.0 now)

This is to put it mildly incredibly annoying (one of the joys of having this beast in the chain on my workstation was reducing CPU load associated with upsampling, I run a lot of virtual machines when working and additional CPU load when dealing with 44.1 sources is not welcome, even if perhaps paranoid and inconsequential on a huge modern CPU)

Also mighty weird (clocks between source PC and measurement PC in my measurement setup cannot align perfectly - one has builtin audio, the other uses the ESI card - so the OpenDRC is doing some resampling anyhow, it's just being incredibly weird and dumb about it)

This very much sounds like a measurement anomaly and/or potentially a Windows resampling issue, I would not blame the OpenDRC at this point.

If you are only running one instance of REW you can ONLY do the measurement at the sample rate of the OpenDRC. If you run at another sampling rate there will be a mismatch in the playback and capture sample rates which will give invalid results. If you want to test with a different sample rate then you need two instances of REW, one for playback and one for capture. The playback can be at any sample rate but the capture needs to be at the same sample rate as the OpenDRC.

Michael

 

[Daltong]

Yeah, two instances.
Same as with RMAA - source PC is one machine, then toslink, then OpenDRC, then toslink to another PC with ESI card.

I kind of assumed based on whole "asynchronous resampling" from docs that OpenDRC takes care of the source/recipient sampling mismatches and it should be okay as long as the recepient matches the sampling rate and format of OpenDRC

No?