Please let us know how it goes. I assume after reading the data sheet again that if the device if configured properly in hardware mode the transmitter should work without the external oscillator because then it uses the MCLK to sync. The WM8805 has the benefit that is easier to source - at least for me (in EU) through Farnell, they don't have many Crystal ships anymore (but RS does). Also the Wolfson part is a lot cheaper (4.80 EUR vs 8.20 EUR without VAT). That part RS delivers it though SOIC packaged and so easier to use. Now I don't know anything about quality, I assume transmitter quality depends on the quality of the clock. Now if someone had really time and desire he or she could put all the "mods" on a single board combining the S/PDIF receiver, clock, ASRC and the S/PDIF transmitters so that they were at minimum distance (clean MCLK route) and cleanest power source for all of the devices on the same PCB.
E: There might be reason why the WM8805 doesn't work without oscillator: "When the device powers up all power up configuration pins are configured as input for a minimum of 9.4 us and .. The times are based on 27 MHz and 10 MHz crystal clock frequencies respetively."
This means the oscillator is needed in startup to read the configuration pins, and in HW mode it must be 12 MHz for clock and data recovery but in this case those features are not needed, and the jitter for PLL or sampling the configuration pins is no issue.
Last edited:
I have not tried the test (removing the XO) yet. hope to get to it soon.
question about the digital input mods: as I understand it, the dcx needs 24/96 audio to be presented to it and that's entirely the reason for the SRC chip. otherwise, if the system could take a native 44.1 or 48, it would not have to force a resample operation; but it always always resamples.
suppose I already have a native (converted or otherwise) audio stream at 24/96? eg, I have a behringer deq-2496 upstream that presents 24/96 (always, no choice) as its output. if this is the case, could I replace the SRC in the DCX with a simple spdif receiver chip? I realize that if I'm not sending in 96k, things 'wont work', but I'll ensure that its always 96k to the input of the dcx.
then, whatever clocking and resampling mods I'd have to do, I'd be better doing them at the INPUT of the deq, as that's the first place that 44.1 to 96 conversion would occur (in my setup).
is that correct? I don't want to mod the digital input to the dcx with yet another resampler if I don't need to. I do want an upgraded SRC in the deq, of course.
question about the digital input mods: as I understand it, the dcx needs 24/96 audio to be presented to it and that's entirely the reason for the SRC chip. otherwise, if the system could take a native 44.1 or 48, it would not have to force a resample operation; but it always always resamples.
suppose I already have a native (converted or otherwise) audio stream at 24/96? eg, I have a behringer deq-2496 upstream that presents 24/96 (always, no choice) as its output. if this is the case, could I replace the SRC in the DCX with a simple spdif receiver chip? I realize that if I'm not sending in 96k, things 'wont work', but I'll ensure that its always 96k to the input of the dcx.
then, whatever clocking and resampling mods I'd have to do, I'd be better doing them at the INPUT of the deq, as that's the first place that 44.1 to 96 conversion would occur (in my setup).
is that correct? I don't want to mod the digital input to the dcx with yet another resampler if I don't need to. I do want an upgraded SRC in the deq, of course.
I'm assuming that the internal architecture was designed with a simpler input assumption. I'm no DSP guy but it seems that if they have a constant input stream type, their design might be simpler. but that's just a guess.
I didn't try, but I assume that this system won't work (at all) if I bypass the SRC and simply inject 'native' 44.1/16 data into the i2s lines via my own spdif-rx chip?
I'm just assuming it needs 24/96, and so I'm planning on handling that elsewhere (probably in the deq stage, but perhaps even at the computer side, where I -could- resample in software and always send out 24/96 via usb).
I didn't try, but I assume that this system won't work (at all) if I bypass the SRC and simply inject 'native' 44.1/16 data into the i2s lines via my own spdif-rx chip?
I'm just assuming it needs 24/96, and so I'm planning on handling that elsewhere (probably in the deq stage, but perhaps even at the computer side, where I -could- resample in software and always send out 24/96 via usb).
One reason for the SRC is buffering between incoming data rate and internal clock.
You might want to start with this short thread, but take a look at some of the links therein. My understanding to your question is that it won't work the way you describe it.
http://www.diyaudio.com/forums/digital-line-level/177118-dcx2496-usb-input.html
http://www.diyaudio.com/forums/digital-line-level/177118-dcx2496-usb-input.html
It's best to upsample at the beginning of the chain. That's because the DEQ and DCX both internally always operate with 24/96. Downsampling would mean reducing/compressing existing data.
Regarding the S/PDIF connections there is always a PLL and SRC necessary even if there is a 24/96 to 24/96 conversion! That's because there are two different clock sources which are not synchronous. Quality of a 96/96 conversion is even a bit worse compared with a 44.1/96 conversion.
Regarding sound quality it's most important that the DACs have a low jitter clock. The wire between clock and DACs should be as short as possible and the clock needs a special power supply (low noise, high PSRR). Otherwise it's no low jitter clock any more.
A USB to I2S converter must use the clock of the DCX otherwise you need a sample rate converter. But as mentioned already before even if you use the DCX clock for the USB/I2S converter software must upsample your 16/44.1 data instead. This software conversion is most probably worse. So it's best to set the PC audio output to 24/44.1 to avoid software conversion.
That's why replacing S/PDIF by USB is no sonically improvement. This might be different if your audio data is all 24/96 (not upsampled).
my usb/i2s (or usb/spdif) converter, the audio widget from diyaudio fame, does have a local 24.576 clock on it. suppose I disable that and feed the AW the clock from the behringer? or maybe it should be the other way around?
but I think I have the freedom to connect those two and disable one. I'm not sure, but I think the way the AW works is that it uses a pair of local XO's and for 96k, it would pick the 24mhz clock. the incoming usb stream is asynch to this (that's one of the goals) and so, if a local 24.576 clock is given to the AW, it should 'just use it' I would think and the 2 devices are now in lock step. isn't that the goal?
but I think I have the freedom to connect those two and disable one. I'm not sure, but I think the way the AW works is that it uses a pair of local XO's and for 96k, it would pick the 24mhz clock. the incoming usb stream is asynch to this (that's one of the goals) and so, if a local 24.576 clock is given to the AW, it should 'just use it' I would think and the 2 devices are now in lock step. isn't that the goal?
With all due respect Frank, i think you are wrong. There is fundamental difference between SSRC /synchronous SRC/ and ASRC. In SSRC there is no time domain at all /there are just data - no time/ it is completely transparent operation with completely predictable output /with known algorithm/ see f.e. SRC Comparisons
output of ASRC depend on algorithm, input jitter and jitter of resampler clock.
I don't know if we can hear it but from purely technical stand point ASRC is without doubt inferior to SSRC.
Also quality resampling can be hardware intensive and hardware chips may not have enough horsepower do it without compromises.
So proposed best solution is - SSRC in PC to 96khz - transport slaved to DCX clock - DCX
It can be Asynchronous USB on dcx clock or SPDIF with transport slaved to DCX clock /no resampling in DCX in any case/
Last edited:
A SRC (sample rate conversion) - independent whether it is a synchronous or asynchronous conversion - is always a conversion of time domain. Otherwise it wouldn’t be a conversion. So there is always a loss of quality. A synchronous conversion is not influenced by jitter.
But a SSRC is not necessarily better than an ASRC. That depends on the quality of the different converters. Good ASRCs have a THD of about -140 to -150 dB. You can easily look it up in the datasheet of your hardware device. I’m not sure if everbody knows his used software algorithm and the quality of it. I have to admit I don’t know the quality of the different software converters I use. Because of that and the higher flexibility I (listening mostly to 16/44.1 audio data) prefer one single hardware ASRC in my audio chain. For other applications a software SRC might be the better choice although you can’t hear the difference.
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.
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.
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.
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.
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.
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.
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.
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.
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.