Schiit (MultiBit) Bifrost (DAC digital filter techno-discussion)

You can do a maximally flat filter also known as the Butterworth approach as opposed to an equi-ripple filter also known as the Chebyshev approach.

The price you pay for a maximally flat filter is a less step roll-off.

You can have something in between known as the Legendre filter I think.

There are no "gimmicks". Just trade-offs.

The tone and some of the things Bruno is claiming in that brief do not inspire me confidence TBH.

Also, don't think much of what Bruno is alluding to relates to what Schiit is doing. I believe Schiit is concerned about input samples coming out untouched at the output of the filter while doing a great job at interpolation by using a fairly large FIR, among other things.

BTW, You can do a fairly large equi-ripple window filter with vanishing ridiculously amoeba fart ripple.

 

I couldn't see the whole brief before. Second part he seems to be having issues with "brickwall" filters.

Usually "brickwall" filters are implemented using IIR class filters. In particular, the Elliptical filter is used often due to it's sharp cut off. IIR filters usually don't exhibit linear phase, and have issues close to the corner frequency. There are Bessel IIRs that have a slow roll-off, but better phase response. None of that is an issue here.

Most of the filters mentioned here (including the specific Parks-McClellan, LS, Window diz, Window dat, Burrito Frijolero) are FIRs and exhibit linear phase. My understanding is that they are all sort of "brickwall" but through brute force, i.e. having relative large number of taps. So, again, his concerns don't apply AFAIK to the class of filters we are discussing:

Large Linear-phase FIRs

Looking at the Mola Mola page, dude claims a 6th order Cheby Polynomial Interpolator. Maybe he is using a polynomial approach using a Farrow or maybe he is using a FIR. It is not clear. But his filter may exhibit ripple since he claims to be using a Chebyshev approach. And then he using a "7th order ripple compensated PWM noise shaper"... 1-bit at that.

It may sound awesome. But I feel this approach is not very close to what I think Mike/Jason are doing.

 

Well, yup. When designing an audio IC I believe corporations try to target as wide a market as possible. This means size, weight and power considerations, as you mention, are important.

One of the things I didn't like about his write up was:

"Another classicical short cut is making a fairly sharp filter like the classical brick wall filter which is then centered around exactly half the sampling rate which means that you still get some aliasing which is not as evil as you would think but which is just kind of a mathematical gimmick again to reduce the number of cycles and the amount of processing power that you need."

I don't agree that aliasing is "not as evil", or "kind of a mathematical gimmick". Aliasing is a very real form of unpleasant non-linear distortion. And dealing with it does not mean reduction of the number of cycles and the amount of processing power. It means the opposite. To generate a very sharp filter that will still have linear phase and remarkable interpolation performance one needs a fairly large filter. The sharper the cut off the more the number of taps and horse power required, if all other requirements remain the same. So to me this is kind of an Obi-Wan statement.

It is based on some truth though. If one fixes (or reduces) the number of taps and resorts to IIR filtering (which is likely what many ICs may be doing), then a sharp cut-off may require an approach that compromises phase response and ripple. But if we are talking a situation where you are going to use a dedicated processor instead of the built-in digital filters, then saying aliasing is "not as evil", but passband ripple "which corresponds to a small pre-echo and a small post-echo... completely kills all body in the sound" seems a bit of a hand-wavy statement putting too much weight on passband ripple, and too little in anti-aliasing for whatever possible self-serving purposes.

As far as the "Filter Stopband Comparision" for the Soekris DAM1021 r2r dacs custom filter, the youtube link says the following:

"Comparison of stop band performance of stock and custom high attenuation filters for the Soekris DAM1021. Filters coefficients were applied to a short music sample using SoX to illustrate the behaviour of the stop band. Static filter response plots don't capture the way the stop band behaves whilst filtering audio."

This is sort of misleading IMO as well. AFAIK "static" (they are really not exactly static) filter response plots do capture the way the stop band behaves whilst filtering audio. But music files may or may not have significant ultrasonic noise. The filter attenuation is relative to input signal level. And this is true whether you are in digital or analog domain.

 

Messed up with the files. Will give you new ones.

Basically the left and right channel are in a single channel mono! And it would give you some nasty echo for sure. Sorry about that.

Matlab handles stereo different than Octave

 

Here are the new files. Sorry about that.

NOTE THESE ARE TWO CHANNEL FILES (left and right channel). I one needs only one channel and JRiver takes care of putting the same thing on both channels let me know and I'll create single channel files.

 

Kaiser indeed is likely closer to stock. AWESOME DUDE. Multiply my "like" by 1k.

Note LS and ParksMcClellan are shorter filters. I feel that once you get in the kilo taps range, one might actually want to consider window methods. It's hard to get Parks to converge when you have tons of taps, perhaps due to precision errors in the calculation of the tabs.

And with kilo taps, you are really getting pretty close to a sinc anyway.

Will put other window filters in the mix later today.

 

Here is the corrected chebySincThune_18001_64 filter...

EDIT: Shit, that one was correct. Attaching regenerated file here anyway.

 

So, so far Kaiser mega filter appears to be doing bestest, correct Lucks?

EDIT: BTW, one could built in headphone compensation (equalization) to the DAC filter.

 

From what I'm reading here:

http://wiki.jriver.com/index.php/Convolution

One might need to rename the filters by appending 2.0_1764 to the name of the file.

But not sure.

Audio files might need to be 176.4 kHz. I could change the wav label to 192 kHz too.

 

Oh! I think I know what you mean.

I guess try just upsampling the 44.1kHz sound file w/o interpolation (just insert 3 zeros in between samples, S/H does some sinc stuff in the passband). Then let JRiver apply the filter... I think.

 

Seems like so. Would be nice if JRiver allowed to specifiy filter for upsampling.