diy Optical SPDIF Switch?

[linuxworks]

Originally Posted by JRKO

how is this project going?

I've been a little lazy on this project as its working pretty well at the physical level; I have just not finished the firmware to talk to the wm8805 chip. I have code in place but have not spent time debugging it, yet. I mostly wanted to USE the chip for a while and see if I liked it and if it had any unpleasant side-effects. so far, after listening for several months, I'm pretty happy with it as an spdif receiver. I am planning on using it in a finished design.

the direction I'm thinking of going on my spdif switch is a bit of a hybrid approach. instead of doing the switching with this chip, I might just use it in 'dumb mode' (for the time being) where it has 1 input and 1 output. I can do the switching with simple ttl muxes ahead of the chip and this has the benefit of being able to completely remove the reclocker, on command, if you want to (or even need to). if the WM chip does the switching, you're forced to always route thru it.

I'm also thinking of making my spdif switch a bit bigger in scope. an spdif receiver has the option of decoding to i2s or re-encoding to spdif again (the reclock feature). I've recently been playing with 'affordable and easy' DAC chips and I'm thinking of simply adding one of these easy dac chips to the output of the i2s lines on the spdif 'switch'. its minimal cost and parts count.

the other thing I'm going to add is a dual switch feature. think of it as a digital version of a 'monitor' and a 'record' output. you can record one spdif source and listen to another (like tape loops and EPL loops of the old days) this is another reason I want to use simple TTL for spdif switching; I can have 2 of these for very little extra cost and board space and give the user lots of flexibility in his output routing. this would be something like a 4input 2output switch. one output would be switched spdif for 'record' and the other output would be a choice of analog (via that dac) or digital via the 2nd gang of the spdif switch.

I am not good at diagram drawing (lol) but this might illustrate what I'm shooting for, now:



this drawing is already out of date with my latest revision but its close enough for now. the bottom 2 teal 'boxes' are the 2 gangs of the spdif switch. 3 of the digital inputs are mirrored between the 2 switches with the recorder-playback not present on the last box, for hopefully obvious reasons not shown is the 'affordable dac' box but it would logically live in the 'spdif monitor' teal box, at the red switched output line.

this whole diagram is part of my overall preamp design; it incorporates analog switching and pathing as well as spdif where applicable. the spdif/dac box will be a separate chassis from the analog preamp-switch box. (for those who care, the EQ/XO is a behringer deq/dcx 2496 pair running active XO and 2 or 3 amps).

[SoNic_real_one]

Originally Posted by linuxworks

I'm pretty into the wm8805 series reclocker chips, at the moment, and they'll 'snap' the bits back to alignment pretty well. sort of like a layer1 repeater vs layer2 bridge. the retiming effect is analogous.

There is NO reclocking done in the WM8805. That crystal clock shown is for something else.

[linuxworks]

no reclocking? the output is supposed to be 40ps of jitter or less, as long as the input locks to it. their sheet starts out saying:

"a pass thru option is provided which allows the device simply to be used to clean up (de-jitter) the received digital audio signals"

is that not reclocking? how do you define reclocking?

[linuxworks]

fwiw, the way I tested 192k over toslink was with simple gear I had at home: an asus xonar ds (has a 192k grade toslink sender block on its rear tab) and an amb gamma1 dac that I know, for a fact, has a 192k grade toslink block (I built my copy and I know the schematic fairly well, lol). I set my linux box to force resample up to 192k (with some pulse audio .conf file magic) and played music. the green light on the dac locked and music came out. I sent that stream into a dac that I knew could 'only' do 24/96 and that dac would not lock. leaving the cable alone, I re-edited the linux conf file (forcing sampling to 96k, say), restarted pulse audio, replayed music and the 'old' dac played fine. the gamma1 dac would still play that 96k stream too. using some cheap no-name toslink connect.

it works. bits get there. you can argue its jitter, but bits do definitely get there

[SoNic_real_one]

Nobody says that it doesn't "work" as receiver. You just need to understand that nowhere on datasheet is mentioned any "reclocking", it just does not reclock.
"De-jitter" is done by the analog PLL loop and involved timing constants. Crystal clock is used only when there is no PLL lock onto incomming signal. In free running mode you have 50ps jitter. But if you have that PLL "lock", the output frequency will have jitter resulted from the incoming one. If incoming has 500nS on low frecuency, that's what you will have on the output. If it has a higher frequency jitter, that will be attenuated by the PLL loop - any SPDIF receiver works that way.
Is that relevant for PC HDD originating signals? Don't know how much jitter have those compared with a stand-alone optical transport.

Assuming anything else is just... assuming.

[linuxworks]

there is not a lot of internals in the data sheet, so there is a limit as to how far we can see into this chip.

I was only implying what they state explicitly. I don't pretend to know how they do it, but if they are not *ensuring* 50ps of jitter at the output, then things seem a bit misleading.

are you suggesting they are misleading on purpose?

they also do say 'de-jitter'. not imply, but say.

so, I'm not sure what to think. we have you saying it does not do this and we have the vendor saying they do.

??

[SoNic_real_one]

"De-jitter" not equal with "reclocking". Show me where in the whole data sheet is mentioned such thing.
Any digital receive will claim "cleaning the signal" and "de-jitter" - and that is true to an extent, for high frequency jitter, due to the PLL loops used for recovery of embedded clock.

WM don't mislead, but the first page of any datasheet is just a big ad. You need to read the whole datasheet... 50pS is for the "intrinsic jitter", not "recovered jitter" - that means is for the transmitter function, when crystal and not the PLL loop is used as source.

[linuxworks]

I wonder how the cirrus 8412/14/16 compares to the wolfson? the cirrus (crystal, when I first used the 8412) does not use a crystal (lol) but the wolfson does.

reading the data sheet, it seems the routing can have the recovered clock from the stream or from the xtal. what is the purpose of the xtal, in your understanding, if its not used to help align the audio data to it?

and I'm not sure that any receiver claims to de-jitter. does cirrus? I have not seem them make claims of this sort at all. in fact, their receivers tend to be sensitive to jitter, if anything.

btw, let me ask you - you seem to have a bone to pick with this chip or company. care to explain? have you actually measured the before/after effect of this chip? I have not (yet) and I may not be able to and so I have to trust the vendor in what they say. if you have data that suggests or shows this chip not to be what it represents, please show it.

but clearly, they are suggesting they clean the signal up from hundreds down to ten's. if you do have data that shows this to be false, I would love to see it.