DSP Measurements and Rising Noise Floor

[mdsimon2]

@danstahl What is your source? Reason I ask is the Flex HT does not have bidirectional USB audio. If your source is multichannel PCM over HDMI from say an AppleTV, you can't use the Flex to route that HDMI input to CamillaDSP. Of course this isn't really a disadvantage of the Flex compared to the MOTU.

Also, isn't the Flex HT only $600?

I'd probably go Flex HT/HTx over MOTU unless you need the additional I/O of the MOTU.

Michael

 

[danstahl]

@danstahl What is your source? Reason I ask is the Flex HT does not have bidirectional USB audio. If your source is multichannel PCM over HDMI from say an AppleTV, you can't use the Flex to route that HDMI input to CamillaDSP. Of course this isn't really a disadvantage of the Flex compared to the MOTU.

Also, isn't the Flex HT only $600?

I'd probably go Flex HT/HTx over MOTU unless you need the additional I/O of the MOTU.

Michael

Flex HTx is what I meant. My source is a vero4k which is a linux platform, and could perform DSP before sending to the DAC (whether Motu or Flex HTx)

 

[mdsimon2]

@danstahl That is a cool device, I haven't seen it before, definitely gives you some nice options.

You should be able to install minidsp-rs -> https://github.com/mrene/minidsp-rs on the Vero, which will allow you to remotely access the Device Console without the miniDSP wifi dongle.

I'd definitely go the Flex HTx for the display / remote. As you wouldn't be running CamillaDSP on a device with GPIO pins, it would make adding similar functionality to the MOTU more difficult.

Michael

 

[mdsimon2]

I've been beta testing the newly announced DSP firmware 1.6 for the @Okto Research dac8 PRO developed by @fabriceo. This firmware is extremely flexible and allows user defined DSP to be implemented on the XMOS XU216. Results are quite good and there is a nice write up on the AVDSP_DAC8 GitHub -> https://github.com/fabriceo/AVDSP_DAC8/tree/main/documents describing how they were achieved.

Measurements below were made using Pure AES mode of the Okto. Source was TOSLINK input from a Mac mini 2014 converted to AES. Results were captured using USB audio capture from the Okto itself.

Base: Input RMS -1.00 dBFS, THD: -168.6 dB based on 49 harmonics [20..22000 Hz], N: -146.3 dB [20..22000 Hz], THD+N: -146.3 dB [20..22000 Hz]
Sub: Input RMS -7.27 dBFS, THD: -152.6 dB based on 49 harmonics [20..22000 Hz], N: -139.0 dB [20..22000 Hz], THD+N: -138.8 dB [20..22000 Hz]

Base: Input RMS -1.00 dBFS, THD: -168.8 dB based on 49 harmonics [20..22000 Hz], N: -146.3 dB [20..22000 Hz], THD+N: -146.3 dB [20..22000 Hz]
Low: Input RMS -5.21 dBFS, THD: -152.2 dB based on 49 harmonics [20..22000 Hz], N: -143.0 dB [20..22000 Hz], THD+N: -142.5 dB [20..22000 Hz]

Base: Input RMS -1.00 dBFS, THD: -172.7 dB based on 21 harmonics [20..22000 Hz], N: -146.5 dB [20..22000 Hz], THD+N: -146.5 dB [20..22000 Hz]
High: Input RMS -10.63 dBFS, THD: -164.7 dB based on 21 harmonics [20..22000 Hz], N: -137.4 dB [20..22000 Hz], THD+N: -137.3 dB [20..22000 Hz]

Updated summary table shows that it is just a hair behind CamillaDSP and clearly beats all miniDSP platforms.

Michael

 

[DWPress]

I'm looking forward to getting into the new firmware, still running FW 1.42 so have a fun update to do first. I've been holding off as I've just replaced woofers and tweeters in my franken-speakers so have been working out the new XO before diving into the new possibilities.

I'm still not sure if I want to offload all these duties from the computer, I like to tinker with things in real time and take quick measurements and there are no sonic advantages to merely moving the processing to the Okto.

Another thought I've recently had is using my old Minidsp 4x10 as an AES input into the Okto to add a couple smaller subs. Quite a few of the MiniDSP boards came with the DigiFP board, what do you think about the combo @mdsimon2?

edit: never mind about the MiniDSP idea!

 

[mdsimon2]

I'm looking forward to getting into the new firmware, still running FW 1.42 so have a fun update to do first. I've been holding off as I've just replaced woofers and tweeters in my franken-speakers so have been working out the new XO before diving into the new possibilities.

I'm still not sure if I want to offload all these duties from the computer, I like to tinker with things in real time and take quick measurements and there are no sonic advantages to merely moving the processing to the Okto.

Another thought I've recently had is using my old Minidsp 4x10 as an AES input into the Okto to add a couple smaller subs. Quite a few of the MiniDSP boards came with the DigiFP board, what do you think about the combo @mdsimon2?

edit: never mind about the MiniDSP idea!

Previously I used an OpenDRC-DI as the front end of my system which uses a DIGI-FP. Performance of the SRC4382 is quite good. Only downside is the ASRC will clip intersample overs as discussed in this thread, although I don't think that is really an audible issue.

Michael

 

[dualazmak]

I've been beta testing the newly announced DSP firmware 1.6 for the @Okto Research dac8 PRO developed by @fabriceo. This firmware is extremely flexible and allows user defined DSP to be implemented on the XMOS XU216.

Please allow me repeating my feeling I posted today here on the thread "Okto 8 Owner’s Thread".

Spoiler

> At least for me, myself, I am still very much hesitating to implement this type of (frequent?) manipulation/writing on "firmware" of an audio device.

> I am living in Japan using DAC8PRO (firmware 1.32), and if I would "destroy" irreversibly the firmware, what should I do for recovery??
Should I send back the unit to Prague for repair/maintenance with cost? How long does it take? Transportation costs and import/export tax? Physical safety of such transportation?

> I still prefer independent system-wide onestop software DSP Center (in my case "EKIO") with which I can very flexibly safely change/configure any of the DSP parameters (even on-the-fly) using well designed GUI interface and mouse operation.

 

[DWPress]

I've been thinking about your tests here and on the Okto thread @mdsimon2 and it strikes me that using the Okto this way is also the most fool proof method for gain structure and introduced latency. Doing it via FIR in software with plugins is convenient but latency issues can start creeping in. After keeping an eye on clip meters as I iron out my new XO and EQ every dB counts when headroom starts getting sucked by DSP. Looking forward to implementing the new features.

 

[mdsimon2]

I've been thinking about your tests here and on the Okto thread @mdsimon2 and it strikes me that using the Okto this way is also the most fool proof method for gain structure and introduced latency. Doing it via FIR in software with plugins is convenient but latency issues can start creeping in. After keeping an eye on clip meters as I iron out my new XO and EQ every dB counts when headroom starts getting sucked by DSP. Looking forward to implementing the new features.

If / when Okto implements DSP volume control in addition to DAC volume control I think that will definitely be the case, without that you are more prone to digital clipping than other DSPs. Here is how I see it assuming you are dealing with SPDIF or AES input.

miniDSP
-Low, fixed latency
-DSP volume control makes digital clipping less likely
-ASRC allows for a wide variety of input sample rates but also clips intersample overs
-Other than watching output meters, no flag indicating if digital clipping has occurred
-Decent IIR processing power
-Limited FIR processing power

CamillaDSP
-Medium, variable latency
-DSP volume control makes digital clipping less likely
-DSP volume control can eliminate clipped intersample overs
-Gives indication in GUI if DSP is clipping samples
-Lack of ASRC and sample rate switching with SPDIF sources makes dealing with varied input sample rates difficult
-Essentially unlimited IIR and FIR processing power

Okto DSP
-Low, fixed latency
-Accepts a wide variety of sample rates by dynamically switching processing rate
-More prone to digital clipping due to volume control downstream of DSP
-Gives indication on front panel if DSP has clipped samples and applies automatic attenuation
-DAC volume control can eliminate clipped intersample overs
-Limited IIR processing power, especially at high sample rates
-No FIR

Michael

 

[ah-ra]

I've put together a brief pros/cons list. Is this an accurate assessment/summary? I'm tempted to go with MiniDSP Flex HT and try it as a pure DAC with Camilla; and if Camilla proves too difficult to work with HT audio (resampling+complex pipelines/filters+ processing speed for audio/video sync), I can fall back to the internal filters.

	MiniDSP Flex HT (USB+Camilla)	MiniDSP Flex HT (HDMI)	Motu (Camilla)
SINAD	Best in class noise and distortion	With internal DSP, noise and distortion rises	Very good noise and distortion
Processing	Variable processing time	Fixed processing time (4.2 ms)	Variable processing time
Tweakability	Highly customizable	IIR/PEQ only, limited filters	Highly customizable
Sample Rate	Fixed (upstream resamples)	Variable (no upstream resampling), internally resampled to 48KHZ	Fixed (upstream resamples)
Input attenuation	Yes, with Camilla	No, digital clipping possible if input is clipped (should be rare)	Yes, with Camilla OR with Motu volume knob
Looks	1MU, sleek	1MU, sleek	1MU, rack mountable with extra ears, not WAF friendly
Cost	950	1000 with wifi dongle	700 with rack mounts

Sorry for the dumb question, but how would bass management work when using Flex HT via USB+Camilla? Do you still need to use the x-over function in the Flex then or can you somehow do the routing in Camilla and forward this to the Flex HT...? Could you also use the standard Flex via USB for this purpose (What's the benefit of the HT version here)?

Thanks!
Andreas

 

[danstahl]

Sorry for the dumb question, but how would bass management work when using Flex HT via USB+Camilla? Do you still need to use the x-over function in the Flex then or can you somehow do the routing in Camilla and forward this to the Flex HT...? Could you also use the standard Flex via USB for this purpose (What's the benefit of the HT version here)?

Thanks!
Andreas

The FlexHT and Camilla can both do bass management.

Camilla: https://github.com/HEnquist/camilladsp?tab=readme-ov-file#iir gives an example which includes high-pass filters and it can map any input channel to any output channel (ie, all non-bass inputs can be remapped to both the corresponding satellite AND to the subwoofer(s)). This is some code I wrote to generate the bass management configuration: https://github.com/danielhstahl/avprocessor/blob/master/src/pipeline.rs#L48-L83

FlexHT: https://docs.minidsp.com/product-manuals/flex-ht/signal-flow/bass-management.html#a-complete-example

 

[ah-ra]

The FlexHT and Camilla can both do bass management.

Camilla: https://github.com/HEnquist/camilladsp?tab=readme-ov-file#iir gives an example which includes high-pass filters and it can map any input channel to any output channel (ie, all non-bass inputs can be remapped to both the corresponding satellite AND to the subwoofer(s)). This is some code I wrote to generate the bass management configuration: https://github.com/danielhstahl/avprocessor/blob/master/src/pipeline.rs#L48-L83

FlexHT: https://docs.minidsp.com/product-manuals/flex-ht/signal-flow/bass-management.html#a-complete-example

Bass management within minidsp devices I'm quite familiar with but the combination of Camilla plus Flex HT I don't understand and the link doesn't really help me... Just to understand if I'm on the right path... If you connect the PC with Camilla) with the Flex via USB, you can do the routing in Camilla and you don't need the routing within the minidsp UI.

I'm completely new to Camilla, so I apologize if it's a dumb question...

 

[mdsimon2]

The Flex HT lacks bi-directional USB audio, this means if you want to use it with CamillaDSP you can only use the USB input. If using the USB input and CamillaDSP with the Flex HT, you could do the routing / processing in CamillaDSP or the Flex HT itself, although if you are using CamillaDSP you aren't really using much of the functionality of the Flex HT and it is just acting like a dumb multichannel DAC.

Michael

 

[ah-ra]

The Flex HT lacks bi-directional USB audio, this means if you want to use it with CamillaDSP you can only use the USB input. If using the USB input and CamillaDSP with the Flex HT, you could do the routing / processing in CamillaDSP or the Flex HT itself, although if you are using CamillaDSP you aren't really using much of the functionality of the Flex HT and it is just acting like a dumb multichannel DAC.

Michael

Okay, thanks a lot for the clarification. That's true, the Flex would then only be a multichannel DAC, but after reading the thread I thought that should be the goal to avoid any degradation in performance due to the filtering within the device.

 

[mdsimon2]

Important to note that only the Flex HT/HTx can be used as multichannel USB DACs. The normal Flex cannot.

I personally don't think worrying about the degradation in performance makes much sense. Although if you want to do a CamillaDSP and only need a USB input the Flex HT/HTx is a decent option as it has IR volume control, display and trigger output.

Michael

 

[ah-ra]

Important to note that only the Flex HT/HTx can be used as multichannel USB DACs. The normal Flex cannot.

I personally don't think worrying about the degradation in performance makes much sense. Although if you want to do a CamillaDSP and only need a USB input the Flex HT/HTx is a decent option as it has IR volume control, display and trigger output.

Michael

Great! Thank you for the clarification that only the HT version can be used as multichannel DAC.

I would probably use it for Acourate implementation instead of Camilla. Still I'm not quite sure if it's worth the effort over a standard Flex solution with integrated EQ and X-over function.

 

[sarieri]

I've put together a brief pros/cons list. Is this an accurate assessment/summary? I'm tempted to go with MiniDSP Flex HT and try it as a pure DAC with Camilla; and if Camilla proves too difficult to work with HT audio (resampling+complex pipelines/filters+ processing speed for audio/video sync), I can fall back to the internal filters.

	MiniDSP Flex HT (USB+Camilla)	MiniDSP Flex HT (HDMI)	Motu (Camilla)
SINAD	Best in class noise and distortion	With internal DSP, noise and distortion rises	Very good noise and distortion
Processing	Variable processing time	Fixed processing time (4.2 ms)	Variable processing time
Tweakability	Highly customizable	IIR/PEQ only, limited filters	Highly customizable
Sample Rate	Fixed (upstream resamples)	Variable (no upstream resampling), internally resampled to 48KHZ	Fixed (upstream resamples)
Input attenuation	Yes, with Camilla	No, digital clipping possible if input is clipped (should be rare)	Yes, with Camilla OR with Motu volume knob
Looks	1MU, sleek	1MU, sleek	1MU, rack mountable with extra ears, not WAF friendly
Cost	950	1000 with wifi dongle	700 with rack mounts

Minidsp Htx/Ht does not have the best in class noise&distortion unless they fix the multitone bug. They haven’t do anything about it for few months. I doubt they will ever come to any solution to it.

 

[danstahl]

Minidsp Htx/Ht does not have the best in class noise&distortion unless they fix the multitone bug. They haven’t do anything about it for few months. I doubt they will ever come to any solution to it.

My understanding was that the multitone bug was with DSP enabled; if it has the bug even with DSP disabled then you are correct.

 

[danstahl]

To close the loop, I did end up going with the MiniDSP and using its internal DSP. My setup is described here: https://www.audiosciencereview.com/forum/index.php?threads/my-av-processor-replacement.55171/. I ended up using a RBPi for the MiniDSP rather than the Vero4K. I wrote a custom app to handle the 12v trigger and control the MiniDSP: https://github.com/danielhstahl/minidsp-remote-control. I rarely, if ever, go above -20 on the MiniDSP so the multitone bug doesn't bother me (I doubt I would hear it anyway). At -20 I lose some SNR vs 0 but nothing that I can hear.

 

[sarieri]

My understanding was that the multitone bug was with DSP enabled; if it has the bug even with DSP disabled then you are correct.

It’s not with their DSP. The i2s output of the dsp board does not have the bug. Something is wrong with their implementation of the es9017s.