Behringer DCX2496 digital X-over - Page 343 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Line Level

Digital Line Level DACs, Digital Crossovers, Equalizers, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 21st December 2012, 01:14 PM   #3421
diyAudio Member
 
Join Date: Apr 2003
Location: Tampere Finland Europe
Quote:
Originally Posted by linuxworks View Post
otoh, if removing the tanks from the wolfson still lets it work, then it would be an even draw between them.
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 by mhelin; 21st December 2012 at 01:40 PM.
  Reply With Quote
Old 27th December 2012, 04:03 PM   #3422
diyAudio Member
 
linuxworks's Avatar
 
Join Date: Jul 2008
Location: santa clara, CA
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.
__________________
My Photostream:http://www.flickr.com/photos/linux-works/
  Reply With Quote
Old 27th December 2012, 04:22 PM   #3423
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
it only does 96khz because the filters are all generated at/for that rate?
  Reply With Quote
Old 27th December 2012, 04:31 PM   #3424
diyAudio Member
 
linuxworks's Avatar
 
Join Date: Jul 2008
Location: santa clara, CA
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).
__________________
My Photostream:http://www.flickr.com/photos/linux-works/
  Reply With Quote
Old 27th December 2012, 04:52 PM   #3425
Julf is offline Julf  Europe
diyAudio Member
 
Join Date: Oct 2011
Location: Amsterdam, The Netherlands
Quote:
Originally Posted by linuxworks View Post
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.
  Reply With Quote
Old 27th December 2012, 09:47 PM   #3426
diyAudio Member
 
zigzagflux's Avatar
 
Join Date: Oct 2006
Location: Charlotte, NC
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.

DCX2496 USB Input
  Reply With Quote
Old 28th December 2012, 03:43 PM   #3427
oettle is offline oettle  Germany
diyAudio Member
 
Join Date: Nov 2006
Quote:
Originally Posted by linuxworks View Post
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.
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).
  Reply With Quote
Old 28th December 2012, 04:06 PM   #3428
diyAudio Member
 
linuxworks's Avatar
 
Join Date: Jul 2008
Location: santa clara, CA
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?
__________________
My Photostream:http://www.flickr.com/photos/linux-works/
  Reply With Quote
Old 28th December 2012, 05:31 PM   #3429
tomtom is offline tomtom  Slovakia
diyAudio Member
 
Join Date: Dec 2006
Quote:
Originally Posted by oettle View Post

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.
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 by tomtom; 28th December 2012 at 05:37 PM.
  Reply With Quote
Old 28th December 2012, 10:02 PM   #3430
oettle is offline oettle  Germany
diyAudio Member
 
Join Date: Nov 2006
Quote:
Originally Posted by tomtom View Post
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/
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.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off



New To Site? Need Help?

All times are GMT. The time now is 08:16 PM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright ©1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2