MEASUREMENTS: A look & listen to Roon Bridge - Raspberry Pi 3 Streaming (HiFiBerry DAC+ Pro & USB DAC)

Last time, I talked about Roon and discussed my experience with it using the NUC as the primary installation and playback. No doubt, you are aware that many people will use inexpensive devices like the Raspberry Pi 3 to handle playback distributed around one's home... And no doubt you've also come across much hyping about more expensive, low power devices when for around $100 and a little know-how, you can get it done quickly, easily and sounding great.

First, I just wanted to practically lay out a simple way to install Roon Bridge on the Pi 3 that worked for me and using which I will run a few tests to demonstrate the sonic output. Remember that the network protocol from the Roon "Core" (my Windows computer) to the Roon "Bridge" (Pi 3) is what's called RAAT (Roon Advanced Audio Transport). It's a protocol with a number of benefits as highlighted in the link.

MEASUREMENTS: Roon 1.2 (with Intel NUC 6i5SYH)

NOTE: I know that just a couple weeks ago, version 1.3 of Roon has been released and I'll perhaps look into that a bit later once some of the initial bugs are stamped out and the system matures a little. Clearly 1.3 has a few new interesting features but the basic bit-perfect playback function I trust would be the same which is what I'm aiming at exploring in this article.

Over the last few years, I have already gradually made my way across the different audio ecosystems that most audiophiles find themselves interested in. Starting with the venerable Squeezebox / Logitech Music Server system (eg. Touch, Transporter), to standard Windows PC and Mac OS X playback, to questionable software (like JPLAY and the JPLAY update), to even just as questionable OS tweaks (eg. Fidelizer), to more recently looking at DLNA streaming using low power devices like the Raspberry Pi 3 and ODROID-C2.

For today and the next few weeks (let's see how this goes), let's spend some time on Roon, another computer audio system much lauded in the audiophile press and see if we can make a few measurements and comment on some observations and thoughts...

MUSINGS: Discussion on the MQA filter (and filters in general)... [Update: Including a look at the classic "Apodizing" filter.]

Here's an interesting comment from the post last week...

CBee 7 February 2017 at 04:47

Excellent article but I have one query. On Sound on Sound they say "MQA claim that the total impulse-response duration is reduced to about 50µs (from around 500µs for a standard 24/192 system), and that the leading-edge uncertainty of transients comes down to just 4µs (from roughly 250µs in a 24/192 system)." In that case wouldn't you need an ADC with higher resolution than the RME Fireface 802 in order to see any real differences between the Reference and Hardware MQA decode?

As I said... Dammit CBee! Now you've made me post another blog entry on MQA :-).

COMPARISON: Hardware-Decoded MQA (using Mytek Brooklyn DAC)

As promised in my last blog post about software MQA decoding, I have been wanting to have a peek and listen to hardware decoding. Due to the proprietary nature of the MQA firmware as well as the fact that we don't have access to MQA encoder software, there is only so much we can do to explore the effect on an audio signal. Ideally, encoding a test signal and then decoding would be the best way to explore the effects and limits of how this all works...

I don't have an MQA-capable DAC myself (and honestly owning one is not high on my list of priorities), but a friend does happen to have the Mytek Brooklyn which is fully MQA-native and has the ability to decode all the way to 24/384. Furthermore, he has the use of a professional ADC of fantastic quality - the RME Fireface to make some recordings of the output from the DAC.

Image from Mytek. Obviously very capable DAC!

With the combination of the excellent DAC and ADC, we should be able to examine the output and make some comparisons. The main questions being:

1. Can we show that hardware-decoded MQA is closer to an original signal beyond the 88/96kHz decoding already done in software?

2. Can we compare the hardware decoder with the output from the software decoder? How much difference is there between the two?