Raspberry Pi vs CuboX-i

Hi guys,

Nice product, nice forum!
I’m pretty new into this world of mini-pc’s, DACs etc, but playing CD’s seems to be old fashioned nowadays :wink:

I’m looking for the following:
A mediaplayer with XBMC and a high quality audio solution for playing my music through my NAD-HiFi set (which only has analogue inputs)

I did some research and I’m thinking of using Volumio with the following setup:

Synology NAS (with disks)
Raspberry Pi with HifiBerry (digital edition)
Bushmaster MKII DAC

However, the Cubox-i (v2 or v4pro) seems to be a nice alternative for the Raspberry Pi, because it already has a SP-DIF out which I can connect to the DAC. Seems to be less hassle!

In terms of audio quality, would you guys suggest to buy this setup with the Cubox-i or with the Raspberry Pi (with HiFi Berry)?

If you want SPDIF out you could consider the Wolfson audio card. I’m using one at the moment (specifically with SPDIF out). Sound quality is very good. No soldering required, and there is a case for it (I just got a case today!).

However, the Wolfson card is not currently supported in Volumio. Michelangelo said he was going to get one of the cards this week, so it should be supported soon. I’m using a custom kernel for it at the moment (not a Volumio kernel) with the Volumio Web-GUI. I think the Wolfson card may only work with the Raspberry Pi though.

That sounds like a great option as well!
Hope there will be Volumio-support for the Wolfson audio-card soon, that looks like a good (and easier) alternative for the HiFi Berry.

There’s a comparison of the relative merits of the HifiBerry and the Wolfson cards by a guy in the Element14 forums element14.com/community/mess … ate#109592

Seems that Wolfson is the way to go for Raspberry Pi’s, but full range implementation is still pending…

I’m also still curious what users of the Cubox-i think of the audio-functionality and quality.

Certainly the software support is a must.

Check out the other i2s DACs available for the Pi, there’s a sticky post here IIRC and the feedback other users are giving over at hifiwigwam.com/forum.php


Did you see this thread?


Now I did :slight_smile:


Have raspi and cuboxi-4pro. The Cuboxi-4pro sounds much better, cleaner. Functions better, more efficient, in my experience My Raspi and CuboxI are both using the same USB CM6631A. I have not used any raspi attachments. The current BETA 1.2 has issues, but easily resolvable. The CuboxI is a lot more money, but I think worth it. I will be re-provisioning my Raspi to other duties.

A good friend has given me his cubox to do my tests. My current device is a raspberry pi.

I did some tests using both volumio and custom a archLinux distribution.

My first impression was that cubox sounds warmer and deeper.
I decided to do some further a to b tests for many hours.

My final preference after the end of the test was the Rpi. The cubox sounds indeed warmer which for me was a wow factor in the beginning, but listening to various hi quality flacs I am very familiar with, I believe that the Rpi has a more natural and uncoloured sound.
This is my not my final impression. I will continue my tests for the next days because I am still interested in buying a second device.

@Michelangelo, which of all your supported devices is your daily driver?

Sent from my GT-N7100 using Tapatalk

You should give one of the Raspberry Pi I2S DACs a go. I reckon the issues with the Pi’s USB implementation might be the cause of any audible differences.

Latest raspberry pi firmware fixes most of the problems with usb dacs:


I have been using this since day one and I have zero problems. Most of you who have experienced issues with your USB dacs you should definately give it a try! I don’t know if there’s any effect in sound quality. In my A/B test the rpi was with the mentioned firmware.

As we speak i keep A/B testing these two devices and I insist that in my case the rpi is the winner.


Thank you. My CM6631a supports a I2S interface. I might implement it on the Raspi, just to check it out. I found the CuboxI transparent, on my rig. I ABX it with my A&K100 via it’s Toslink to a Corda Stage DAC. The two were very similar, I would have to spend a whole lot of time, ABXing it to determine the differences. I have another DAC that is DSD comparable, and don’t think the Raspi can handle that, but it will be fun to try. When I get some time, I will build out a I2S interface for the Raspi.

I tested the rpi with DSD with a friends dac and it failed, so if you need these types of files rpi is not the device you need for sure!

Before concluding too quickly about the differences between rip and cubox, I would assume that the dac will be a determining factor. Can you indicate how you dealt with that - did you use the same dac in the two settings?

I did the following tests:

  • Rpi with custom Archlinux (with latest firmware including the FSM driver and usbhid unbound) vs cubox-i4 with Volumio
  • Rpi with custom Archlinux (with latest firmware including the FSM driver and usbhid unbound) vs cubox-i4 with custom Archlinux

The rest of the rig was exactly the same. The dac of the test is:

hifimediy.com/index.php?route=pr … duct_id=87 (i have both dacs, adaptive and async - in this test i used the async)

I am not here to say that cubox is bad. I heard a difference in sound and I prefer the sound of Raspberry Pi in both tests with my current rig.

P.s. I totally agree that the conclusion was very quick, although my tests lasted for about 2 hours, but the device it not mine and unfortunately I cannot spend much time on it.

I’m using a CM6631A USB digital to SPDIF digital converter, connected to a Corda Stage DAC. with both CuboxI and Raspi. I do not have the luxury of doing an AB switch and can only do long term listening on both. I have to move the USB between the two ARM appliances. This process isn’t as good as an ABx and very subjective to many variables, but currently my only option. Please take this in account, when I voiced my last opinion.

Bearington, the opinion I expressed above is just the first feeling I got from this device.

As an upgrade from Rpi I decided to buy udoo quad which has if I remember correctly a cpu of the same family. When it comes I will use it as my daily driver and I will come back after many hours of listening, something I wasn’t able to do with the cubox because I don’t have it anymore.

Sent from my GT-N7100 using Tapatalk

My cubox-i runs rocksolid, consequently running since days.
It sounds, according to my personal perception, better than the RasPi when connected to the same DAC.
Since today it supports as well squeezelite.
The Form factor is better than the Raspberry board.
It gives more a “product” impression.
So its clear for me.
Cubox-i has won.

I had to apply the following fixes to make it run with volumio, wifi and squeezelite

  1. Implement wifi (Thanks Istein !)

  2. Reactivate DAC (Thanks Bearington !)

  3. Implement Squeezelite (Thanks Michael birch)
    regbirch.com/blog/logitech-m … rver-cubox

Some work to do, but the result is great !

An update on what I am doing with the Cubox-i4pro
I was thinking about how streaming works with audio. How CPU’s cache functions and decided to make some Affinity adjustments, as to pin mpd process, to CPU 2 and 3, and then isolated CPU 2 and 3 from the kernel and all other processes. My reasoning is to establish a more local and fixed cache for the CPUs, dedicating just to audio streaming. Also freeing up MPD from sharing CPU resources with IRQs.
I edited uEnv.txt and /etc/init.d/mpd to implement Affinity changes.

Then I decided to tune some resources for my NAS, USB and network. Here are my files changes. If anyone is interested, with these changes. They could probably use a whole lot of adjustments, feedback on that would be kind. This is Just for fun, trying to get the most out of the quad cores.

Make sure you make a backup of your SD card, before you do any of this, to insure you can go back to the original. I am just sharing with you, somethings I am playing with.

vi/boot/uEnv.txt # last command isolates CPU 2 and 3

mmcroot=/dev/mmcblk0p2 rootwait rw console=ttymxc0,115200 consoleblank=0 raid=no
autodetect cgroup_disable=memory isolcpus=2,3

changed the /etc/init.d/mpd last lines to pin the CPUs when mpd is started and restarted


case “$1” in
BJI=$(cat /run/mpd/pid)
taskset -cp 2-3 $BJI
status_of_proc -p $PIDFILE $DAEMON $NAME
BJI=$(cat /run/mpd/pid)
taskset -cp 2-3 $BJI
BJI=$(cat /run/mpd/pid)
taskset -cp 2-3 $BJI[/code]

vi /etc/security/limits.conf add to the bottom to adjust limits

@audio - rtprio 99 @audio - memlock unlimited @audio - nice -19

vi /etc/sysctl.conf add following to tweak LAN buffers

net.core.rmem_max=12582912 net.core.wmem_max=12582912 net.ipv4.tcp_rmem= 10240 87380 12582912 net.ipv4.tcp_wmem= 10240 87380 12582912 net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_no_metrics_save = 1 net.core.netdev_max_backlog = 5000 vm.overcommit_memory = 2 vm.overcommit_ratio = 50

vi /etc/init.d/rtset.conf created not sure about this, but it is to tune realtime streaming.

#!/bin/sh chrt -f -p 53 `pgrep irq/24-ehci_hcd` chrt -f -p 53 `pgrep irq/29-eth0` chrt -f -p 53 `pgrep cifsd`

Anyway, just playing, looks like these changes made a difference, no so much in sound, but in resource management.
Play with at your own risk!!