Behringer DCX2496 digital X-over

[modmix]

Originally Posted by oettle

I have to admit I don’t know the quality of the different software converters I use.

Just in case...
some differences between various src: SRC Comparison

Ulli

[oettle]

Originally Posted by modmix

Just in case...
some differences between various src: SRC Comparison

Ulli

I’m aware of this comparison list, but I don’t know the algorithms of all players I use. So in best case I increase THD from -150 dB to -170 dB (I have to admit I can’t hear this difference.) but THD also could become much worse using the wrong algorithm.

Also this increase of THD is only possible with a USB to I2S converter which is synchronous to DCX clock. But what happens if my data source is a simple CD player or my TV or something else? That’s what I meant with better flexibility.

[tomtom]

Frank, i really don't want fight with you. I just want to find out best possible solution.

The output of ASRC - and therefore any measurement must depend on source jitter - the process cannot remove it. You just remove the awkward PLL clock recovery from SPDIF. So THD of process is dependable from jitter condition.

in SSRC time is JUST nominal value. there is no dependency on real time. It is just sequence of samples recounted to another sequence. Does excel sequence of data cell had time domain? Its thd and all other parameters are completely predictable. Im sure you know what i mean.

We are on DIYAUDIO here im sure that almost everybody is capable to install SOX on they foobar.

[linuxworks]

this reminds me of the old dat-heads wisdom about digital audio and how data to data transfer won't ever lose 'timing' until you are at the final stage where you convert from digital to analog.

d to d transfers are just data, like copying files. the only time timing matters is at the final analog stage. that's what we were all taught many years ago when we first were doing dat to dat tape copies. you could copy 100 times and the data would never change and cabling and such didn't matter. the only time it matters is when you expand from digital to analog, at the final step in the d->d->d->d->a chain.

[Julf]

Originally Posted by linuxworks

this reminds me of the old dat-heads wisdom about digital audio and how data to data transfer won't ever lose 'timing' until you are at the final stage where you convert from digital to analog.

And that is still true, unless you use a system/connection/setup where the clocking is also transferred over the connection, and you don't buffer/reclock.

[tomtom]

sorry but i dont know what are you trying to say /for linuxworks/

[tomtom]

Sorry but i have feeling that people dont really understand ASRC and SSRC difference. I apologize to everybody who already know it.

ASRC just look at data input in interval dependent on output timing. Only real purpose of ASRC is not to use clock from SPDIF line which is horrible. And for that purpose it work very well. But is not in any sense bit transparent - or capable of remove input jitter.

SSRC - can be completely offline - just process files. - or same thing but in real time before data is sent do DAC - Dac see just new resampled data.

[Julf]

Originally Posted by tomtom

Sorry but i have feeling that people dont really understand ASRC and SSRC difference. I apologize to everybody who already know it.

Old thread - Asynchronous Sample Rate Conversion

[qusp]

this also seems to disregard ASRC that doesnt change samplerate, only reclocks asynchronously wrt the input time, this can most certainly reduce jitter and it doesnt only have to do with spdif, just shifting the clock domain to the one local to and synchronous to the target dac.

[linuxworks]

Originally Posted by tomtom

sorry but i dont know what are you trying to say /for linuxworks/

what I'm trying to say is that its not hard to recover bits even if the jitter is absolutely horrible. capturing a bit and not caring about when it occurs, just that it did occur during a timeslot and it was seen to be a 1 or 0, that's enough to keep the data going across a data link. if the data only gets copied and never *played back* (converted to analog), then timing is not relevant and there's no timing to get lost. the timing is based on the bits and the clock at the final playback (dac) location.

and so, in the case I was talking about (the deq-2496 feeding to the dcx-2496), that link's jitter should not matter as its still just a data transfer and the timing comes entirely from the 8420 chip and the local clock on the behrginer (the dcx behringer).

on my modified dcx, I now have spdif-out links going to 2 (or eventually 3) stereo dacs. *those* links are where the timing is more critical, as some spdif receivers will depend greatly on that spdif data and others, less dependant if they locally reclock. but any digital to digital link that happens before this one is not relevant to audio quality as long as no bits are actually so bad that they are misread or dropped.