Cool. I’ll add it later today. To bad on a quick look it appears to be missing the DSD pin assignment:)
Yeah, I’m wondering if I’ve screwed up and an custom cable might not be able to solve everything. I’m too new to this stuff…
I am building a Roon endpoint with I2S out right now. I am cheating though because there is USB in the mix as the interface between the network/Roon card and the output PCB so it isn’t a ‘pure’ solution. Input is an Atom powered NUC board running ROCK as an endpoint. Output is the AudioByte Hydra Z board. I am waiting for a few bits to arrive and still trying to determine its final configuration but if it works well I may end up with something worth keeping.
What DAC and what source are you trying to use?
The Hydra Z is a pretty good i2s source…good audio clocks, isolation, clean power to the digital board, and selectable output configuration.
@Jesus_Rodriguez 4 posts up (Matrix X-SPDIF 2 and HOLO Spring)
Edit: FYI, the info I have is that the Spring’s DSD channels are reversed with respect to the PS Audio “standard”. If so, it looks like I’m going to have to correct in software.
Sorry I got replies mixed up.
It looks like you could use the “B” setting. No clue what will happened with DSD though.
Yeah, that’s what Jeff Zhu at HOLO Audio said!
The Allo Kali Reclocker will output i2s up to 32bit 384kHz and is probably best paired with an Allo Sparky (better Ethernet implementation than the Pi). It has it’s own power input and the Sparky can also be run from that.
The Kali is designed to fit between the Sparky and a slave DAC. This is the pinout of the i2s 40 pin connector output:
KALI I2S PINOUT:
Si.no Pin Number Signal Name
1 12 BCLK
2 35 LRCLK
3 29 MCLK
4 40 DATA
@joel do you think it would be possible to construct a short 40 pin to HDMI cable that might take this output into the Spring ? I’ve read that the Spring doesn’t reclock an incoming i2s input. Is that the same thing as being a ‘slave Dac’ ?
The supplied PS is 5v/3A so it may be that an LPS-1 can’t be used as it maxes out at 1.1 amp continuous. The Sparky and Kali can be separately powered however, so it may be possible to power the Kali only from an LPS-1, can’t say.
@andybob, i2S over HDMI is not the raw signal. It needs to go via a balanced driver to enable it to be used via HDMI and so requires more than a 40 pin to HDMI cable. Audio-GD make input and output modules that do this so you would need one after the Kali Reclocker which then goes via HDMI to your DAC. I would power the Kali with the LPS-1 if I needed and keep it separate from the Sparky.
This thread on the Volumio forum had some interesting posts and I think this Output module is one of the modules you are referring to. This could be an interesting project. I’ll take it over to Tinkering if I can confirm it’s viable.
It may be that the Allo people can be persuaded to do a Kali with an HDMI output.
It is the same module. How will Roon recognise it as an end point?
I was thinking I’d run DietPi on the Sparky and load Roon Bridge. The Sparky kernel for DietPi has the Piano 2 drivers and firmware built in, which would get music into the Kali. After that I was just kind of hoping the Kali would send the right signal to the Spring, but maybe that’s a forlorn hope. I don’t need Roon to see the Spring, quite happy for it to recognise the Sparky as the endpoint.
The Piano is hardware and if it isn’t there I don’t see how you might engage RoonBridge to see an output. It is the reason I went with my solution where the USB is engaged but hidden away so externally it is Ethernet in and the Hydra Z outputs. Roon sees the Hydra Z and everything works.
Look at this one. Very nice https://www.youtube.com/watch?v=Gb1sv5k5QkM
I love it!
It looks very accomplished but he does comment on its complexity with regards to operation, not least because it can do a number of different things from being an endpoint to being the server at the centre of your setup. I wanted a dumb, simple solution and the combination I have seems to have made that happen for me. Plus it is based around AudioByte know how so clocks, power and functionality are all taken care of.
Not sure if I understand your complexity with regards to operation. I got a Mano shipped; hooked it up the the network;plugged power plug and turned it on. Automatically seen by Roon and done!
Hydra-Z looks pretty much like the Singxer SU-1 by the way. Looks good too.
I preferred a “plug and play” high-end endpoint for Roon and this is what I got.
Well he said as much in the review, it isn’t a cinch to set up, so support is available. Just repeating what was said in the review!
In terms of heritage, the SU1 is essentially a Chinese clone of the Hydra Z which has been around in X, X+ and Z variants since around 2012 I think. I have owned both, and the SU1 was good. In fact this plan was first germinated when I had a SU1 but I had the chance to own the Hydra Z and because I already own the AudioByte Black Dragon I went for my Z plus a ZPM. I have made this Roon only by choosing ROCK as its OS, but it could be made DNLA or Squeeze friendly by loading plain Linux.