• These commercial threads are for private transactions. diyAudio.com provides these forums for the convenience of our members, but makes no warranty nor assumes any responsibility. We do not vet any members, use of this facility is at your own risk. Customers can post any issues in those threads as long as it is done in a civil manner. All diyAudio rules about conduct apply and will be enforced.

Reference DAC Module - Discrete R-2R Sign Magnitude 24 bit 384 KHz

Benchmark Media makes provision for an extra 3.5dB headroom in their DAC2 Digital to Analog Audio Converter - they claim sample rate conversion can cause digital clipping if the input signal is at 0dB. Your clipping may have a different origin, but it is interesting nonetheless.

High Headroom DSP - with 3.5 dB "Excess" Digital Headroom

All of the digital processing in the DAC2 HGC is designed to handle signals as high as +3.5 dBFS. Most digital systems clip signals that exceed 0 dBFS. The 0 dBFS limitation seems reasonable, as 0 dBFS is the highest sinusoidal signal level that can be represented in a digital system. However, a detailed investigation of the mathematics of PCM digital systems will reveal that inter-sample peaks may reach levels slightly higher than +3 dBFS while individual samples never exceed 0 dBFS. These inter-sample overs are common in commercial releases, and are of no consequence in a PCM system until they reach an interpolation process. But, for a variety of reasons, virtually all audio D/A converters use an interpolation process. The interpolation process is absolutely necessary to achieve 24-bit state-of-the art conversion performance. Unfortunately, inter-sample overs cause clipping in most interpolators. This clipping produces distortion products that are non-harmonic and non-musical . We believe these broadband distortion products often add a harshness or false high-frequency sparkle to digital reproduction. The DAC2 HGC avoids these problems by maintaining at least 3.5 dB of headroom in the entire conversion system. We believe this added headroom is a groundbreaking improvement.

See: Benchmark DAC2 HGC - Digital to Analog Audio Converter - Benchmark Media Systems, Inc.
 
OK, the attenuation to cater for clipping out of the filters should be in the actual filter coefficients of course. This would be a e.g. rePhase configuration. No?

//

The dam1021 filter parameter file have a "multiplier" parameter, normally set to compensate for the zero insertions that would attenuate the signal.

Most filter generators if set correctly will output a parameter file that need gain when oversampling using zero insertions, like a 44.1K to 352.8K usually need a gain of 8, but look at the largest taps, they need to be normalized to 1.

See 1021filt.txt for examples.
 
Disabled Account
Joined 2005
The dam1021 have 2-4 bit of headroom though the digital filters, all the way until the volume control.

So any clipping would be because of incorrect filters.

Apparently SoX has no headroom and the clipping seems to be a commonly reported phenomena.

The one that clipped worst when using SoX was the default 44.1 filter coefficents. The ones I'd done in rePhase had far lower levels of clipping.
 
The dam1021 filter parameter file have a "multiplier" parameter, normally set to compensate for the zero insertions that would attenuate the signal.

Most filter generators if set correctly will output a parameter file that need gain when oversampling using zero insertions, like a 44.1K to 352.8K usually need a gain of 8, but look at the largest taps, they need to be normalized to 1.

See 1021filt.txt for examples.

... You don't need to worry about saturation, the filters coefficients floats are converted to 2.30 fixed format.

I think, numerically the multiplicator is a bad idea. You loose here three bits of acureancy with the taps (and with FIR2 again).
While designing the tabs you have all the time you need. There you can compute with any acourancy needed, so that you can provide the already normalized taps with the full accurancy the DAC works with.
 
Last edited:
I think, numerically the multiplicator is a bad idea. You loose here three bits of acureancy with the taps (and with FIR2 again).
While designing the tabs you have all the time you need. There you can compute with any acourancy needed, so that you can provide the already normalized taps with the full accurancy the DAC works with.

I just a simple practical thing, the multiplication factor is just an easy way to normalize FIR parameters to 1 in the .skr file.... It don't have anything to do with accuracy as it works with the floating point input parameters.
 
Floating pont is never accurate ;)

If you stay with 2x 4x 8x you can do bit shift. Thats accurate.

//

That depends.... Try expressing very small numbers in fixed point format, like some of the FIR coefficients....

But there are two things here:

1) The format that rePhase outputs, should be floating point with many digits as it don't know the actual hardware....

2) The format the actual hardware use, in case of the dam1021 it's 2.30 fixed point format for the FIR filters and 3.29 fixed point format for IIR filters. FPGA's are not good at floating point....

The mkrom utility read and process the input .txt parameter files as 64 bit floats, including the multiplier, then convert to the 2.30/3.29 fixed formats in the final step, which are pretty good, t.ex. the SigmaDSP chips use fixed 4.24 format for coefficients....
 
Well, it wont get any better with float :)

So, OK for coefiicients in float. But when the filter is finished and say 8x gain is needed, why not do shift left 3 instead of a arithemtic float operation?

Maybe a 8x in float ends up like a shift??

//
With 64 bit floats (doubles) you have 52 bit mantissa and 11 bit exponent. That is 52 bits accuracy. if you multiply or divide by two you only alter the exponent, thus you stay with 52 bits of acurancy.

With a 32 bit fixed point numbers you have at most 32 bits information (if you have only small numbers you loose a lot by the leading zeros and deviding by two makes you loose one bit acurancy.

So if you use doubles for the arithmetic and convert only in fixed points in the last step to submit to the FPGA (as it seems to be done here) you should be save.
 
.....................FPGA's are not good at floating point....................

So far nobody is concerned about the final oversampling/upsampling to 2.822 MHz (a kind of filter itself); does this mean that it has so effect on the final sound?

I understand your views on oversampling/upsampling and anti-image filter. For the hardcore NOS & No filter enthusiastics; is there any possibility that all digital processing could be turned off and 44.1 kHz is presented as it is for conversion? A no filter, no over/up sampling firmware in future?
 
I think the word "pushed" need some scrutiny...

//

TNT, kindly help me understated where I am wrong. I am not challenging you but I am unable to understand that with the final sampling rate of 64x (2.822MHz) why the following principle is not applying to this DAC.

From http://www.analog.com/media/cn/training-seminars/tutorials/MT-017.pdf
"For instance, oversampling is common in digital audio CD
players, where the basic update rate of the data from the CD is 44.1 kSPS. Early CD players used
traditional binary DACs and inserted "zeros" into the parallel data, thereby increasing the
effective update rate to 4-times, 8-times, or 16-times the fundamental throughput rate. The 4×,
8×, or 16× data stream is passed through a digital interpolation filter which generates the extra
data points. The high oversampling rate moves the image frequencies higher, thereby allowing a
less complex lower cost filter with a wider transition band.
"
 

TNT

Member
Joined 2003
Paid Member
Well, the energy between Fs/2 and Fs I believe is still there but gets weaker if interpolation is made. The DAM dont do interpolation as I understand it so the alias beteween Fs/2 and Fs is still there. So I was wondering if bands are pushed away as in transponded to somwhere else. That was what I was thinking about. I just wanted to learn if this was really the case, hence the scrutinization :)

//