Convertus Decima Digital

The easy way

Few weeks ago I published the results of my studies and tests reguarding the usage of decimation in a zero-oversampling DAC. Unfortunately I had not yet been able, at the time, to find a digital process that could obtain decimation in an easy way, while protecting the audio signal from any contamination.

Just after a few days from the publication I was studying how to connect another DAC chip to a CS8412, and all of a sudden I found out what I had not been able to understand for a couple of years - the easy way to decimation.

I will not spend time here about the reasons for decimation. If you want to have an in depth discussion you can just have a look at the article about the non-digital Convertus Decima.

The approach

The solution was indeed really simple. It just required some more understanding of CS8412 capabilities.

CS8412 digital receiver gets an S/PDIF flow on one side and, in the way we have used up to now in Convertus and Convertus Decima (Normal Mode 2, I2S compatible), from this is able to build four digital flows:

• a master clock MCK (11.2896 MHz, 256*Fc), which is the raw output of the PLL,
• a bit or serial clock, SCK (2.8224 MHz, 64*Fc), that gives the pace with which the single data bit are output (there are 32 data bit per channel in the flow)
• a frame sync, or left-right, clock (FSYNC, 44.100KHz, Fc), that shows when a new word is output and which is the channel the data bits currently being output refer to
• the data flow

Now, MCK and DATA are always outputs, but SCK and FSYNC can be programmed, using the four configuration pins M0-M3, as input or output. Mode 3 (M0=1,M1=1,M2=0,M3=0) in particular is I2S compatible too, but the data flow is output on the basis of a SCK and FSYNC that must be provided from an external circuit.

So in theory, if we would like to make our life complicated just by purpose, we could simply select Mode 3, take MCK from CS8412, divide it by 4 to build a SCK and then divide the SCK by 64 to build an FSYNC, feed these SCK and FSYNC back to the 8412 and everything would work exactly as with the normal rig.

This is obviously due to the fact that the 8412 has been specifically built for this purpose, and data are therefore double buffered if FSYNC and SCK are configured as input.

CS8412 has also some specific predefined behaviours in case the SCK and FSYNC clocks are asynchronous to the input flow. In case a new word is requested by FSYNC clock before a new one has been read, an error flag is raised, but there is no "hole" in the output data flow: the old sample is re-output again.

On the other side, TDA1543 supports by the way up to 4x oversampling; FSYNC (named WS in TDA1543 documentation) can be as high as 192kHz and the SCK (BCK) frequency can be up to 9.2 MHz.

So here is the idea: if we build a SCK with a 5.6448MHz rate (128*Fc) and a FSYNC with a 88.2KHz rate (2*Fc) and send them into the CS8412, the 8412 will output two identical data sample bit sequences for each input sample. The error flag will be raised, but from the point of view of the data flow it will work fine.

On the other side, the TDA1543 will assume the input data flow has been oversampled with a x2 factor, and will output the single samples in sequence with a rate that is the double of the normal. Obviously each channel output will anyway remain at the same level for 2 FSYNC cycles, that is for a full Fc cycle, as in the digital flow any couple samples (one for each channel) is repeated twice.

Now if we mask out one of the two identical digital samples, forcing all its bits to zero, the DAC will output one sample with the original value for an FSYNC cycle, and a null voltage for the following one.

As FSYNC is here the double of Fc=44.1KHz, we have our decimated output, and an easy way too to enable and disable digital decimation.

I am not completely sure this is really a situation taken into account by who designed CS8412. As a matter of fact, normally there is no need for extracting data in a faster way than usual. But even though on the data sheets this situation is not taken into account, the case of an SCK clock asinchronous (and sepecifically faster) with respect to the SPDIF derived clock is taken into account and described, and the design uses these features: so it should prove sound. I have tested it in two different layouts, with two different receivers and with two different converters, and it works fine in both cases.

The circuit

The implementation of Convertus Decima Digital is therefore rather simple.

The CS8412 must be set to mode 3 instead then mode 2 (raising pin M0 to +5V). MCK is the taken to U3 and U4, two four bit binary dividers arranged in chain, so that the second counts when the first goes in overflow, but are both synchronous with MCK.

The MCK/2 clock (QA of U601) is our new SCK/BCK, to be taken to the CS8412 and to the DACs. The MCK/128 (QC of U602) is instead the new FSYNC/LRCK. The MCK/256 clock (QD of U602) is instead used mask out one sample out of two, but must be correctly aligned with FSYNC by delaying it for one BCK cycle; this is obtained by the D type flip flop U603B, which is clocked with a MCK/4 (this has the leading edge synchronous with the trailing edge of SCK). The two NAND gates are used to blank out one out of two SDATA samples based on the delayed MCK/256 clock.

In order to disable decimation it is enough to connect the preset pin (/PRE) of U603B to ground: in this case its output Q remains always high, and SDATA goes through unmasked all the time. The DAc receives therefore two identical samples and maintains the same output level for a full Fc cycle.

The sound

For what regards the sound, digital decimation has exactly the same effect as the analog one. The apparent output level is decreased, but apparently the drop is higher at low frequencies than at higher ones, so that the overall balance is improved, with greater detail, greater impact and apparent speed.

Is there any great improvement in sound with respect to analog decimation? Well, I would not dare saying so, because I find even the analog one to be very quiet and clean, with no special noise. But as a matter of fact this way seems for sure more safe and more correct than the analog one to implement decimation.

In fact, here's the easy way.