• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required as is 20 years of participation in forums (not all true). There are daily reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

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

mdsimon2

Major Contributor
Forum Donor
Joined
Oct 20, 2020
Messages
1,495
Likes
1,893
Location
Detroit, MI
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?

And you are always running your capture instance at the same sample rate as the OpenDRC? Can you post some RTA shots so we have an idea of what you are seeing?

The OpenDRC ASRC will convert all sources to the sample rate of the plugin but the capture rate used by the ESI needs to be the same as the OpenDRC because the ESI will end up being clocked by the OpenDRC via TOSLINK.

Michael
 
OP
Daltong

Daltong

Member
Joined
Mar 9, 2022
Messages
47
Likes
5
Yeah, the ESI is set up to always 24 bit 48khz, and works well if openDRC is fed 48khz 24 bit.

If it is fed anything else - (no change in OpenDRC or ESI config) weirdness starts.
Annoyingly even if the sound card of the source is set to 24 bit 48 khz (all other sampling rates disabled in source driver setting, checked by connecting it to DAC which dutifully displays "48" upon connection) but the file being played back is 41 khz (test wav, relying on windows's less than ideal resampling here) weirdness begins.
 
OP
Daltong

Daltong

Member
Joined
Mar 9, 2022
Messages
47
Likes
5
only viable configuration seems to be

source card 48 khz 24 bit
test file 48khz

(test wav 41 khz fails miserably even if the source sound card is using 48 khz and windows is presumably doing the upsampling)
 

mdsimon2

Major Contributor
Forum Donor
Joined
Oct 20, 2020
Messages
1,495
Likes
1,893
Location
Detroit, MI
Yeah, the ESI is set up to always 24 bit 48khz, and works well if openDRC is fed 48khz 24 bit.

If it is fed anything else - (no change in OpenDRC or ESI config) weirdness starts.
Annoyingly even if the sound card of the source is set to 24 bit 48 khz (all other sampling rates disabled in source driver setting, checked by connecting it to DAC which dutifully displays "48" upon connection) but the file being played back is 41 khz (test wav, relying on windows's less than ideal resampling here) weirdness begins.

This sure sounds like Windows resampling weirdness and not the OpenDRC-DI.

For reference here are some measurements of one of the OpenDRC-DIs I have. Path is MacBook Pro TOSLINK out (REW playback and Audio MIDI settings set to 44.1 kHz so no software resampling), OpenDRC-DI running at 96 kHz, capture instance of REW set to 96 kHz. Capture device is a RME Fireface 800 with clock set to sync to TOSLINK input.

44.1 kHz input - 16 bit
1652654646530.png


44.1 kHz input - 24 bit
1652654725714.png


Michael
 
OP
Daltong

Daltong

Member
Joined
Mar 9, 2022
Messages
47
Likes
5
Well, anyway 99 percent of my music listening is when working on Linux so like, I guess next step is not "throw MiniDSP into the roiling ocean" but "figure out how to make pulseaudio upsample/downsample everything to 48/24 without too much pulseaudio-style artifacts"

I kind of counted on MiniDSP to handle this one for me but, alas, life is unfair.

At least good news is that RMAA generated test files work about the way I expected them to, so I can just play WAVs from linux and watch ESI+RMAA on the windows box go insane until I hit the right settings.
 

mdsimon2

Major Contributor
Forum Donor
Joined
Oct 20, 2020
Messages
1,495
Likes
1,893
Location
Detroit, MI
Well, anyway 99 percent of my music listening is when working on Linux so like, I guess next step is not "throw MiniDSP into the roiling ocean" but "figure out how to make pulseaudio upsample/downsample everything to 48/24 without too much pulseaudio-style artifacts"

I kind of counted on MiniDSP to handle this one for me but, alas, life is unfair.

At least good news is that RMAA generated test files work about the way I expected them to, so I can just play WAVs from linux and watch ESI+RMAA on the windows box go insane until I hit the right settings.

I'm not sure you get it, the miniDSP does fine at asynchronous resampling (as shown by my examples above). The key is to make sure that your software player is NOT resampling.

Michael
 
OP
Daltong

Daltong

Member
Joined
Mar 9, 2022
Messages
47
Likes
5
Okay, I mostly figured it out and it seems to be many things at once.

1) Linux situation with resampling turned out both worse (idiosyncrasy of my OS stack) and better (I understand what's causing problem and can mitigate) and I managed to get reasonablish measurements

2) however, periodically I would still measure mad THD crap for absolutely no reason, but only after I restored my EQ "set"

Turns out - FIR equalizer I've built to implement Oratory EQ for AeonRT was causing the MiniDSP to bug out weirdly making every n+1 measurement break even though the preset where it is stored is not loadedo_O. Given that EQ itself turned out to look nothing like oratory anyway, with over 3db deviations from "curve I expected to see" at places (measured using analog inputs of ESI card, through the DAC, and, separately, "TOSLINK only" - problem not attributable to DAC) I decided to delete it and situation improved for all other presets...somehow!

Maybe one day I will bother with finding the rePhase settings which both build a close-to-oratory EQ that doesn't make OpenDRC go mad.

I guess I should notify MiniDSP (tho I suspect they abandoned support for these units)

Measurements became reliably repeatable.

So I guess situation is mostly debugged + mitigated.

Holy shit :cool:
 
Last edited:
Top Bottom