Hi,
looking at Michaels analog measurement, I would say there is NO real jitter problem and this is based on at least 2 non Tento clocks (DAC ONYX and ADC+DAC DCX). So why has the digital measurement a lot of jitter, although using the same clocks?
A reason is that there is a 44.1 kHz data input at the DCX which must be converted to a 96 kHz data stream whithin the CS8420. That's a factor of about 2.18 which looks pretty difficult.
What's the advantage of an internal 96 kHz data stream with a 44.1 kHz input? I asume there is only a disadvantage: jitter.
One very simple solution could be:
The CS8420 recovers clock from the S/PDIF input (pin 'RMCK'). So why shouldn't we use this?
It is easy to have a 74HC002 on top of the CS8420. So you can select via 'RELDIG' whether 'CLK24' or 'RMCK' is switched (via a 22 ohm resistor) to IC19A, pin 51 (former 'CLK24').
The result would be that in analog input mode there is no change at all (96 kHz) and in S/PDIF input mode the DSP and all DACs would operate at the same frequency (44.1, 48, 96 kHz) as the data input.
Spend 1 bug an test it! I will do so soon.
greetings,
Frank
The
looking at Michaels analog measurement, I would say there is NO real jitter problem and this is based on at least 2 non Tento clocks (DAC ONYX and ADC+DAC DCX). So why has the digital measurement a lot of jitter, although using the same clocks?
A reason is that there is a 44.1 kHz data input at the DCX which must be converted to a 96 kHz data stream whithin the CS8420. That's a factor of about 2.18 which looks pretty difficult.
What's the advantage of an internal 96 kHz data stream with a 44.1 kHz input? I asume there is only a disadvantage: jitter.
One very simple solution could be:
The CS8420 recovers clock from the S/PDIF input (pin 'RMCK'). So why shouldn't we use this?
It is easy to have a 74HC002 on top of the CS8420. So you can select via 'RELDIG' whether 'CLK24' or 'RMCK' is switched (via a 22 ohm resistor) to IC19A, pin 51 (former 'CLK24').
The result would be that in analog input mode there is no change at all (96 kHz) and in S/PDIF input mode the DSP and all DACs would operate at the same frequency (44.1, 48, 96 kHz) as the data input.
Spend 1 bug an test it! I will do so soon.
greetings,
Frank
The
Frank,
I think the DSP in the DCX needs as much resolution (real or artificial) as possible to work. The digital filtering works by doing a lot of multiplies and divides on the input data. If you stay with 44.1/16bit, the best you can do the calculations are to 16 bit accuracy. Its like a digital vol control. If you go down 6dB, one half level, you effectively lose 1 bit and go back to 15 bit accuracy. It is similar with the DSP. So, you go to 96k/24bit, then do your math, then convert back to analog.
Jan Didden
I think the DSP in the DCX needs as much resolution (real or artificial) as possible to work. The digital filtering works by doing a lot of multiplies and divides on the input data. If you stay with 44.1/16bit, the best you can do the calculations are to 16 bit accuracy. Its like a digital vol control. If you go down 6dB, one half level, you effectively lose 1 bit and go back to 15 bit accuracy. It is similar with the DSP. So, you go to 96k/24bit, then do your math, then convert back to analog.
Jan Didden
oettle said:
Sorry, but isn't the advantage obvious? By running at a fixed 96kHz rate, you only ever need one set of filter coefficients. If you need to support 44.1, 48, 88.2 and 96, you have to continually re-compute the filter coefficients every time your sample rate changes.
This is an entry-level piece of pro audio gear. It's highly unlikely that they would consider minimizing jitter to be a high priority compared to features and/or price.
This won't work, since your filters will be all wrong. The DCX dsp REQUIRES a 96kHz digital input signal; there is simply no way around this.
If you want to bypass the ASRC, you'll have to ensure that you're always sending 96kHz, which means an external upsampler, and all the external hardware boxes use basically the same approach as the DCX does. The only approach that would seem interesting to me along these lines is to go all the way and eliminate spdif entirely, and use a PC and software upsampling with a modified Transit outputting I2S @ 96kHz. I don't know whether anyone has tried this, but "it should work".
Hi dwk123,
I think you are right. The DSP math should be based on 96kHz only. Would have been too easy.
So the only way to bypass the CS8420 is to have a 96kHz input. 3-wire I2S would be best. Similar results should be possible with S/PDIF and CS8420 set to mode 5 (receiver only without sample rate converter).
Remains the question what impact has the upsampling software on the data?
regards,
Frank
I think you are right. The DSP math should be based on 96kHz only. Would have been too easy.
So the only way to bypass the CS8420 is to have a 96kHz input. 3-wire I2S would be best. Similar results should be possible with S/PDIF and CS8420 set to mode 5 (receiver only without sample rate converter).
Remains the question what impact has the upsampling software on the data?
regards,
Frank
Hi
just found some interesting and easy to read articles about sonic impacts of sample rate conversion:
software:
http://www.audioease.com/Pages/BarbaBatch4/Barba4SRCTest.html
hardware:
http://www.tcelectronic.com/media/christensen_lund_rate_conv.pdf
greetings
Michael
just found some interesting and easy to read articles about sonic impacts of sample rate conversion:
software:
http://www.audioease.com/Pages/BarbaBatch4/Barba4SRCTest.html
hardware:
http://www.tcelectronic.com/media/christensen_lund_rate_conv.pdf
greetings
Michael
This is getting interesting!How do you do this,Set it to mode5?
I read sommewhere (can´t remember where)that DCX do NOT recive clock signals via S/PDIF but uses it´s own internal clock,but only at 88.2 Mhz,is this whats called a "Free running osclillator"?Is This True?
Maybee this "Mode 5" thing could help me get rid of the crackling if the level is to high,with 96khz.I do SRC with a M-1000 digitlamixer..
Hi Ryssen,
The DCX has an internal 24.576 MHz crystal. Divided by 256 this is exactly 96 kHz. The DSP and all ADCs and DACs use this clock. In analog input mode the 96 kHz sample rate is an advantage.
In digital input mode there are two problems: 1. Having a 44.1 or 48 kHz source you have to up sample data. 2. Your data source has a different clock which is asynchronous to the DCX clock.
Both tasks are done by the CS8420 which first recovers the clock with a PLL from the S/PDIF data stream and then up samples and synchronizes the data with a sample rate converter.
Having 96 kHz data only it would be pretty easy. You just have to do the 74HC002 mod and if this works you even can switch off the sample rate converter at all (hardware mode 5: DFC0 (pin 2) and DFC1 (pin 27) = high).
Not having 96 kHz data you could first up sample data on the PC which is probably better but it's a little bit running in a loop. Another solution could be a better? sample rate converter like AD1896 (Oehlbach mod).
Best would be to mod the DSP firmware. Having the source I assume it wouldn't be such a big issue changing some filter parameters. But I haven’t heard about DCX firmware mods so far.
Frank
The DCX has an internal 24.576 MHz crystal. Divided by 256 this is exactly 96 kHz. The DSP and all ADCs and DACs use this clock. In analog input mode the 96 kHz sample rate is an advantage.
In digital input mode there are two problems: 1. Having a 44.1 or 48 kHz source you have to up sample data. 2. Your data source has a different clock which is asynchronous to the DCX clock.
Both tasks are done by the CS8420 which first recovers the clock with a PLL from the S/PDIF data stream and then up samples and synchronizes the data with a sample rate converter.
Having 96 kHz data only it would be pretty easy. You just have to do the 74HC002 mod and if this works you even can switch off the sample rate converter at all (hardware mode 5: DFC0 (pin 2) and DFC1 (pin 27) = high).
Not having 96 kHz data you could first up sample data on the PC which is probably better but it's a little bit running in a loop. Another solution could be a better? sample rate converter like AD1896 (Oehlbach mod).
Best would be to mod the DSP firmware. Having the source I assume it wouldn't be such a big issue changing some filter parameters. But I haven’t heard about DCX firmware mods so far.
Frank
Dipend of what problem we are talking. My understanding is that Ryssen had crackling problem with DCX. I had similar problem before I added SRC. I had that problem even with S/PDIF going throughDEQ and than sending AES/EBU to DCX. When I dropped SRC in the chain the problem was gone. By some miracle it even sounds better if I chose upsampling from 44.1 to 96 at SRC, I do not know why.
oettle said:
I had also a drop-out problem with my DCX, which I got rid of by using a small S/PDIF to AES/EBU converter (the schema and pcb is in the files section of the Yahoo DCX users group).
I don't know the internals of the SRC, but chances are they use the same 8420 (and surely the same ADC and DAC) as in the DCX, so I ask myself, what's the improvement I can expect?
BTW, what is the "Oelbach mod"?
Jan Didden
Hi Jan,
Here you are: http://freerider.dyndns.org/anlage/Behringer-Input-Stage-E.htm
The Oehlbach mod is using a AD1896 sample rate converter which might be better. Havn't looked in datail to this mod so far. I think the basic idea is to use a better sample rate converter and better PLL. Best would be to get rid of all that up and down sampling stuff.
I couldn't find your S/PDIF to AES mod so far. Do you have a more detailed link? My experiance was that the DCX has some problems with typical S/PDIF voltage levels (too low). That's the reason for my toslink converter mod.
Frank
Here you are: http://freerider.dyndns.org/anlage/Behringer-Input-Stage-E.htm
The Oehlbach mod is using a AD1896 sample rate converter which might be better. Havn't looked in datail to this mod so far. I think the basic idea is to use a better sample rate converter and better PLL. Best would be to get rid of all that up and down sampling stuff.
I couldn't find your S/PDIF to AES mod so far. Do you have a more detailed link? My experiance was that the DCX has some problems with typical S/PDIF voltage levels (too low). That's the reason for my toslink converter mod.
Frank
oettle said:
That was the reason for my S/PDUIF to AES/EBU converter.
You can find it in the 'files' section in this user group:
http://tech.groups.yahoo.com/group/DCX2496/
... but you need to register to become a member.
Jan Didden