CS8421 upsampling in a DAC

[Wingfeather]

Hi there,

I'm looking into building my first DAC and have settled preliminarily on the CS4398 (I hear it's used in the Lynx sound cards and they have a reputation you don't mess with). Choice of DAC chip is not the issue, or at least not just yet, anyway.

I listen mostly to CDs so all my data is 44.1kHz. However I'm interested in the idea of upsampling to 176.4kHz (or 192kHz if that's not too nasty) before sending to the DAC to take advantage of the fact that the anti-alias filter is now well out of the way.

The SRC chips I've found are all aynschronous in nature, such as the CS8421 and the AD/TI equivalents. However, everyone here seems to use them primarily for jitter reduction purposes and it's hard to know what people think of their actual resampling performance.

I use an RME sound card as my source (for digital crossovers, see the thread(s) started by shinobiwan for the general idea - many thanks to him by the way for his inspiration) so my source component can be sync'd to the clock inside the DAC. This puts me in what I think is a rather unique position:

* I will be able to use the ARSC chip in a truly "synchronous" 1:4 upsampling manner by generating all the relevant fixed-ratio clocks inside the DAC *

I like the idea of clocking backwards from the DAC for all the reasons outlined in other threads - jitter is nipped in the bud. All you're left with is the jitter of your master clock, which can be made nice and low (I've been looking at the Analog Devices' emerging line of clock generators, and the jitter they produce is of mouth-watering <1ps proportions). And the clock source is now physically close to the actual DAC ICs to maximise this effect.

What do people think of this approach? I can't see anything in the datasheet of the CS8421 relevant to this particular method.

Hope someone has some tasty ideas

Thanks

[ezkcdude]

Are you going to use the MCLK from the RME card?

[Wingfeather]

Nope.

The idea is the generate a master clock for 176.4kHz playback (so, some multiple of 11.2896Mhz) on the DAC board, then divide this down to provide a suitable word clock for the RME card to work from. That way the card and therefore the whole playback system is slaved to the DAC's clock, and the DAC can rejoice in low-jitter heaven.

Besides, how would you get the MCLK from the soundcard anyway?

Thanks.

[Werner]

Originally posted by Wingfeather
However I'm interested in the idea of upsampling to 176.4kHz (or 192kHz if that's not too nasty) before sending to the DAC to take advantage of the fact that the anti-alias filter is now well out of the way.

1) Anti-Imaging Filter, or Reconstruction Filter. Anti-Aliasing is what is done in original sampling (ADC) or downsampling.

2) Oversampling = Upsampling. Exactly the same thing, exactly the same class of filter required. The CS4398 internally does so to 352.8kHz for CD data. See Figures 20 and 24 in its datasheet.

[Wingfeather]

1) Anti-Imaging Filter, or Reconstruction Filter. Anti-Aliasing is what is done in original sampling (ADC) or downsampling.

I always forget that! My bad.

2) Oversampling = Upsampling. Exactly the same thing, exactly the same class of filter required. The CS4398 internally does so to 352.8kHz for CD data. See Figures 20 and 24 in its datasheet.

You know, I should have known that. I had a feeling the two were similar, but I also thought the oversampling process was tied up with the delta-sigma modulation somehow (and not yet having taken the time to go over delta-sigma theory I put that whole kettle of fish to one side).

I've heard people raving over this and that digital filters (most notably the PMD200 and the DF1704/DF1706 chips) - will the oversampling quality of the 4398 DAC match the 32-bit (24-bit dithered) process of the 8421? Nothing on the filter implementation seems to get a mention in the datasheet.

Could filter quality be a valid reason for using an external upsampler?

Thanks

[Werner]

Originally posted by Wingfeather

I had a feeling the two were similar, but I also thought the oversampling process was tied up with the delta-sigma modulation

True. Before the arrival of delta-sigma DACs oversampling of x4, x8 (to x64 for Wadia, but they cheatet a bit) was strictly used to allow digital-domain anti-imaging filtering. Then came DS with its need of an x64 to x256 datarate. In these cases the first x4 to x8 were used traditionally, i.e. with (relatively) high accuracy anti-imaging filters. The gap to the required x64-x256 was filled in with linear interpolation and even sample replication, i.e. without any interesting filtering features.



Could filter quality be a valid reason for using an external upsampler?
[/QUOTE]

Probably. Most filters on silicon are crap (*), compared to what is really (mathematically) required of them. Most are a result of trade-offs, and it is not inconceivable that some trade-offs sound better than others. Datasheets won't tell, although you'll have noticed that your DAC chip on its own already offers two flavours of filter.


(* Like short FIR length, ~100-200 taps, lower internal accuracy, economic half-band design with only 6dB attenuation at fs/2, insufficient stop band rejection, excessive pass band rippling, ... With over 1000 taps and internal 32 bit or better processing you can make a perfectly monotonic filter with over 140dB of stop band rejection ... off-line on a PC. But this is all sort of moot as non-oversampling DACs prove that you can do without. Sort of.)

[Glassman]

Originally posted by Werner
Probably. Most filters on silicon are crap (*), compared to what is really (mathematically) required of them. Most are a result of trade-offs, and it is not inconceivable that some trade-offs sound better than others. Datasheets won't tell, although you'll have noticed that your DAC chip on its own already offers two flavours of filter.


(* Like short FIR length, ~100-200 taps, lower internal accuracy, economic half-band design with only 6dB attenuation at fs/2, insufficient stop band rejection, excessive pass band rippling, ... With over 1000 taps and internal 32 bit or better processing you can make a perfectly monotonic filter with over 140dB of stop band rejection ... off-line on a PC. But this is all sort of moot as non-oversampling DACs prove that you can do without. Sort of.) [/B]

Very well said! Spot-on description of the situation in hifi and even socal 'hiend' upto these days.. Only I would change Probably to Definitely. Now there is a question whether ASRC corrects this or is a mere alternative on about the same level as the internal oversampling filters in DACs. I'd certainly say it's the latter. The filter you described sounds very much like upsampling filters we use in our product. And boy it makes a difference, a difference of a class..

[Werner]

Originally posted by Glassman

The filter you described sounds very much like upsampling filters we use in our product.

Could you tell us about your products and filters?

[Glassman]

take a look at our website, linked in my profile..

[Wingfeather]

Werner,

Thanks for your replies, they are interesting reading. Am I to take it that you are a fan of non-OS DACs?

I guess this is one of those times when it's difficult to make any real arguments one way or another without more solid data on filter implementations, etc. But I can well imagine that the implementation of the oversampling filter in the DAC is not optimal.
One option (for me, at least) is to resample in software on the source computer. I would have to do this in advance of my crossover filters and thus it would seriously increase their CPU requirements, however it should be possible. I would probably end up using FFDshow's resampling for non-music and a winamp plugin (there are several) for music. Or even write a winamp plugin of my own to understand the process better. Of course, on a PC the processing resolution can be huge, with only a final dither down to 24-bit. Would this provide a better end result?
One immediate problem I can see is that it's not possible to entirely defeat the oversampling process in the 4398 (or indeed most DACs for that matter) and so that even if I were to feed in nicely resampled 176.4kHz data it would still perform its oversampling function, albeit there would be less of it. Do you have any idea what differences (if any) would result?

Thanks.