[linuxworks]

I've been kicking around the idea for a while now - and searching is not showing a lot in the DIY area for spdif digital audio selectors.

I found this article which is quite good and has so much useful info in it:

Remote Controlled AV Switch with S-Video, Composite Video, and Audio

its a bit old and needs some updating but most of the elements you need are there.

what I'm thinking of is a really simple and easy spdif input selector that can be linked to a DIY preamp or DAC. for example, on a home preamp I'm building, I would like to have an input selector that might choose line/analog in and also some digital ins. if my preamp is analog-only and I will be using outboard DACs, then I'd like to have a remote switcher for just the spdif parts but have it be controllable by the preamp (the preamp will 'own' an IR receiver module and so it could very easily have a 2bit address pair to select 4 remote inputs, in some other metal box, somewhere).

so the interface would be something like 4 spdif inputs and 1 (or even 2 parallel, opto/coax) output - but the control line would be 2 wires that come from a 'master' device and would select input 00, 01, 10 or 11 (in binary). pretty easy and could even be done with simple rotary switches if you didn't need remote IR control.

I'm not sure I want any 'smart' ports that listen for activity and auto-pick an input. that's often more trouble than its worth (imho). manually selectable ports are all that I need.

any interest in something like this? alternately, anyone started any work on it that I could leverage from?

 

[n_maher]

S/PDIF 4:1 Receiver/MUX Module

Brian is a member here so you might ask him for some guidance. Or you could save yourself a world of hurt and just buy one of his modules.

 

[linuxworks]

thanks for the ptr! I had not seen that. looks very cool.

it seems to have a receiver chip (which I admit is a better way than the 'pure analog' way of using the cmos mux buffer chip I was thinking of).

I still might try to do a more simplified design since I'm not sure I actually *need* another receiver chip in my chain. all my wiring will be stereo-rack distances which don't technically need repeating/retiming.

also, I may want to link an existing hdmi switch so that I get parallel hdmi/spdif input selecting. that might also be an optional part of my project.

its not much of a world of hurt - and I sort of want to do some spdif design work, anyway, just for fun and experience.

 

[error401]

Remember that S/PDIF is 1Vpp (or is it 2V?), which complicates things considerably, you can't just use digital logic directly. Relays are probably the easiest route; if you want to go solid-state, you'll need some kind of analog switch, but I don't think you'll find a way to do it without causing serious impedance mismatch issues or really destroying the signal.

The only reasonable ways I can think of are to either use relays (which kinda messes with the transmission line...) or a full differential receiver on each input and then a digital switch (I'd probably use tristate buffers, just because it's so easy to expand), then back to a proper differential transmitter to the output.

 

[linuxworks]

spdif is either .5v p-p OR its ttl level if you import/export via toslink.

if I take the easy way out, I can use ttl as my middle format and convert to and from to, for the 'edges'. switching TTL should be cake

I'm going to try slow-ish ttl or cmos chips (would it matter: 7400 vs 4000 series?) but I'll also try the fancy video switcher (analog) chip, the lt1204 chip that the article references.

I am pretty sure that will work ok - the whole design paradigm of spdif coax (at least) was that it integrate well with existing 75ohm video infrastructure. they did this on purpose - so ANY thing that switches or passes composite video should also work for spdif/coax.

there's also an old project called the DSD (data stream dissector, was one name for it) back in the early 90's that 'helped' spdif get across consumer DAT decks. they used a full spdif receiver, pal and encoder to recreate spdif streams. here's the file history:

Index of /dat-heads/dsd/dsd-v0.7

that could even be the heart of an spdif switcher (it does that but its not remotely addressable which is one of my goals). I'd probably take the spdif i/o circuits from that design (its old and proven).

so I'll first try something like a 4052 switch and see if my signal passes thru ok enough.

I am assuming that any modern dac will reclock so I'm not TOO worried about jitter. I really am not, as all modern dacs 'deal' with jitter well enough (imho!).

 

[error401]

Hmm I guess I really don't know what I'm doing. I looked at this problem some time ago and just dismissed analog switches out of hand as causing too much voltage offset or something. Looking at even the ancient cheap ones now though, they seem like they'd do the job. Buffer each input with an HCU04 buffer (Cheap as chips, lots in a package and Jocko likes it, it must be good!) or a video opamp and then stick a proper s/pdif transmitter on the output and you're good, I'd think. Maybe I'll revisit that project I had...this looks easy now.

If you're feeling ambitious and like flashy, mostly useless features, you could do some rudimentary frequency timing and guess the frequency of the input on an AVR or something, and also indicate no signal.

 

[linuxworks]

in fact, I have an old DSD mod that I did (I published it back in the early 90's when I was somewhat involved with that DSD dat-heads project) that shows in 2 7seg led displays the actual sample rate (00, 32, 44, 48). there was no 96 back then (lol).

I think the PAL did the frequency selection and outputs 2 leds which I then mapped to the 2 7segment digits.

here's an ugly shot of my ancient box:

I won't show the insides since its not one of my better/cleaner builds - but it does work pretty well.

the code is public for that PAL, I think, so in theory it could be borrowed and updated to more modern chips (if that pal is still around; I don't know).

 

[linuxworks]

(doublepost)

 

[linuxworks]

Quote:

Originally Posted by error401 /img/forum/go_quote.gif Hmm I guess I really don't know what I'm doing.

hmm - you seem to be one of the very clueful ones. I always like reading your posts, they are quite informative and useful.

Quote:

I looked at this problem some time ago and just dismissed analog switches out of hand as causing too much voltage offset or something. Looking at even the ancient cheap ones now though, they seem like they'd do the job. Buffer each input with an HCU04 buffer (Cheap as chips, lots in a package and Jocko likes it, it must be good!) or a video opamp and then stick a proper s/pdif transmitter on the output and you're good, I'd think.

yes, the 74hcU04 is the golden part and has been for well over a decade, now.

I'm not sure what I plan to do about media types; opto vs coax. if I choose ONLY opto as my i/o format then life is easier - the toslink modules are native ttl leveling and less parts (just a cap and choke to get them stable on the power bus and that's all). with rca connectors, you need 1:1 pulse trannys, a few R's and small bits of 75ohm coax (to be in spec). with spdif/coax I'll have to raise the level from a half volt up to ttl so that I can 'switch' things, then back down to coax level if I want that as an output format.

otoh, if I omit toslink entirely then I have at least a chance of supporting 96k (which is not supported on plastic toslink, afaik). if I kept things at simple .5v levels for coax then I could use relays and ignore the solid state switching chips and really make my life easier

not sure which way to go. I don't tend to use or care much about 96k and I like the isolation and almost universal connectivity of toslink (more of my devices speak toslink than coax, these days).

 

[error401]

Why wouldn't the analog switches work at 0.5vpp?

 

[linuxworks]

they would and should work with half a volt input.

I was thinking that if I use toslink as my i/o type, I could just leave the levels, inside, at TTL. I'm guessing but I wonder if having a 'hot' signal inside might be better compared to 'only' a half a volt. the noise level might be better if the signal is 5v or logic-1 level instead of little itty bitty 1/2 volt. but I might be wrong in that assumption.

 

[cetoole]

If you are buffering the inputs with a 74HCU04, you could just use that to also bring the coax inputs up to TTL levels. I have no idea what the best approach to this is, and it is something I have been wondering about myself. I dont see why you need the coaxial cable for this project, why not just board mount the I/O jacks, and since this is DIY, why not also use BNC? It certainly seems easiest to do SPDIF switching by just using a receiver with a built in MUX. You know, Mouser now stocks the WM8805, which is a great little chip, and it would be beneficial for the DIY community if someone with uC programming abilities would do something with it (nudge, nudge; I am clueless here).

 

[linuxworks]

that 8805 chip looks neat but it has to have software running it. the hardware native mode is too dumb (it just ends up being a receiver/transmitter - which is useful but not useful enough for me)

too bad they didn't also provide a real 3bit binary addr (dumb mode) to switch the input lines. they missed an opp, there - not everyone wants a uP in their design. I'm not sure I do, to be honest.

note the use-case of what I plan to do with this: the switch will be inches (or a foot, at most) from the dac. the dac already has an 8416 cirrus chip for receiving the spdif stream and dejitter. adding another won't make anything better - and only adds complexity.

if I was running a long wire AFTER the switch, it might make sense to retime. and if my input cables were long, also - I'd want to do a more proper receiving job; but in a home stereo rack the distances are short enough that I've never found the *need* to have to retime or regenerate spdif.

I'm going to try the super simple way first and see if it works.

 

[cetoole]

I guess that was basically my point, its a great receiver, but Wolfson, in their infinite wisdom, decided to make it reliant on a uP if you want to use more than one input. I know you are a software guy, and figured you would already have some kind of processor in here for use with the remote, so put two and two together to get five.

Why not just use the mux on the 8416, maybe with remote switches? The simple way should work just fine, it is amazing what you can make SPDIF go through and still lock fine, like random twisted pair wiring, rca jacks, header terminals, random PCB traces, ect.

 

[linuxworks]

its true the 8416 in my dac has input selection. but I don't want to depend on it, I want a more generic solution.

one hairbrained use-case is to send 2 bits out of the chassis for control. just literal 2 wires to carry the 4 combos in binary. some 'pod' on the outside would connect to that and have 4 inputs and 1 output (and a wallwart or something). that lets me have a remote 'easy' wire control of an input selector and all the crazy digital stuff can go outside my analog box (pimeta, etc) and if I want to get really crazy, I can link this 4 input switch to a similar hdmi one and really have a nice hdmi/spdif input box. again, a diff box that is not part of my preamp.

the thing is - each time I try to partition where things go, I often end up with the IR receiver board (as a whole unit, considering it closed blackbox for now) inside the preamp and yet I want to have remote control of some external stuff. that's why I'll have those 2 address lines from my preamp going OUT of the box to a remote pod or box that does the spdif switching. it also means I don't have to waste inside space and jack space on i/o jacks that can be better done in some remote pod. I may actually just take an hdmi switch in a metal chassis and add in my spdif parts, trying to sneak them in where there's room in the box

maybe.

in software, we call this 'loosely coupling' functional boxes

while its not the most efficient, it does have enough generality in re-use to make up for that.