# IC: DIY spdif switcher



## 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.


----------



## linuxworks

Quote:


  Originally Posted by *cetoole* /img/forum/go_quote.gif 
_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. _

 

here's the 'processor' I'll be using:







 link:

TinyIR2 Learning IR remote control receiver

 its a black box - no source code, of course ;(

 it gives me active-high outputs and I 'take it from there'.

 that's life in the integration business - you often don't have access to other internals and HAVE to view things as 'velcro integration' so to speak


----------



## BrianDonegan

nm


----------



## linuxworks

update: the proto works. it was simple, like I had hoped (planned. no, hoped, really) 
	

	
	
		
		

		
		
	


	














 just a 4052 analog switch (using half of it) with toslink opto blocks in and 1 going out.

 the usual choke/cap bypass for the toslinks is there.

 no reshaping at all. just real low-budget 'does it work' testing.

 it seems to work. and given how good modern dacs are, I'm not 100% convinced its worth 'prettying up' the signal any more than it is now. I'm getting lock and I'm hearing sound. that's at least a good start 
	

	
	
		
		

		
		
	


	




 for testing I'm using back-to-back gamma1 dacs. one is a half build (just the usb/spdif board) and that gets me opto-out from my pc. I go into this switch and then out of it into another Y1 dac that takes opto-in spdif and makes analog sound from the other end 
	

	
	
		
		

		
		
	


	




 dial in a 2 bit binary address and the right input port is mapped to the single output.

 $20 or less in parts.

 perhaps I'll work this up into a proper project. I've now learned how to deal with controllers and lcd displays (and IR remotes) and so just having a remote controlled user-label display that picks digital inputs - that could be cool just on its own (?)


----------



## Pricklely Peete

Wow totally cool !!! 

 I love following your projects in the hopes of learning some of this stuff 
	

	
	
		
		

		
		
	


	




 On the 1 out jack how hard would it be to use a combi jack (SPDIF and Optical ?) like the one used on the Auzen Prelude SC digital output ? It would mean using a plastic adapter for Toslink out but you could use a SPDIF as normal without much or any SQ loss.

 Of course it's just something that occurred to me while reading this thread that might give you some additional flexibility provided the additional circuitry can be incorporated. Maybe 1 in and 1 out using the combi jack ? I have no idea what part number that is or where to source one. It seems to do a very good job with the Auzen card. I can get a solid 24/96 signal lock via Tolsink using a plastic fiber cable NP whatsoever to the HT processor 3m away using this jack (same goes for SPDIF coax).

 If this idea (is lame and) counterproductive to what you are trying to do please forgive my lack of knowledge and experience and go easy on me 
	

	
	
		
		

		
		
	


	




 Peete.


----------



## Gatsu

Grats on getting on HackaDay





 Personally I've never worked with that PIC before (only worked with the PICAXE so far) but it looks like he may have given enough information to allow reverse engineering of the code.


----------



## linuxworks

Quote:


  Originally Posted by *Pricklely Peete* /img/forum/go_quote.gif 
_Wow totally cool !!! _

 

thanks 
	

	
	
		
		

		
		
	


	




  Quote:


 On the 1 out jack how hard would it be to use a combi jack (SPDIF and Optical ?) like the one used on the Auzen Prelude SC digital output ? It would mean using a plastic adapter for Toslink out but you could use a SPDIF as normal without much or any SQ loss. 
 

sounds like something like this?











 that's a combo opto+coax jack. tricky stuff! 
	

	
	
		
		

		
		
	


	




 if the connector is buyable, sure, why not. its only a physical layer thing - the bits are the same. 

 I'm thinking about how to best give flexibility in 'physical jacks' and try to decouple that from the main board design.


----------



## linuxworks

Quote:


  Originally Posted by *Gatsu* /img/forum/go_quote.gif 
_Grats on getting on HackaDay



_

 

that blew me away - I had no idea at all 
	

	
	
		
		

		
		
	


	




 I noticed a HUGE spike in my view-count on flickr and it wasn't until someone replied on that photo that it was on H.A.D. ha!
  Quote:


 Personally I've never worked with that PIC before (only worked with the PICAXE so far) but it looks like he may have given enough information to allow reverse engineering of the code. 
 

no need to reverse engineer, the source will be coming along with schematics. first, though, some testing has to be done. it passes the 'yup, bits are flying' test but I'd like to do a bit more test equip-level testing before throwing out circuits. so far, I'm encouraged but I know the crowd here is mighty picky about their bit accuracy (lol). more testing is needed but it does look good, so far.


----------



## linuxworks

new photos of the thing being 'bits in flight' tested:






 here is my first test, going across media types going from a gamma1 'lite' (usb to spdif), thru the switch and then out via opto to a full gamma1 dac.












 the wiring isn't exactly to-spec (LOL!) but I'm just doing INFORMAL testing at this point. the last 2 pics show it going from coax up to TTL level (for the switch), thru the switch chip and back down to coax level (half volt) again. source was my 'popcorn hour' media streamer and sink was my m-audio superdac2496 (many years old AKM-based dac). bits flew and I heard the music just fine. 

 until the battery died.

 and then it was jumper cables for the rest of the nite


----------



## TeraHz

Nice switch linuxworks. Do you know if the digital-analog-digital conversion affects the bit stream? That is, have you tried passing encoded audio through the switch without breaking it (like DTS or DD)?


----------



## linuxworks

Quote:


  Originally Posted by *TeraHz* /img/forum/go_quote.gif 
_Nice switch linuxworks. Do you know if the digital-analog-digital conversion affects the bit stream? That is, have you tried passing encoded audio through the switch without breaking it (like DTS or DD)?_

 

it cannot affect it. not in *this* switch.

 this switch does not go above the PHY (physical) layer. it does not 'unwind' packets or understand them at all. nothing is edited or changed. its just a physical repeater, not even a real bridge (in the datacomm sense).

 since dts and dd5.1 don't use enormously higher data rates than normal old spdif, I'm sure they will be as bit-perfect as pcm, thru a switch like this. in fact, dts will refuse to 'run' if it gets less than bit-perfect data presented to it (same with dd5.1, I think). so if you get a signal 'lock' light, at all, you're golden.


----------



## linuxworks

I should update this thread. I think I even forgot about it 
	

	
	
		
		

		
		
	


	




 here's what I have, right now, on this spdif project:

 I re-did the coax-in section. in fact, I'm making this a very modular design so you (the builder) can pick what options you want and not have stuff you didn't.

 here's the coax-in 'port board' in proto form:










 parts needed for it:






 and there is is, being tested (it works):






 that's the coax-input board (with 2 independant ports).

 now the switch guts, the 'fabric' as its sometimes called:






 and the initial wiring, just getting started 
	

	
	
		
		

		
		
	


	









 this is where the switching happens. this chip supports up to 8 input ports. I am going to build for 4 (the row of 4 red headers). it supports 1 ttl output which directly drives opto-out and can drive a coax-out in a similar board fashion like the coax-in board.

 here's an opto port; there's little point in this having its own 'board' so I air-wire it and secure it (well) to the rear panel with a screw. much better than board mounting even though its a lot more work:










 that mostly covers the switch and its i/o 'port boards' (or flying ports, in the opto case, lol).

 next post has some info on the cpu controller that is made for this.


----------



## linuxworks

here's the controller photos, also using proto board (no pcb designed. yet.)




















































 this sort of turned into a project all in itself 
	

	
	
		
		

		
		
	


	




 but from it comes a general purpose i/o (lcd, IR remote) board that I can re-use in all my other DIYs. 

 here's where I used it, to integrate some functions in amb's latest y2 (gamma2) dac:


----------



## TeraHz

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_this switch does not go above the PHY (physical) layer. it does not 'unwind' packets or understand them at all. nothing is edited or changed. its just a physical repeater, not even a real bridge (in the datacomm sense)._

 

Very cool! Thanks for updating the thread as well. This is my next project (after the y2 is finished)!


----------



## linuxworks

more updates 
	

	
	
		
		

		
		
	


	














 I'm happy enough with this build 
	

	
	
		
		

		
		
	


	




 I also found a local source of opto-in parts (8mhz, old style, but they work at redbook audio rates just dandy). I may grab some extras in case people want them; when you build switches, you often need lots of parts for ports. lucky that I found some input ports since you need more of those than output ones 
	

	
	
		
		

		
		
	


	




 so, this is the main switch fabric board. you send in 2 or 3 bits of constant 0 or 1 on each of the wires and the binary-numbered input port is connected to the single output.

 you don't really even need a controller. if you are ok with just having 2 switches and using binary to select the 4 states, hey, have fun, the circuit will work fine just the same 
	

	
	
		
		

		
		
	


	




 but for just a bit more work, the lcd and IR front-end can be integrated and that will select the 2 or 3 bit binary address for you, in a nice friendly way.


----------



## linuxworks

more updates 
	

	
	
		
		

		
		
	


	












































 informally, it seems to work. I'll soon begin some scope level testing to see what the waveforms really look like, just out of curiousity. but for practical use, I see no reason to not use something like this. I've been using the previous version for a while, now, and I'll start using this version now that its all boxed up. I don't hear any sonic problems; it just seems to pass the bits thru unharmed.

 I'll have SPDIFmaster at the bay area meet (this saturday) in case anyone local wants to come check it out


----------



## TeraHz

That looks awesome!

 I will use my arduino nano + lcd and try and put everything in a Hammond 1455C80x case (lcd on top, I/O on the sides). Powered by nano's 5V, optical only. I've sourced all parts and will start this weekend. If you don't mind I will post progress here as well, since it is your design.


----------



## linuxworks

sure, if you have questions, just ask.

 btw, if I could get someone to do some eagle library elements for me, I'll put together an eagle schematic of what I have.

 I need elements for these chips:

 ua9637
 ua9638

 both are smd soic8 rs422 diff line drivers. I use them to convert up and down from coax to TTL level. I like these chips due to reasonable cost, small size and they are similar to some designs I've had in real use for over a decade, now.

 my schematic is using older rs422 parts but I'd like to update to these. anyone care to help with the eagle stuff? I'm not really good at eagle library creation, yet..


----------



## TeraHz

Ok, here come the questions.

 I'm using the same LCD as yours, and trying to setup a 4pin communication. I've connected:
 LCD Arduino
 P1(GND) GND
 P2(VDD) 5V+
 P3(V0) <- I don't have a pot to use, so I made a constant pot with two resistors (5v -> 1KR - P3(V0) - 9KR ->GND). That should work for now.
 P4(RS) P11
 P5(RW) GND
 P6(E) P12
 P11(DB4) P7
 P12(DB5) P8
 P13(DB6) P9
 P14(DB7) P10
 P15(A - LED+) 5V+
 P16(K - LED-) GND


 When I plug the arduino in the USB, the backlight powers up, but nothing shows up. I tried both your code (setting the D, RS and E pins) and the LCD4bit examples (again setting the appropriate pins) and I can't get anything to show up on the screen.

 I can't figure out what am I doing wrong! Help!

 Also, while setting up the above, I managed to burn one of my two arduino boards. It looks like the FTDI chip is dead because the OS cannot initialize it anymore and the 5V at the voltage regulator is now 3.3V. The arduino seems to be running the last program I uploaded.So I when I have enough things to order online I'll order a few of these RT232 chips and try and replace it.


----------



## TeraHz

Ok, I put an actual pot and now it seems to be showing the ##########. the LinquidCrystal example still doesn't work, but at least I can now see the LCD is on. Will post an update when I print something


----------



## linuxworks

yes, the contrast pot can be tricky; if you set it wrong, it looks like nothing works at all 
	

	
	
		
		

		
		
	


	




 your pinouts:


 >P1(GND) GND
 >P2(VDD) 5V+

 right.

 >P3(V0) <- I don't have a pot to use, so I made a constant pot with two resistors (5v -> 1KR - P3(V0) - 9KR ->GND). That should work for now.

 ok.


 P4(RS) P11

 P5(RW) GND

 P6(E) P12
 P11(DB4) P7
 P12(DB5) P8
 P13(DB6) P9
 P14(DB7) P10

 just to check, are you sure you got them on the ARDUINO logical pins or the ATMEL physical pins? I sometimes get them wrong and then have to dig out the logi/phy mapping chart.

 also, check which source you are using. I switch pins every so often, so you have to check the source. look for a block like:


 #define LCD_DB4_PIN 2 // hitachi pin 11
 #define LCD_DB5_PIN 3 // hitachi pin 12
 #define LCD_DB6_PIN 4 // hitachi pin 13
 #define LCD_DB7_PIN 5 // hitachi pin 14
 #define LCD_RS_PIN 6 // hitachi pin 4 ('register select')
 #define LCD_ENABLE_PIN 7 // hitachi pin 6 ('E')

 but also, there might be a line like:

 LiquidCrystal lcd(LCD_RS_PIN, 0, LCD_ENABLE_PIN, LCD_DB4_PIN, LCD_DB5_PIN, LCD_DB6_PIN, LCD_DB7_PIN);

 so those would be the definitive pin mappings. gotta check the source. are you using spdifmaster v1 or v2 source? I updated things a bit in v2 but I think v1 was the last public source I posted. 

 >P15(A - LED+) 5V+
 >P16(K - LED-) GND

 I have the backlight wired thru a PWM wire and then sometimes an R in series. I think I tied 16 to gnd like you say and then 15 gets the PWM signal, but that's not needed to make this work.


----------



## TeraHz

I got it to work. I had to wire a real pot to get things to display. Then used the latest LiquidCrystal lib and it is as simple as
 lcd.begin(2, 16);
 lcd.setCursor(0,0);
 lcd.print ("Line 1");
 lcd.setCursor(0,1);
 lcd.print ("Line 2");

 Using the 1.11 source (the only one I found posted) of SPDIFMaster I couldn't get anything to display. 

 Now off to the real i/o part...

 Thanks linuxworks


----------



## linuxworks

maybe the v2 firmware will be better.

Index of /spdif-master/firmware/arduino/v2.x

 you have to grab all the files, place them in the same folder and then load the .pde file into the editor/IDE. I wanted to break the files down into .c files, as well, but have not gotton the arduino env to like that, yet.


----------



## TeraHz

Thanks, I'll take a look, although I will most likely use this occasion and write my own so I can refresh my C... From all that Java at work I'd forgotten about memory/pointers/fixed size arrays... 
	

	
	
		
		

		
		
	


	




BTW how long does it take for you to switch between inputs? I've noticed it takes about 6-7 secs after the binary is sent for any music to start playing. Is that what you get as well? <- I had to setup the pins as OUTPUT

 I will post some pics soon.


----------



## TeraHz

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_I need elements for these chips:

 ua9637
 ua9638_

 

BTW 9638 is available on Eagle's website
ftp://ftp.cadsoft.de/eagle/userfiles...ies/ua9638.lbr


----------



## TeraHz

It works! Here is a short video:
Arduino LCD Remote SPDIF Switch
I also have some pics, but will upload them tomorrow. 
 And a couple of pics:









 TODO:
 cleanup, add two more inputs, cleanup the code and case it!

 Again, thanks a lot linuxworks.


----------



## TeraHz

Here it is, ready to be cased. This slides right into one of the Hammond 1455C80x cases given that you cut the top for the LCD.

 3 spdif in, 1 spdif out, usb, IR, 2x16 lc:

 Top view without LCD:





 Top view with LCD:





 Bottom view:






 Next to my y2:


----------



## linuxworks

nice!

 which IR module are you using? is that one of the TSOP vishays?

 I assume you were able to find out your IR remote codes? 
	

	
	
		
		

		
		
	


	




 I have mine hard-coded in the source and I didn't (yet) give an easy learning method for discovering the IR integer keypress codes. so I assume you worked that out via a printf or something? 
	

	
	
		
		

		
		
	


	




 good job on the build. glad you were able to make good use of my work.


----------



## TeraHz

Wow, you can tell from these pics??? It's a TSOP34838. 

 About the codes, I used one of the reading routines from the "Arduino infrared problems" thread on arduino.cc. I programmed my receiver remote to use Sony protocol for one of the components so the rest was just printing the integers and deciding which keys I want to use 
	

	
	
		
		

		
		
	


	




.

 Your 2.0 firmware doesn't print on the second line of my lcd, so I didn't use it. I did spend a few mins trying to figure out why it is not working properly, but it seemed faster to write one from scratch, and that's what I ended up doing. One part I noticed tho, is that you've defined your own characters/graphics, which is something I will investigate, as I want to make a Cyrillic font and print in my own language 
	

	
	
		
		

		
		
	


	




 Your pics were very helpful, especially for decoding the MC14051BCPG pins. The data sheet was hard for me to understand (my EE knowledge is very limited).

 Thanks!


----------



## linuxworks

the hitachi lcd uses a funny way to address the char positions.

 2 lines are easier and 4 lines use a 'wrap around' method.

 what I found easiest is just to know the start addr and then print from there using an offset up to (start+15).

 #define LCD_CURS_POS_L1_HOME 0x80
 #define LCD_CURS_POS_L2_HOME 0xC0
 #define LCD_CURS_POS_L3_HOME 0x94
 #define LCD_CURS_POS_L4_HOME 0xD4

 those are the 2 key numbers you need. you put the lcd controller in 'cmd' mode and then write the location. then put it in 'data' mode and write the data.


 see this example:


 void 
 LCD_send_string(const char *str, const byte addr)
 {
 // Send string at addr, if addr <> 0, or cursor position if addr == 0
 if (addr != 0) {
 lcd.command(addr);
 }

 byte i = 0;

 while (str_ != 0) {
 lcd.write(str[i++]);
 }
 } 


 you can see it does lcd.command and lcd.write - those are the 2 'modes' that the lcd can be in when you talk to it. that's how you do cursor addressing._


----------



## wackyterbacky

Hello:

 I know this question is not exactly on topic. In post 7 of this current thread:

http://www.head-fi.org/forums/f6/ic-...7/#post5258673

 You show a Turtle Beach Micro with 44.1kHz output via Toslink.

 I have one of these and have always read that it upsamples to 48kHz. I have not tried to test it.

 Does it indeed output 44.1kHz?

 Is it bitperfect?

 Is this a function of some Linux driver or have you tested with a Windows PC.

 Thanks.


----------



## BrianDonegan

Quote:


  Originally Posted by *wackyterbacky* /img/forum/go_quote.gif 
_Hello:

 I know this question is not exactly on topic. In post 7 of this current thread:

http://www.head-fi.org/forums/f6/ic-...7/#post5258673

 You show a Turtle Beach Micro with 44.1kHz output via Toslink.

 I have one of these and have always read that it upsamples to 48kHz. I have not tried to test it.

 Does it indeed output 44.1kHz?

 Is it bitperfect?

 Is this a function of some Linux driver or have you tested with a Windows PC.

 Thanks._

 

To the best of my knowledge, it is simply a PCM2707 feeding a toslink transmitter. You can find your answer in the PCM2707 datasheet. (I don't think it does upsampling.)


----------



## wackyterbacky

Hi Brian:

 I opened up my Turtle Beach and it has a CMedia CM102S+ The datasheet says:

 USB 2.0 Full Speed Compatible and USB IF Certification
 USB audio device class specification v1.0 Compatible
 High performance 16-Bit Stereo, 48 / 44.1 KHz Sampling Rate for Audio Playback
 Embedded X2 Modulation for Higher Audio Quality

 I guess it does do 44.1 so I will try to set up a bit perfect test at some point. I will need coax spdif out and run it into my Juli@ Coax Input.

 Thanks.


----------



## linuxworks

re: turtle beach micro. it does not resample! my frequency display showed that 
	

	
	
		
		

		
			





 yes, it really honestly outputs at 44.1 when you play a redbook audio cd. or an mp3 created from it.

 play a movie (down to stereo) and it shows 48.

 all what you'd want and expect 
	

	
	
		
		

		
		
	


	




 its a good chip (the cmedia chip; always always has been, too!)


----------



## linuxworks

I have an inside shot of that turtle beach card:






 see? cmedia


----------



## linuxworks

Quote:


  Originally Posted by *TeraHz* /img/forum/go_quote.gif 
_Here it is, ready to be cased. This slides right into one of the Hammond 1455C80x cases given that you cut the top for the LCD.
 Next to my y2:



_

 

hey, you have a y2, also. I wrote a small bit of code to also control the features on *that*. you should do that, too. you can turn on/off that anti-clip and also turn on filter a/b/c. I think that's the 2 'features' that are natural to control, on the wolfson, while in hardware mode.

 you need to put some OUTPUT wires in high-z mode or logical 0 or logical 1. to put the wire in high-z mode, you re-config the wire as INPUT. there is also some detail about pullup or pulldown R's based on how you wrote to the port while in OUTPUT mode or INPUT mode. have to check the arduino playground for more details.

 but if you can spare some wires, I think you only need 2, to control those 2 features on the y2. and then you can display what you've done on the lcd and show the input port# (and name) but also any Y2 settings.

 even more custom: if you wanted the y2 to be in 'noClip/filterA' on input 1 and maybe 'clip/filterC' on input 2, you could do that, too! one of the nice things about having control over the source code that is inside your own box


----------



## TeraHz

that's a very interesting idea. I'll definitely look into it.

 BTW here is how the whole thing fits in the case:
















 and now cased and working:






 As you said, once you have an open source controller, there are so many fun things to do. I was thinking of displaying the current song playing from itunes, if anything is playing on the computer, and maybe the temperature outside in the lower right corner fetched from weather.com 
	

	
	
		
		

		
		
	


	




 Anyways, It has been a very fun and educational project!


----------



## linuxworks

Quote:


  Originally Posted by *TeraHz* /img/forum/go_quote.gif 
_
 BTW here is how the whole thing fits in the case:_

 

I see the lcd is not lying parallel to the box surface. how about some double side foam sticky tape between the ard module and the lcd? I would stick one side to the lcd and let the other side float (don't peel the layer off the bottom side). that will give some cushion but not really bond anything too permanent and it might be enough to make things 'level' inside.


----------



## linuxworks

update:

 I've just added HDMI switching to this project! its a sneaky little hack, but it works and works pretty well. costs $15 to get 3 ports (if found on sale) or under $30 at the normal price.

 this is one that I got hold of and was able to 'hack':

Meritline.com - HDMI v1.3 + HDCP 3 Ports Mini Switch, intelligent Auto Switch and 3 pcs of 6 Feet HDMI v1.3 Male to Male Digital A/V Cable, 30 AWG Cable, Category 2 Certified, Support 1080P HD Resolution

 today (16-mar) its on sale with this coupon code: MLCK195119031630AL1 but it often goes on sale.

 the key to this hack is that the HDMI switch has an IR input via a cable. there are 2 ways to interface with this; via an indirect opto method (ir blaster and ir eye); or via an actual optocoupler chip. I've done the first one and it works, and I'll move onto the optocoupler when my chip order comes in.

 this particular HDMI switch uses NEC style IR coding and it was simple to be able to 'sniff' the code and mimic it on the send side. adding one IR led (which, btw, can be taken directly out of the included handheld credit card style remote) and some code to SPDIFmaster, I was able to link spdif ports to hdmi ports.

 the user can define any mapping of (spdif, hdmi), even repeated port numbers. when you select an input, it does a table (data structure) lookup and finds the corresponding spdif and hdmi port numbers to use. if the hdmi port number changed since the last button press, a new IR blast is sent out of the sender-led and this causes the HDMI switch to change to that new input (there's a discrete IR blast for each of the 3 ports, so there's no state that needs to be read or maintained).

 you can locate the hdmi port box behind the cabinet or where ever the hdmi cables can reach. the point is that this box can be remote from the spdif switch box and they're just connected via a single cable. you don't need to uncase the hdmi switch or modify it or even allow for it inside your own chassis. it just acts like a 'pod' that has wires out of it but no user interface. the UI is coming from SPDIFmaster and its lcd display.

 more details later when I have the optocoupler working.


----------



## alec-av

Quote: 





terahz said:


> Here it is, ready to be cased. This slides right into one of the Hammond 1455C80x cases given that you cut the top for the LCD.
> 
> 3 spdif in, 1 spdif out, usb, IR, 2x16 lc:
> 
> ...


 

 Hi TeraHz !!!!
   
  Nice work whis arduino&ir remote.
  [size=medium]You can upload more detail pics, I can't see all connect lines. [/size]
  [size=medium]What value of adjustable resistance and what value of ir ditails?[/size]


----------



## jimmytrk

I'm coming very late to this party... Great work here from all participant's working the DIY selector versions/implementations.
   
  When I originally converted my HT setup over to digital audio (and got rid of a 100 lbs and 100's of feet of analog video and audio cabling) my HT Receiver was not up to the task of taking in more than 2 digital sources.... so, what to do?  Spend 1) $1K-2K on a new receiver, or 2) get a digital audio input selector...
   
  I chose option #2 and got a SPDIF / ADAT  4x1 Digital Audio Switcher doing up to 24/192 - 4 Coax/Toslink input into 1 Coax/toslink output from a Portland, OR company called INDAY  http://www.inday.com/da4x/da4x.htm
   
  Its still my audio switch untility.  Works great, but its becoming very outdated.
   
  I've been over and over Head-Fi, DIY Audio, etc, forums for different DIY DAC builds, cases and controls. 
   
  An automatic (or user selected by IR remote) digital audio selection is a definite implementation/feature that I want in my DIY DAC build - likely replacing my inday unit - or at least, its current function.
   
  But nowadays, the audio selection need is NOT limited to SPDIF (Coax/toslink.)  We've got several DAC kits available that do USB, I2S (I2C? direct DSD from modded SACD players, DSD over HDMI cable from Factory enabled SACD players, and soon to be dsd from PCs (ElecArt - etc,) AES/EBU, etc in 192/24 PCM, now up to 32/384 PCM... and so on.   I currently have 4 spdif sources... with 2+ more hi rate PCM likely in the near future with likely 2 DSD sources and a hi-rate USB coming soon as well.  I need my DAC to handle all of them.  I need it to auto detect/select, or be selectable with an IR mapped to my  "one to rule them all" remote - logitech 880 or similar high end HT theater programmable remote.
   
  Ok - I'm rambling at this point....
   
  So, the punchline is:
   
  Linuxworks, TeraHZ, and other experts - can an HDMI or some other off the shelf or DIY switching unit take ALL COMERS I've identified above and route to the appropriate DAC inputs - SPDIF, Toslink, 32/384 PCM (?? spdif?), I2S, I2C, 2.8 DSD, 5.6 DSD etc. 
   
  How could we do this type of switcher/selector?
   
  I'm open to comments/suggestions, or just outright solutions.
   
  Cheers,
   
  Dave J  (aka JimiTheRottenKid / Jimmytrk)


----------



## jimmytrk

Bump
   
  Anyone have a DIY DAC digital audio input selector setup working to handle multiple SPDIF, DSD, I2S inputs selected manually and from an IR input???
   
  - Dave


----------

