Setting up a Raspberry Pi2 with RoonBridge Step-by-Step (OSX version)

It works - and the zones can be linked to provide simultaneous playback…but - terrible background interference from analog output that makes it unlistenable

Mine wasn’t unlistenable, but was pretty bad… It was OK for casual use, but…
Ironically I found it more practically useful though, the hifiberry actually has other issues in my setup which make it unusable…

Yeah mine had a heavy static interference which was just too much. Might try hdmi at some stage to see if that’s a better option

You might want to try running the Pi on a battery (a cell phone battery pack charger works well). I found with mine power supply noise caused some issues.

Interesting - will give that a try

I’ve just remembered I actually bought a cheap Ebay LPS a while back to use with it, but never actually tried as it seemed a bit overkill in the kitchen but I’ll experiment with it just to report back if it makes a difference…

Thanks for the reminder!

Keep the experiment going! :slight_smile:

As for volume: the next release of Roon will contain a fix that enables the hardware volume control for your Hifiberry from within Roon Bridge.

As for the buzzing: the Hifiberry should not buzz – not even with the standard power supply. Something must be shorting or looping – have you closed the case yet?

Ok so have changed cables and power supply to battery - great - static has gone. Usb dac and analog work together as a grouped zone…but ( there is always a but) RAAT is truncating 96/24 to 48/16 to both outputs as presumably this is the max for the analog output.

I love my kids having an analog feed but not at the expense of my listening room resolution !!! Mean I know…

So Roon truncates globally for the ‘worst’ source? I would have though it would truncate just the respective endpoints? Or is it because the two outputs reside on the same device?

Paul was speaking about grouping the zones, ie: USB and analog out. A group can only use the best stream the least capable zone can handle. If you don’t group the zones you can send each the best stream that zone can handle.

Yep - still have the option to remain ungrouped and send different streams via each output. I was sorta after cheap multi room but I understand the architecture doesn’t support that and why. It’s been fun playing though !

And the next experiment will be 2 USB Dacs on the same Pi to maintain the resolution

As all USB ports and the network port share the same 480Mbps bus, it may get oversaturated at higher bitrates with two USB DACs. A better option may be to add a DAC HAT to your Pi – it will give you a way cleaner audio signal and support for bitrates up to 192/24.

Don’t let this stop you from experimenting though… :wink:

1 Like

I’m confused…

Say you have (hypothetically) a main hifi supporting all rates, and a Pi zone with a redbook limit, and they are grouped to play together, are we saying that the main hifi will get pulled down to redbook too? Or only if the zones are on the same device?

Good point Rene - perhaps another Pi is calling…

Yes, as I understand it, the main hifi will get pulled down because a group shares the same stream. I haven’t tested this, so stand to be corrected, but can’t see how it could be otherwise.

Yup – when grouping, RAAT will fall back to the lowest common denominator, I guess:

As you can see, you can make things a little better by upgrading your Pi to the NEXT (development) kernel (currently 4.4.6) – this will give you up to 192Khz on the on-board audio (mini jack & HDMI), but the signal will still be truncated to 16-bit.

No need for a new Pi – a HAT DAC (f.e. IQAudio or Hifiberry) will work just fine in conjunction with a USB DAC, as it operates outside the USB/Network bus.

Interesting. I would have thought with RAATs design for highest SQ, it would have been more desirable to send each endpoint a ‘best stream’ within resource constraints - ie send the hifi it’s bit perfect stream and downsample for the other. Processing would be the same more or less, it would just be two different streams sent over network.

Obviously there are hypothetical ways to get around it, but it’s a curious design choice (in my mind)

Sending the streams won’t be the problem, but keeping them in sync is, I guess.

Perhaps @brian can shed a little light here?