AMB Laboratories DIY Audio

[linux-works]

for now, just the photos and some simple explanations; but maybe I'll do a circuit board later if there's interest.

the idea is to leverage the spdif selection that is native to many dacs (such as the gamma1/2 8416 chip) and have that be remote controlled (in this case, by the LCDuino).

some photos, first:











the components are the DAC, itself (stacked board set in the photos) and an interface board that receives i2c 'input select' addresses (0, 1 or 2 for three total inputs) and sends that decoded parallel set of 2 bits over to the 8416 receiver chip via a pair of opto isolators (6pin chips on my perf board). I used what I had on hand but any opto isolator will work, even the slowest stuff you can find (those 6 pin chips are at least 30 years old from my parts bin).

looking at the first photo, to the far right there is a thick cable from the rear to the front. that's a hacked firewire cable from an old motherboard that had a firewire connector (by itself) on a pc tab (pci style slots). its a PITA to wire up your own FW connectors but its not too bad to steal others that already work FW has 2 strong wires for 5v power (per the FW spec) and it has 2 twisted pair groups inside that are ideal for i2c. I've been using FW cables and connectors for this stuff a lot lately and its working out pretty good. the coolest part is that the cable from this box to my controller (the LCDuino system) is a bog standard firewire cable that you may even have lying around at the house. they are being phased out in the pc world but they'll be around for a long time, at least as discounted parts. might as well use a well designed connector and cable standard. I have that large 6 pin connector which follows the amb/linuxworks i2c+power standard (2 pins of +5v, 2 pins of gnd and 1 each of clock and data).

the 3 pin ribbon next to it (purple white and grey) is the 'result' of the 2 bits that is sent to the DAC. this is equivalent to the front panel 3 way switch. however, I did not use usb - I stole that third port and used it for a 2nd opto in! the soldered-on set of 3 wires in the middle of the top green board is the hijack connection (lol) where instead of usb, I feed in a TTL spdif signal that comes directly from a 2nd opto-rx block. I use 5v blocks and so the vcc pin goes to the box's 5v. this is different from amb's toslinks which tend to use 3.3v. be aware of this if you get into hacking stuff like this! toslinks come in 3v and 5v versions. look up the numbers and know what you are doing..

the 3 leds (up front) are part of the perf board (sitting on headers and sockets, so they can be removed. in theory, lol!) and they just show which of the 3 inputs the unit is dialed into. there is no 'lock on' indicator as I didn't really need an extra led. you may want to route the 'lock on' signal to the panel but I decided not to.

one thing of note is that the perf board is powered by 'both ends'; meaning, that the 5v from the lcduino comes in via the firewire and powers the port expander (8574, same as we use for d1/d2 controllers) and half of the led opto chips. the other half of the chip (the transistor part and its pullups) are powered by the s25 in the smallest green board. that also powers the y2 dac and it takes ac input from a rear barrel connector.

so, if there is interest, I can try to make a pcb layout. but this was really more of a proof of concept and a thing I used to test the LCDuino code (in the v1.0 shipping code, there is a mode in the i/o switch called 's-addr' and this is directly used to talk to 'managed dacs' like this). however, I still prefer not to have to hack dacs internally and instead, so the switching via a separate front-end box. that box can talk to any dac since its spdif in and spdif out. if you upgrade your dac later, you won't have to re-embed this switch stuff in again. I think its smarter, long term, to keep the boxes and functions separate. but, just to show it could be done, here is the managed y2 dac with the circuit embedded and the firewire connector there for remote management.

[mikeg88]

Awesome! I think this is such a good idea. If you do a batch of boards, put me down for one.

[linux-works]

btw, I didn't say too much about the allocation of bits, so here's more about that, now.

there's a single port expander (PE) chip and that has 8 bits we can use. since the spdif receiver chip has 4 inputs in hardware mode (what we use; same as stock y1/y2) we only need 2 bits, max, to address 0,1,2,3. that leaves us 6 bits free we can still use. my idea was to repeat what I did for the standalone spdif switch pod; take the 3 inputs that I built and give each a LED for 'admin status' (which port the user selected, via 'administration'). but I also like to be able to turn lights off. so, I made the 3 port status LEDs software addressible as their own objects. that takes 3 more bits away but it also lets me write to the switch part (2 bits) and also write to the 3 leds (3 bits) on their own. just do a logical OR before you write to the PE chip and if I want leds off, I put 000 for that field. if I want one led on, it might be 010. its stealing bits but we did have bits left unused. if we started to get toward 8 then we'd have to give up the idea of sharing the same byte for light-status and actual port-status but for now, when I build 3 or 4 port versions, the bit-stealing is still perfectly valid I can select a port, show its leds, then turn them off a few seconds later. if they were hard-wired, you could not do things like that.

finally, there is the filter a/b/c thing that the wolfson dacs do. I suppose some bits could map to the virtual positions on the switch and you could remotely choose the filter via the lcduino. I have no plans to do that, though. the default filter sounds fine enough to me and its one less thing to have to 'manage'.

[Coughinhk]

How about WM8805 or DIR9001 instead, with a clean mclk input from a tcxo ? I'd get one of those.

Even better would be a multiple isolated i2s input controller

[linux-works]

WM8805 is definitely something I'm looking into. I have not used one, yet, but I have some samples on order.

I don't have any i2s sources and sinks to think about doing a switch for that, but maybe in the future. it sounds like its on the order of complexity of an hdmi switch, at least in terms of hoq critical its trace length and z would be.

a reclocked spdif switch, otoh, sounds like it would work for 99% of the people and if the reclocking (without asrc) works as well as they claim, it could actually improve the signal, not just switch it. I'm all for that, if its really true.

and also if its defeatable, that's good, else I'll have to add my work bypass switch or circuit.

you don't want to double-do it. if you are going into a cirrus spdif receiver like the 8416, you already get a reclocking effect from that chip, alone. its not clear what benefit you get by doing it ahead of time.

similarly, I would want any dac to be able to disable its own local reclocking if the upstream box (like a switch) cannot.

for the current y1/y2, its reclocking is hard wired and built-in and so the proper thing for the switch to do is to NOT touch the waves and pass them exactly as received. otoh, if an older dac that has no reclocking at all in it is the consumer, I would want to engage the reclock in the switch.

[linux-works]

How about WM8805 or DIR9001 instead, with a clean mclk input from a tcxo ? I'd get one of those.

I just got a demo board (ebay stuff) with wm8805 on it. I'm listening to it now using their board and their simple controller. I plan to write some lcduino code and have it control the 8805. at the very least, I'd like to get the sample-rate freq to display on the lcd. it does not appear that you can get 16/20/24 word length (it always receives all 24 and only lets you stomp on the last few, under sw control). you can switch input ports and you can get the port's frequency. that's not too bad for a 'managed' device. via arduino software, I'll let you name the ports, as well. I'm also thinking of providing a bypass function so you can turn off the chip and just be a pure layer-1 repeater. there may be some data streams you don't want this chip to 'receive' (non-pcm, for one!). or maybe you just want to a/b things and hear the effect of this chip.

the 8805 is an affordable chip, so I'm hoping it can be a center 'switch fabric' for my spdif switcher box. it does not need many parts and it looks somewhat simple enough to make.