DSP Measurements and Rising Noise Floor

[Sokel]

There is one way to make sure this is software or hardware based. Use a minidsp with Dirac software. Not 100% reliable, but should at least give slightly different results if the root cause is software. If you plot the results in a graph the difference should be visible.

I did tried a foobar xover plug-in which is dead simple (Linguitz Riley 24db @40Hz -3dbFS/Linguitz Riley 12db @40Hz -1dbFS) and the result was identical with the internal software.
I also did Multitone Analyzer's intersample overload tests (along with the gazillion others) just to make sure.
Seems that it's tied to hardware.
(note that my measurements were on the analog outputs,so much-much worst than the digital ones shown here,you can safely make the analogy from Amir's 114db SINAD vs 130+db SINAD here with pure digital )

 

[Marc v E]

Pretty sure it's the hardware limitation, even miniDSP admits as much and is the reason why you have limited filter taps or PEQ bands per channel. With a modest computer like a RPi or a tiny Windows box with a Celeron processor like Archimago demonstrates here you can do so much more.

Thank you for sharing this. I must say I'm both surprised and not at the same time. I work in software (as a performance automation engineer) and that's how I would look for a solution. What I don't get is: if a rpi can provide the processing power, why not use it in a minidsp device or use the same kind of parts? It doesn't make sense to me for hardware to be the limitation.

 

[HenrikEnquist]

These are super interesting measurements!
Would it be a lot of work to redo a few measurements with a camilladsp binary compiled to use 32-bit floats, instead of the default 64?

Thank you for sharing this. I must say I'm both surprised and not at the same time. I work in software as a performance automation engineer and that's how I would look for a solution. What I don't get is: if a rpi can provide the processing power, why not use it in a minidsp device or use the same kind of parts? It doesn't make sense to me for hardware to be the limitation.

The hardware is only one part. CamillaDSP (and other software DSPs) rely on FFT to do fast convolution. This has a few disadvantages that you probably don't want in a hardware dsp. The first is that it needs a lot more ram and storage to store and run the algorithms. The second is that it requires the sound to be processed in chunks of preferably a few thousand samples. This again needs more ram, and also adds quite a bit of delay. Hardware DSPs that support FIR normally perform the convolution directly with a hardware MAC engine (multiply-accumulate). This gives less delay (basically only the inherent delay of the IR) but needs a lot more calculations than FFT convolution. The IR length gets limited by the speed of the MAC engine. They can usually do a couple of hundred million MACs per second, which is divided by the samplerate and the number of channels to see how many are available per sample. That's the maximum usable number of taps. It usually ends up at no more than a few thousand, and often less.

 

[DWPress]

What I don't get is: if a rpi can provide the processing power, why not use it in a minidsp device or use the same kind of parts? It doesn't make sense to me for hardware to be the limitation.

Cost! Shark processors and similar used by miniDSP, Dayton and others is a programable IC as opposed to a fully functional computer. Despite the failings of miniDSP products (and remember everything demonstrated above is inaudible) they are actually really good at some things and they get you most of the way there - a gateway drug for DSP. They are self contained units as many of them don't require a computer after set up so the appeal is there for people who don't want a PC in the chain and are relatively affordable for what you can do with them.

 

[mdsimon2]

Would it be a lot of work to redo a few measurements with a camilladsp binary compiled to use 32-bit floats, instead of the default 64?

Yes, I can do that. Already had that on my mind as so far the DSPs with issues are using 32 bit floating point.

So far plan to test the following:

1) DDRC-24 (same hardware as 2x4HD but runs at 48 kHz)
2) miniSHARC running OpenDRC plugin (48 kHz, 2 channels)
3) miniSHARC running miniSHARC plugin (48 kHz, 8 channels)
4) CamillaDSP using 32 bit floats
5) CamillaDSP using FIR at 96 kHz (16K taps per channel)
6) CamillaDSP using FIR at 48 kHz (8K taps per channel)
7) miniSHARC using FIR at 48 kHz (8K taps per channel)

Michael

 

[jackocleebrown]

These noise floor shapes look familiar. The figure below is from Rhonda Wilson's 1993 JAES paper: "Filter Topologies". She demonstrates that quantisation errors/noise are amplified by the recursive part of IIR filters and that the error/noise in the output signal is higher when the pole frequencies are lower. She was analysing fixed point filters but since this amplification of the quantisation error is due to the recursive nature of IIR filters, similar issues could exist for floating point systems with insufficient bit depth, or bad scaling. I really love this paper because it's packed with elegant and highly efficient ways of working around this issue on fixed point systems.

R. Wilson, "Filter Topologies," J. Audio Eng. Soc., vol. 41, no. 9, pp. 667-678, (1993 September.). doi:

E-library page - AES

AES E-Library ← Back to search

www.aes.org

 

[cgardnerma]

Super interesting. The Emotiva and and Tonewinner pre-pros use the Sharc DSP and show this low frequency noise increase in the reviews as well. I think it is safe to say this is a characteristic - and probably an intentional design tradeoff/noise shaping decision - in these chipsets. Which all begs the question: If this is all below an audible threshold, does it matter? Is it a cost thing, or just engineers smarter than us making design tradeoffs? I am too lazy to look up the BOMs on all these chipsets, but its so great that all this data is becoming transparent. Love this site.

 

[Hayabusa]

Looks like we are seeing the effects of single precision floating point limits.
Time for double precision DSP's !

 

[Sokel]

These noise floor shapes look familiar. The figure below is from Rhonda Wilson's 1993 JAES paper: "Filter Topologies". She demonstrates that quantisation errors/noise are amplified by the recursive part of IIR filters and that the error/noise in the output signal is higher when the pole frequencies are lower. She was analysing fixed point filters but since this amplification of the quantisation error is due to the recursive nature of IIR filters, similar issues could exist for floating point systems with insufficient bit depth, or bad scaling. I really love this paper because it's packed with elegant and highly efficient ways of working around this issue on fixed point systems.
View attachment 267773
R. Wilson, "Filter Topologies," J. Audio Eng. Soc., vol. 41, no. 9, pp. 667-678, (1993 September.). doi:

E-library page - AES

AES E-Library ← Back to search

www.aes.org

This graph corresponds exactly at the30-40db SINAD hit that appears at 20Hz in Shark ones.
Really interesting stuff,thanks for the link!

 

[capslock]

This graph corresponds exactly at the30-40db SINAD hit that appears at 20Hz in Shark ones.
Really interesting stuff,thanks for the link!

Where do you see 30-40 dB hit? Maybe from 16 bit dither at -137 dB to - 97 dB?

What is more, I would not expect it to agree quantitatively. That was for 24748 bit integer math, whereas the Mini-DSP does single precision float.

I also wonder where that frequency independent line at -137 db came from. 16 bit should be good for - 98 dB quantization noise. Dithering may earn you a few dB but not 40, unless you have a higher sample rate and can afford to to noise-shaped dither. But in that case, the line will no longer be frequency independent.

 

[Sokel]

Where do you see 30-40 dB hit? Maybe from 16 bit dither at -137 dB to - 97 dB?

What is more, I would not expect it to agree quantitatively. That was for 24748 bit integer math, whereas the Mini-DSP does single precision float.

I also wonder where that frequency independent line at -137 db came from. 16 bit should be good for - 98 dB quantization noise. Dithering may earn you a few dB but not 40, unless you have a higher sample rate and can afford to to noise-shaped dither. But in that case, the line will no longer be frequency independent.

Both link's chart and the measurement below (even if you can't judge noise precisely by this) show a 50db hit at 20Hz compared with the 1Khz noise floor.Am I seeing it wrong?
Specially the charts refers specifically to this.

 

[capslock]

These noise floor shapes look familiar. The figure below is from Rhonda Wilson's 1993 JAES paper: "Filter Topologies". She demonstrates that quantisation errors/noise are amplified by the recursive part of IIR filters and that the error/noise in the output signal is higher when the pole frequencies are lower. She was analysing fixed point filters but since this amplification of the quantisation error is due to the recursive nature of IIR filters, similar issues could exist for floating point systems with insufficient bit depth, or bad scaling. I really love this paper because it's packed with elegant and highly efficient ways of working around this issue on fixed point systems.
View attachment 267773
R. Wilson, "Filter Topologies," J. Audio Eng. Soc., vol. 41, no. 9, pp. 667-678, (1993 September.). doi:

E-library page - AES

AES E-Library ← Back to search

www.aes.org

This is amplification of quantization errors due to the original word length and the filter coefficient length. What about real world noise, i.e. analog noise that is encoded in the signal? I suspect that will provide dithering, making the problem less pronounced.

What about corresponding op amp analog filters with filter components in the feedback loop? Will they too amplify LF op amp noise?

 

[jackocleebrown]

Where do you see 30-40 dB hit? Maybe from 16 bit dither at -137 dB to - 97 dB?

What is more, I would not expect it to agree quantitatively. That was for 24748 bit integer math, whereas the Mini-DSP does single precision float.

I also wonder where that frequency independent line at -137 db came from. 16 bit should be good for - 98 dB quantization noise. Dithering may earn you a few dB but not 40, unless you have a higher sample rate and can afford to to noise-shaped dither. But in that case, the line will no longer be frequency independent.

This is correct, it's not a like with like comparison because one is integer/fixed point and the other is floating so if it does match it would be a coincidence.

@capslock, the lsb of 16bit is at 20*log10(2^-15) = -90dBFS. If correctly dithered to avoid quantisation error the noise level will be around 3dB higher. But when you look at the noise spectrum the absolute level of the noise depends on the resolution of the analysis (the more frequency bins you have the lower it will appear).

 

[jackocleebrown]

This is amplification of quantization errors due to the original word length and the filter coefficient length. What about real world noise, i.e. analog noise that is encoded in the signal? I suspect that will provide dithering, making the problem less pronounced.

No, this is amplification of quantization errors in the IIR filter implementation itself. If the filter implementation is correctly dithered then this results in quantization noise amplification at the output. If there's no dither in the filter implementation then this results in distortion. This is irrespective of any dithering or noise before or after the IIR.

Quantization is required in a digital filter to maintain the same bit depth at the input and output. For example, if you have 16bit input data and 16bit filter coefficients you will require 31bits to store each multiplication between sample and coefficient without loosing any information. At the output you have to convert this back to 16bit, and this requires truncation / quantisation.

What about corresponding op amp analog filters with filter components in the feedback loop? Will they too amplify LF op amp noise?

Yes, it's a similar issue. If noise is generated by a component that's inside the feedback loop then this noise will be amplified.

 

[capslock]

This is correct, it's not a like with like comparison because one is integer/fixed point and the other is floating so if it does match it would be a coincidence.

@capslock, the lsb of 16bit is at 20*log10(2^-15) = -90dBFS. If correctly dithered to avoid quantisation error the noise level will be around 3dB higher. But when you look at the noise spectrum the absolute level of the noise depends on the resolution of the analysis (the more frequency bins you have the lower it will appear).

Thanks for pointing out the resolution issue. Yes, we just don't know the binning in that graph.

Also, yes, it makes total sense that adding noise will in fact degrade SNR. There are so many graphs out there that promise a lower noise floor with dithering without ever saying what the improvement is -- because there isn't any unless you choose to noise shape.

What is your point about the 90 dB? The SNR of an undithered 16 bit recording should be about 98 dB. https://en.wikipedia.org/wiki/Audio_bit_depth

With about 4 dB added noise in TPDF, we'd still have about 94 dB SNR.

 

[jackocleebrown]

Thanks for pointing out the resolution issue. Yes, we just don't know the binning in that graph.

Also, yes, it makes total sense that adding noise will in fact degrade SNR. There are so many graphs out there that promise a lower noise floor with dithering without ever saying what the improvement is -- because there isn't any unless you choose to noise shape.

What is your point about the 90 dB? The SNR of an undithered 16 bit recording should be about 98 dB. https://en.wikipedia.org/wiki/Audio_bit_depth

With about 4 dB added noise in TPDF, we'd still have about 94 dB SNR.

You do often see 96dB dynamic range stated for undithered 16bit audio (you said 98dB but Wikipedia says 96dB like just about everywhere else) but that doesn't really make sense if you think about it. 96dB comes from the calculation 6dB x 16 = 96dB, i.e. every bit gives additional 6dB SNR. However, with audio we're always talking about AC signals and one of the 16bits represents the polarity of the signal. The smallest AC signal you could encode would be oscillating from -1 to +1 (1 least significant bit or LSB). And the largest would be +32767 to -32767. The amplitude difference between these is 20*log10(32767) = 90.3dB.

Textbook dither to avoid noise modulation and quantisation distortion is +-1 LSB of TPDF dither. The RMS level of this signal is around 0.5 LSB. If we take the largest possible sinewave peaking at +-32767 LSB the RMS level of this signal is 32767/sqrt(2) LSB. The dynamic range of this system is 20*log10(32767/sqrt(2)/0.5) = 93.32dB.

This may seem like a strange way to look at things because it means that the dynamic range increases by 3dB when you add dither... but this is true!!!! https://www.aes.org/e-lib/browse.cfm?elib=4523

I recall that there's a great online demo of this somewhere.... wish I could find it now.

 

[mdsimon2]

For the additional tests going to add them as one set of measurements per post.

First CamillaDSP + UL Mk5 using 32 bit floats instead of the default 64 bit floats. This is actually much worse than the SHARC miniDSPs! Also note I needed to revise the scales for the dBFS stepped sine plots for the sub and low measurements as they were much higher noise.

Sub - CamillaDSP + MOTU Ultralite Mk5 32 Bit Floats

Base: Input RMS -1.00 dBFS, THD: -151.4 dB based on 49 harmonics [20..22000 Hz], N: -147.7 dB [20..22000 Hz], THD+N: -146.2 dB [20..22000 Hz]
Sub: Input RMS -7.28 dBFS, THD: -86.6 dB based on 49 harmonics [20..22000 Hz], N: -72.4 dB [20..22000 Hz], THD+N: -72.3 dB [20..22000 Hz]

Low - CamillaDSP + MOTU Ultralite Mk5 32 Bit Floats

Base: Input RMS -1.00 dBFS, THD: -151.5 dB based on 49 harmonics [20..22000 Hz], N: -147.7 dB [20..22000 Hz], THD+N: -146.2 dB [20..22000 Hz]
Low: Input RMS -5.20 dBFS, THD: -107.8 dB based on 49 harmonics [20..22000 Hz], N: -67.3 dB [20..22000 Hz], THD+N: -67.3 dB [20..22000 Hz]

High - CamillaDSP + MOTU Ultralite Mk5 32 Bit Floats

Base: Input RMS -1.00 dBFS, THD: -151.9 dB based on 21 harmonics [20..22000 Hz], N: -147.9 dB [20..22000 Hz], THD+N: -146.4 dB [20..22000 Hz]
High: Input RMS -19.63 dBFS, THD: -135.8 dB based on 21 harmonics [20..22000 Hz], N: -98.7 dB [20..22000 Hz], THD+N: -98.7 dB [20..22000 Hz]

Michael

 

[mdsimon2]

Switching from the miniSHARC-4x8-96k plugin to the miniSHARC-4x8 plugin which runs at 48 kHz results in decent improvement at low frequencies.

First I want to show the frequency response at 48 kHz to show the high frequency warping effects compared to 96 kHz.

Sub - miniSHARC 48k

Base: Input RMS -1.03 dBFS, THD: -146.4 dB based on 49 harmonics [20..22000 Hz], N: -124.5 dB [20..22000 Hz], THD+N: -124.5 dB [20..22000 Hz]
Sub: Input RMS -7.46 dBFS, THD: -141.0 dB based on 49 harmonics [20..22000 Hz], N: -116.6 dB [20..22000 Hz], THD+N: -116.6 dB [20..22000 Hz]

Low - miniSHARC 48k

Base: Input RMS -1.03 dBFS, THD: -147.2 dB based on 49 harmonics [20..22000 Hz], N: -124.5 dB [20..22000 Hz], THD+N: -124.4 dB [20..22000 Hz]
Low: Input RMS -5.38 dBFS, THD: -150.7 dB based on 49 harmonics [20..22000 Hz], N: -112.7 dB [20..22000 Hz], THD+N: -112.7 dB [20..22000 Hz]

High - miniSHARC 48k

Base: Input RMS -1.01 dBFS, THD: -148.6 dB based on 20 harmonics [20..22000 Hz], N: -124.6 dB [20..22000 Hz], THD+N: -124.6 dB [20..22000 Hz]
High: Input RMS -10.75 dBFS, THD: -147.6 dB based on 20 harmonics [20..22000 Hz], N: -122.1 dB [20..22000 Hz], THD+N: -122.1 dB [20..22000 Hz]

Michael

 

[mdsimon2]

Overall using the OpenDRC 2x2 plugin instead of the miniSHARC-4x8 plugin resulted in a minimal difference as they are both running at 48 kHz.

Sub - OpenDRC

Base: Input RMS -1.03 dBFS, THD: -148.1 dB based on 49 harmonics [20..22000 Hz], N: -124.4 dB [20..22000 Hz], THD+N: -124.4 dB [20..22000 Hz]
Sub: Input RMS -7.46 dBFS, THD: -133.0 dB based on 49 harmonics [20..22000 Hz], N: -114.4 dB [20..22000 Hz], THD+N: -114.3 dB [20..22000 Hz]

Low - OpenDRC

Base: Input RMS -1.03 dBFS, THD: -148.8 dB based on 49 harmonics [20..22000 Hz], N: -124.5 dB [20..22000 Hz], THD+N: -124.4 dB [20..22000 Hz]
Low: Input RMS -5.38 dBFS, THD: -149.1 dB based on 49 harmonics [20..22000 Hz], N: -110.2 dB [20..22000 Hz], THD+N: -110.2 dB [20..22000 Hz]

High - miniSHARC 48k

Base: Input RMS -1.02 dBFS, THD: -151.1 dB based on 20 harmonics [20..22000 Hz], N: -124.6 dB [20..22000 Hz], THD+N: -124.6 dB [20..22000 Hz]
High: Input RMS -10.75 dBFS, THD: -148.3 dB based on 20 harmonics [20..22000 Hz], N: -121.7 dB [20..22000 Hz], THD+N: -121.7 dB [20..22000 Hz]

Michael

 

[mdsimon2]

As with the miniSHARC platform the 2x4HD does better when running at 48 kHz, in this case using the DDRC-24 plugin.

Sub - DDRC-24

Base: Input RMS -1.03 dBFS, THD: -149.9 dB based on 49 harmonics [20..22000 Hz], N: -124.4 dB [20..22000 Hz], THD+N: -124.4 dB [20..22000 Hz]
Sub: Input RMS -7.31 dBFS, THD: -134.9 dB based on 49 harmonics [20..22000 Hz], N: -115.5 dB [20..22000 Hz], THD+N: -115.4 dB [20..22000 Hz]

Low - DDRC-24

Base: Input RMS -1.03 dBFS, THD: -149.0 dB based on 49 harmonics [20..22000 Hz], N: -124.4 dB [20..22000 Hz], THD+N: -124.4 dB [20..22000 Hz]
Low: Input RMS -5.37 dBFS, THD: -150.5 dB based on 49 harmonics [20..22000 Hz], N: -113.0 dB [20..22000 Hz], THD+N: -113.0 dB [20..22000 Hz]

High - DDRC-24

Base: Input RMS -1.01 dBFS, THD: -149.7 dB based on 20 harmonics [20..22000 Hz], N: -124.4 dB [20..22000 Hz], THD+N: -124.4 dB [20..22000 Hz]
High: Input RMS -10.74 dBFS, THD: -140.8 dB based on 20 harmonics [20..22000 Hz], N: -116.8 dB [20..22000 Hz], THD+N: -116.8 dB [20..22000 Hz]

Michael