Saturday 23 April 2016

SET-UP: Low Power Linux Audio Player (ODROID-C2 & Volumio 2)

As you know from a few weeks back, I got myself one of these little single-board computers (SBC) - the Hardkernel ODROID-C2 - and posted a PREVIEW on it. As described in that article, I had flashed a copy of Volumio 2 "Release Candidate" (0.861RC1) to my SDHC card and have been streaming music to my TEAC UD-501 DAC in the music room for the last while.

Originally, I was going to publish both the contents in this post as well as measurements but it quickly became obvious that this was going to be too unwieldy (plus the day job got very busy)! As such, let me talk about the basics of the setup here today along with a few changes you might want to try if you're streaming from one of these Linux-based network machines. Then later, we'll get to the measurements...

Note that although I'll obviously be specifically addressing the ODROID-C2 I have here, the software is portable and at present, the good folks at Volumio have software images for many low-power computers including: Raspberry Pi, Beaglebone Black, Cubox, ODROID-C1+, etc... Just check their site to see if your machine is supported with a ready-to-use OS/app image. I've been informed that RuneAudio will also have ODROID-C2 support ahead (maybe as early as this weekend), so keep an eye on that one as well!

A reader made a cute post with a cartoon of the difficulty of running Linux last time. Yes, in principle I agree... Linux is clearly not as easy to use as Windows and Mac OS X; and even after the years of refinement in  the GUI with so many variations these days, I doubt that for most people, Linux on the desktop is something they'd be seriously considering beyond hobby purposes. On a side note, I remember reading an article about Linux back in 2000 that suggested that the rate of adoption of Linux was accelerating and this OS would overtake Windows in the desktop within something like a decade! Of course back then we were starting to see Linux invade network servers and the like... No surprise that some would extrapolate into the desktop single-user computing space. Although it never happened for the desktop environment, isn't it interesting to see the Linux kernel invade the mobile/tablet space as Android and the embedded devices market like NAS storage and low-power music servers? I wouldn't be surprised if proportionally, a good number of us have just as many devices running Linux in our day-to-day life as there are Windows / Mac OS devices. As such, I think it's good knowing the basics of UNIX/Linux as a computing skill these days if one were ever stuck without a geek to call on among friends and family.

Okay, on to music streaming and the ODROID-C2. Here's basically how I have it set up...

Windows Server 2012 R2 machine running JRiver 21 ---> gigabit ethernet LAN ---> ODROID-C2 UPnP/DLNA running Volumio ---> TEAC UD-501 DAC ---> Rest of the sound system...

Simple, right?

On the Windows Server side I have JRiver 21 running as a media server for all my music files. It sees the ODROID-Volumio device as a DLNA renderer once the ODROID is up and running on the gigabit network (named "odroid-Volumio" here):

Since JRiver 20, there has been the ability to apply digital processing to the DLNA output for the audio rendering device. In fact, this was my main motivation to upgrade to version 20 back then. With the DSP functionality, one would be able to get the faster server computer to do stuff like run upsampling, apply convolution room correction filters, and output conversion like packaging DSD as DoP then stream it over to whatever renderer you're using without the need for much further processing on the client/DAC end. Of course, ultimately it doesn't hurt to have a reasonably fast low-power machine like the ODROID-C2 in the event that you wanted to run upsampling or other DSP in the future (maybe BruteFir could be incorporated some day?)...

As you can see, I have configured my DLNA server with a few settings to get it the way I want. Under the "... Add or configure DLNA servers ..." tab, I've set the output format to be "PCM 24 Bit", and upsample everything to 192kHz. In the "Advanced" tab, I've turned on "Bitstream DSD" since I will be streaming music out to my TEAC UD-501 which is capable of up to DSD128 via DoP.

One level down into the "Advanced --> ... DSP Studio ..." tab of the DLNA Servers configuration, I've activated the convolution filter with the appropriate setting for room correction as discussed previously using the AudioVero Acourate software.

I've experimented with a few of these DSP effects on the list and it's a bit hit-and-miss which ones work over DLNA. For example, the "Output Format" DSP doesn't work. If you want to upsample, the "Sample rate" setting that I changed above to 192kHz is where you do it. "Room Correction" DSP will work if you want to reverse polarity but will not implement a volume level change.

Although I might be getting ahead of myself a little with some measurements, I just want to prove that the room correction convolution does work (it's audible but I still wanted objective proof :-) - here's the frequency response with it on as played back with the ODROID-Volumio through the TEAC UD-501...

As for ODROID-Volumio settings, you can start using the web-based configuration to get things working once the computer boots up (note that the first time you boot Volumio with the SD card, give it a few minutes to install, format partitions, etc. could take 15-30 minutes depending on flash card speed and size). On your web browser, either go to "volumio.local" or find the IP address ( in my case) of the Volumio computer; you'll see something like this :

That's the "Playback" screen showing what's being streamed currently. Notice that the left panel is telling me I have a 32/192 stream coming in (interesting, since my JRiver was set to 24-bits). Volume control 100% on the right. Press on the gear icon top right and click "Playback Options" to change some settings:

Rather self-explanatory... Output device is my TEAC UD-501. Audio buffer 8MB - more than enough on the gigabit network with a fast server at 192kHz. In fact with a fast network, you probably want even lower latency before playing back so that 10% can be set even lower if you want manually which we'll talk about in a second.

You can also click on that same top right gear icon and change "System" options:

You can change the DLNA player name. There's the version number as well as a info on system updates and resets.

Volumio Bug: Cosmetic issue with the "Player Name" field. It seems the first letter cannot be uppercase! I was hoping to do "ODROID-Volumio".

Although I'm using the server computer running JRiver to process audio for the streaming device, you can actually also point Volumio to mount a network or local drive and access the library:

Above is the setting for my Samba/CIFS share directory containing my DSD albums on the Windows Server 2012 R2 computer. Point it at the NAS IP, select the path in the drive, and plug in the Username/Password as needed. The "ro" option is to keep the drive read-only so nothing is changed. Assuming it's mounted properly, Volumio will scan through it and audio files found can be selected from the bottom left "Browse" tab. One caution about DSD is that Volumio/mpd does not recognize DST-compressed DSD64 natively and will ignore those files. However, JRiver will decode DST and will bitstream them as DoP to the DLNA device with the option selected above.

The Volumio GUI (and RuneAudio) is actually controlling the underlying Music Player Daemon (MPD) playback system where there are more settings to play with. To access that and edit the configuration files manually, we'll need to run a SSH session to access the Linux command line of the ODROID (or Raspberry Pi, etc...). In Windows grab PuTTY and run it pointed at the machine's IP:

From here, you'll see your Volumio computer command line (remember that the default ID and PASS are both "volumio" by default).
Go to the /etc directory:
cd /etc
And now, let's edit the mpd.conf file to add a couple of things using the nano text editor which is installed by default...
nano mpd.conf
The most interesting parts are in the "Audio Output" block. The default will likely look slightly different for your setup but here's what I changed mine to:

As you see, I've annotated the changes... To allow my UD-501 to stream DSD/DoP (DSD64 and DSD128 works fine from JRiver), add the "use_mmap" (use memory mapping, needed for some DACs) and "dsd_usb" settings. Some DACs (like those using XMOS chipset) can play back DSD natively and will require activation of the dsd_native setting (see here for some details).

Notice I commented out the format line (with '#'), but if I wanted the ODROID to force upsampling to 384kHz, I could (384000Hz:32-bits:stereo). Note that doing this would prevent DSD streaming because the software is not able to convert DSD to PCM and this PCM setting takes precedence over DSD.

Related to the upsampling function, we can tell MPD what samplerate converter algorithm to use. I see that both SoX and Secret Rabbit Code (libsamplerate) settings are included in this build (see here for some details)...

SoX settings: soxr very high, soxr high, soxr medium, soxr low, soxr quick

libsamplerate settings: Best Sinc Interpolator, Medium Sinc Interpolator,
Fastest Sinc Interpolator, ZOH Interpolator, Linear Interpolator

(ZOH = Zero Order Hold - like a non-oversampling DAC, Linear = think Windows 10 DirectSound)

Finally, you can do funky stuff with the buffering. I have it set to 32MB buffer size with playback starting when 5% full in this example. Remember that the ODROID-C2 has 2GB RAM so plenty of memory space. Also, with gigabit ethernet speeds, at full speed the data transfer proceeds at 100MB/s so the slowest step in this whole process is likely the processing speed of the Windows Server performing complex DSP in 192kHz. If streaming wirelessly or through a less reliable network, you might want the buffer to fill a bit more like 20% before playing just to have the extra headroom; the price is a slightly longer playback latency. (For comparison, remember that the Squeezebox devices before the Touch only had ~25Mbits of buffering or ~3MB and the Transporter could handle 24/96 audio quite well with this buffer size on its 100Mbps ethernet.)

Once you've made the changes to the configuration file, CTRL-O to write the changes, and CTRL-X to exit nano. Now reset MPD to activate changes (without a full reboot):
service mpd restart
Remember that these manual changes will be rewritten if you use the Volumio web-based GUI to change "Playback Options" so you might want to back-up the mpd.conf file with changes you like.

With the above settings, I can stream DSD (here's DoP DSD128 or 5.6MHz as displayed):

JRiver (21.0.50) BUG? It seems there's something odd with DSD64+DST compressed .dff files. The decompression seems fine and JRiver 21 will stream them as DoP to Volumio, but the music truncates after about 1-2 minutes and it proceeds to the next track. I'm suspicious that this is a JRiver bug because non-DST-compressed .dff files play fine all the way to the end through Volumio. I wonder if other JRiver + DLNA DoP streaming users could double check on this... Since there's no current compression system other than DST for DSD64 in use that I'm aware of, and only the .dff file format can accommodate this but cannot be tagged, I generally just play PCM files so this bug/issue doesn't affect me too much though should be fixed!

If I uncomment the 32/384 upsampling setting (in the "audio_output" block above), I'll be taking in the 192kHz audio from JRiver and the ODROID will further upsample that to 384kHz to feed to the DAC:
Clearly, Mariah Carey deserves extreme upsampling :-).
Normally the TEAC DAC's OLED screen will display what upsampling antialiasing filter it's using (like "Sharp" or "Slow" correlating to the TI/BB PCM1795 DAC setting). As you can see in the picture above, when the ODROID is upsampling all the way to PCM 384kHz, it turns off the digital antialiasing filter completely. Some audiophiles might feel that this makes an audible difference (I don't believe it does).

The ODROID's 2GHz quad-core 64-bit processors are easily able to handle the 192 --> 384kHz upsampling using "soxr very high" setting which is the most processor-intensive option:

As you can see, mpd is using up ~12% processor load. I've seen it go up to around 14% when upsampling from 44 --> 384kHz using this SoX setting.

Here's another interesting processor load figure:

~4% load from a quad-Cortex A53 2GHz ARM CPU is all it takes to convert a DSD128 .dsf file from a gigabit ethernet mounted NAS drive, repackage into DoP and played on the USB 2.0 DAC (3% mpd + 0.7% cifs). This is with a Volumio-mounted DSD directory off my server so it's not going through JRiver at all. I've heard talk by some audiophiles fretting over whether DoP changes the sound quality of DSD playback! Evidently it's no big deal from a processing power perspective (I would not have expected it otherwise).

It has been about a month since I have had the ODROID up and running. It's on 24/7, the beta/RC1 version of Volumio 2 has been very stable so far. Other than the issue with DST compressed DSD64 files truncating on playback (JRiver problem?), and the small cosmetic player name issue, I haven't run into any other concerns. I use eos as the JRiver controller app with my Nexus 7 Android tablet and just as well can use the free Gizmo app.

I hope this post gets you interested in the potential of free Linux software paired with these very inexpensive single-board computers. And a taste of the customization potential and options available with just a little time and effort. Indeed, at some point, my Squeezebox devices will fail and I would have no concerns at all running something like this as replacement. Already I'm quite impressed by the stability and it sounds fantastic. As promised, I will be running some measurements as well with this little streaming computer connected to my DAC via USB, so stay tuned for that in the next couple weeks!


Let's end off with a discussion in general on music streamers. You've seen them around. Like many audiophile products, over time, as companies start moving into "high-end" gear, prices often escalate easily to the 4-figures for what in my opinion are just small ARM-based computers like the ODROID-C2. Looking around at the specs, typically the streaming devices have even less processing power, memory, and video capabilities than this little hobbyist computer. What is often advertised are claims that linear power supplies, low jitter "femtoclocks", special shielded enclosures are beneficial for audio quality... Sure, while these features might sound great and may be congruent with audiophile "lore", it's generally unclear under what circumstances and to what degree any of it would be audible at all. Remember, we're looking for accurate digital data transmission with minimal timing anomaly in the playback. Essentially any reasonable computer with a functioning cable is capable of accurate data transmission. And timing anomaly that could result in jitter is dealt with by asynchronous interface (USB/ethernet/Firewire) DACs, not typically a function of the computer/streaming hardware unless you're still using the older S/PDIF interfaces these days. As for noise originating from the computer/streaming hardware, I'd like to see evidence of this "problem" with modern equipment. Any streamer that creates enough electrical noise to cause distortion in a reputable DAC or any DAC that is so susceptible as to "sound" noisy with a reputable computer/streaming device should be avoided!

Beyond the hardware side, also remember that many of these commercial streaming devices (I believe various Auralic and Aurender models) are using some variant of Music Player Daemon (mpd); the same underlying Linux infrastructure as Volumio and RuneAudio among others. Unless there are special features one wants/needs from the hardware (eg. a specific digital output like an AES/EBU interface), or other non-utilitarian features, I would certainly highly recommend looking around at these SBC's like the Raspberry Pi or ODROID, and audio add-ons if needed (like the HiFiBerry DIGI+, DAC+, or HiFi Shield). Simply assemble your own. The remarkable thing is that this would only likely set you back ~$100 when all is said and done!

Folks, these are truly exciting times for the computer high-fidelity hobbyist. Take advantage of technological progress pushing down prices of all kinds of amazing hardware and the power of already quite mature and feature-filled "free" software (donations of course always appreciated).

Until next time... Hope you're all enjoying the music!

Addendum: I see that Blogger took down my April 1st post on "USB Audio Gremlins" and the FUD they're perpetuating referring to my take on the iFi sponsored post on AudioStream yet again despite changes I made to not directly quote much from the ridiculous article... Fine. You can still find it cached for the time being.

Addendum 2: I see that Archphile also has an image up for the ODROID-C2 for those wanting a try.


  1. Welcome to the world of linux-based music players :) My first ones were the and back something like 17 years ago (if you don't count my software-only stuff on Sun workstations and linux PC's way before that).

    - Julf

    1. Thanks for the note Julf.

      Cool, didn't know about the Rio Receiver and Empeg! I think if I look at the definition of "early adopter" in the dictionary, your picture would be in there.

      Thanks for funding the early ventures and development of the tech in any event :-).

  2. Hey Archimago, thanks for going through the layout of this setup in detail! Looking forward to the measurements. The ODROID has definiteley piqued my interest. I've been following your blog for quite a while now and it's become something I always refer to before investing in new gear. A couple of areas where I'd love to see some actual measurements (I realize, of course, that these might not be of interest to you,so consider these suggestions only): Passive line level attenuators - like the Rothwell attenuators - I've yet to see anything factual on their actual performance.
    Also, I've gone through a number of Android music players (for my phone), and I find that they differ a lot in terms of overall sound quality/characteristics. I've currently settled for the USB Audio Player Pro, after having tried out Neutron, Jet Audio, PowerAmp... Would love to see some measurements for some of these. Again, thanks for providing some sobriety among all the crazy, it has saved me more money (and time) than I care to think about.
    Jens the Swede

    1. Hi Jens.

      Thanks for the note! Hope things are well in Sweden :-). I was in Stockholm a few years back and spent a couple days there - lovely city and beautiful part of the world.

      I didn't know anything about the attenuators until I Googled it just now:

      They look like attractive line level attenuators. At best hopefully they won't affect the noise level and dynamic range and allow a "hot" signal to sit at a more optimal level for presentation to the pre-amp and amps. Can't say I've tried these "audiophile" RCA versions but passive attenuators are common in the pro audio world to dampen XLR microphone overloads.

      Interesting question about the Android music players. Yes, USB Audio Player Pro is what I use as well. Will put that on the list of items to investigate :-).

  3. What are you thoughts on UPnP/DLNA being a "not so great" transport for music? Being UDP in nature - corrupted/missing packets are not re-transmitted. Personally I stick with using good old SMB pointing to an SMB share on a NAS. It uses TCP and in theory - a more reliable protocol, especially if one is using WiFi.

    Totally agree about it being exciting times. The ubiquity and low cost of SBC's is already revolutionizing music playback systems. I've had oustanding success in using SBC's (Raspberry Pi's in particular) as music players. I don't find the shared bus an issue. It has plenty of grunt for critical music (and video) duties. With the likes of devices such as the Google Chromecast I believe it will render most (existing) playback devices obsolete - probably even the SBC's!

    $3000 audiophile music "servers"? Pffft.

    1. Hey Qmax.

      Heck, in my mind a $1000 audiophile music servers seem out of touch from a price-performance basis. $3000 IMO is insane for this purpose. This kind of price range *demands* more features that just claims of good sound!

      You're right, UDP by nature is about sending packets of a more time-sensitive nature like streaming media. There is an optional checksum to detect errors but since it's unidirectional, packets are dropped rather than asked to be resent.

      Whether the transport mechanism is "great" or not then rests with whether one's home network is reliable or not and whether many UDP packets are dropped.

      Tell ya what... Let me put up another blog post next week using my home network to try to answer that question with the ODROID machine :-).

    2. DLNA can use TCP (HTTP) or UDP (RTP). What ends up being used depends on the combination of server and renderer.

    3. Thanks Mans. I've been looking at the ODROID-Volumio to JRiver combo here and I'm seeing use of TCP port 52100 rather than UDP for DLNA transfers.

    4. I look forward to your findings Archimago....I see lots of words dedicated to writing about ethernet cables from the audiophile press, but never about the underlying choice / implementation of network transport protocols. How much they can make a difference depends on the quality of the underlying network. Wired networks typically see much less transmission errors than wireless. Wireless is not as reliable as some may think, and might be surprised by the "behind the scenes" errors, retransmissions etc. TCP can ask for the packet(s) again, and depending on the audio player in question - can build up enough buffer meaning the player has provide "perfect" data in even the most errors prone networks.

      I have not had much to do with DLNA/UPnP in the past as SMB (a TCP protocol) has been so rock solid for me I've not had any incentive to look for other playback options - I play most of my audio/video from SMB NAS shares and have done so since the early days of computer/network playback systems. Coupled with players that offer bit perfect and buffering -> I believe I'm in a good place.

  4. Why is this better than having the R2 machine running jriver straight into the TEAC? (I'm ignorant). Grant

    1. Hi tnargs,
      Because I don't want my server machine with a number of fans, multiple terabyte drives in the same room as my sound system :-).

      I can actually run JRiver on my fanless HTPC in the sound room as well and that would be fine, but hey, it's a hobby and it's fun exploring options :-).

      (Fanless HTPC already in the room mainly used for video playback:

  5. Hello. I spent couple of hours on reading your blog. Thank you for your work and honesty in audio. It is important this days...

    Regarding low power linux audio: for the last years I'm using Raspberry Pi with moOde ( and Jriver with great results. I can confirm all your findings. It is great and cheep solution. I have difficulties to believe that top shelf audio product's can make it better (from audio quality point of view).
    I'm looking forward for your measurements of odroid. It would be great to see diagrams similar to the one available in "Computer USB port noise, USB hubs and the 8kHz PHY Microframe Packet Noise" article.
    I'm thinking on adding 5V 2A LPS to my Raspberry pi and would like to take that decision based on your findings. I have modern asynchronous USB DAC with galvanic isolation (LKS MH-D003 which I strongly recommend) but this raspberry wall wart is ringing in the back of my brain.
    Best regards from Poland.

    1. Greetings Tri in Poland!
      Thanks for the note. Yes, I will put together some measurements including a look at the 8kHz PHY packet tone that gets picked up by my pre-amp with the analogue input in a hookup similar to the HTPC.

      I know the psychological link and perhaps "learning" is there over the years of forum posts and general sentiment among people in the audiophile world that "top shelf audio products" can *always* in some way make it sound better. But I see many of these beliefs like "tradition". They might apply to some circumstances and may have some element of truth at some point in history. But it doesn't mean they apply now to say "digital audio" and it doesn't mean that "computer audio" doesn't have its share of truths which are different from convention... As technology changes, so too does the concept of what matters and what doesn't.

      In my mind, there's nothing wrong with "traditions" like say the replacement of SMPS with a linear supply of course. Surely at some point some switching power supplies were problematic. But specifically would an inexpensive modern wallwart providing 5V power to the ODROID cause an audible degradation in my system? That is one I have to find evidence for because I'm certainly not overtly hearing a problem, but I am open to the idea that subthreshold noise could be there...

      We shall see...

    2. That's very good news.
      I will wait for measurements. I already promised myself that I will forget about LPS if your measurements wont show any significant difference...
      Audiophilia is difficult to fight with. There is always "better" behind the corner. Measurements and calm decisions help to fight with this disease. I'm going back to music not gear.

      Yes we are living in interesting times with audio equipment capable of high fidelity at reasonable price.
      Future will judge who was right about influence of digital cables and "noisy" equipment. Maybe they will develop measuring equipment to proof all the statements from web pages and leaflets.

      We shall see...

      (Sorry for my English)

    3. Hey Tri... Your English is awesome! Infinitely better than my Polish :-).

      Yes, the future will show who's right!

  6. Arch,
    I employ a Broadwell NUC w 8GB RAM and JR21 and Dirac Live. This is connected by 100 MB ethernet to a Synology NAS. Signal path is then NUC to Oppo 105D by HDMI. Would this be comparable to your demo above?
    Thanks, great job.

    1. Hi Sk16. That would be a much more powerful setup! It's more akin to my HTPC with Skylake processor that I built in this room for home-theater multichannel purposes (Dec 2015) feeding my Onkyo HDMI receiver.

      Remember, this little computer is basically being run as a headless machine for ethernet streaming, output as USB to the DAC. Much less CPU processing than your Broadwell NUC. And the Acourate convolution being done about 100' away in the server computer rather than in the same machine like your NUC and Dirac.

      Ultimately, the sound quality should be very similar! Yours sounding like the Oppo 105D. And mine sounding like the TEAC UD-501.

      BTW: Is the NUC essentially silent (ie. fan noise)? That's about the only thing I'm most concerned about - fans and noise from storage drives. Not all this talk about electrical noise which I have rarely seen as a significant issue...

    2. Yessir,silent at least to me from 10 ft. The Panasonic ZT65 fans make a whisper noise unfortunately. Speaking of electrical noise, I have the NUC plugged into an LPS, along with an ethernet switch and the Modwright PS for the Oppo. Have you ever done a study on the efficacy of LPSs?
      Great weekend,

    3. Hey SK.

      Many years ago I did try to measure noise levels between a linear supply and the standard wallwart to see if this made a difference with the Squeezebox Touch thinking that the analogue output would be affected.

      Nope. Didn't find a difference. Unfortunately this was in the early days of the blog and before I got measurements recorded so didn't post anything on this. Plus I borrowed the LPS so returned it... It's a good idea though to have another look.

    4. Hardly surprising, the Touch does all its power regulation on board, the power supply is just that. There's a useful thread on the Squeezebox community forum, just search 'Touch power supply'.

  7. Hey Archimago!
    Thanks for taking the time to keep alive this blog with your experiences,
    I find it very smart and helpful. I have a setup similar to yours:
    Raspberry Pi2 linked by ethernet to a gigabit LAN; a NAS/Server machine
    with Ubuntu Server and large storage space (with music shared with samba
    and also with DLNA), in another room :) ; a TEAC UD-501 Dac connected with USB to the RPi2; analog output to pre+amplifier; smartphone as controller.
    I played with Volumio (1.55 stable) as well as Runeaudio, both excellent pieces of software.
    Now I just put an order for an Odroid C2, attracted by its power,
    more ram and above all its gigabit ethernet/different usb implementation
    (and of course your blog!). I have to admit it:
    I never had a problem with RPi2 about dropping/stuttering, also with
    24/192 and DSD. Sometimes some "pop" and "click" changing the song
    in the middle.
    What do you think about the potential differences (sound quality wise) between Rpi2 and Odroid C2? Considering the gigabit ethernet and the different USB implementation (different hub from the ethernet one).
    I completely agree with every word you write concerning the general discussion on music streamers.

    Thanks, keep it up!

    1. Thanks for the note Michele!
      Looks like you've got quite the experience already :-). I am looking forward to the supposedly imminent arrival of RuneAudio to see how things are run differently.

      I honestly do not anticipate that there will be a difference in sound between the RPi2 and Odroid-C2 simply because the processing needs of audio is relatively low for just streaming purposes. That said, the significantly faster gigabit ethernet is nice and the extra processing power might one day make this a nice 4K media server if pressed for HDMI service!

      I see on Computer Audiophile a "review" for the Sonore microRendu. Written well but with the usual audiophile flare and name dropping for basically a much less powerful device asking for >$600 without powersupply. Dual core i.MX6, likely the Cortex A9 processor cores. Limited gigabit ethernet speed (I can tell you that the ODRIOD-C2 can manage >600Mbps real-life sustained). Limited with single USB port and no video output nor option for daughterboard DAC or other digital output. With even mysterious redacted lines to boot :-).

      Supposedly everything to placate the god of "noise" (like the REGEN before it) so as not to intrude on the audiophile experience...

      Maybe better software support with Roon? Worth the price?

      Staggering! And as usual... No measurements on how they prove audibility claims. As as far as I know, measurements for the REGEN never got released either despite statements they were "working on it".

    2. BTW: I seriously hope Chris will include discussion on the SBC computers like the Pi and Odroids in his "Part 2" to that "review" considering how commonly available and easily accessible (and much more powerful!) the alternatives are...

      Otherwise, as far as I'm concerned, these kinds of "reviews" are nothing more than "infomercials" clearly not meant to educate the audiophile public nor advocate for value to the consumer.

  8. I have tried quite a few Linux based players and all of them seem to sound very thin, small soundstange..etc.
    As yourself, I am a big fan of Jriver and my current stereo setup uses Meegopad T03 PRO stick mini-PC. A full fledged Windows 10 OS running Jriver and connected via wifi to my NAS and via USB to my async DAC.
    I have to say that I am getting better sound from this setup than from my previous setup that had a $1500 PC connected to the

    1. Thanks for the note Basil.

      Interesting little stick computer. I see another one out there might be Intel Compute Stick and Lenovo 300.
      Interesting summary article:

      Hmmm, I'm not noticing any "thin"ness in the sound though. Flipping between this Linux computer with the TEAC DAC and my Logitech Transporter without digital room filters sounds essentially identical when I equalize the volume output!

      A spectral timbral change like loss of mids or bass to create a "thin" sound would be easily measured and demonstrated. You should give it a go and see if this is found! I'd love to see the results...