Reviving the HiFiPi


I know this hasn’t been posted for awhile, but I’ve been keeping a close eye on how well the domain-server and assignment-client run on a humble Raspberry Pi. With the recent updates that have been going on, there are some things that work great and others not so much. The fact it even works at 90% functionality is pretty much a massive accomplishment in my book.

What works:

  • Avatar positioning works fine
  • Audio handling appears to work fine
  • Domain-server control panel is 99% functional (see below)
  • Assignment-clients run without any massive errors

What doesn’t work:

  • Creating objects doesn’t sync with the server
  • But letting entities be made from the marketplace seems to work fine
  • This results in “EntityItem::deserializeActionsInternal – no _element”
  • Setting up default viewpoints for paths seems to not fully work.

Changes that had to be done:

  • AVX & AVX2 optimization had to be removed (not available for ARM processors)
  • Had to include an additional header to AudioLimiter.h
  • #include “stddef.h” just before #include “stdint.h”

Aside from being built on a Raspberry Pi and needing to change a few lines of code, High Fidelity’s server code runs very well and compiles just like any other Linux build, so much so that I used the same notes I have made for building the Pi version to build the version on one of my actual servers (except for changes to any code due to differences in architecture).

While I do plan to make a full from start to finish guide for building High Fidelity on a fresh Ubuntu installation (16.04 and 14.04), honestly the biggest hurdle is just getting QT 5.6.1 (And I just realized I have been fiddling around with 5.6.0. Woops).

Effectively, you just need to (and this is by no means a full guide):

  1. Flash a micro-SD card with Ubuntu 14.04 or 16.04 from here. (Do note that 14.04 is not available for the Raspberry Pi 3. I don’t have one yet so when I do go ahead and order one, I can provide any notable differences between 14.04’s setup and 16.04)
  2. Setup the OS as needed (enable SSH, setup accounts, expand storage space, etc).
  3. Get Qt 5.6.1 onto the Pi (Build it for 4 hours or find a pre-compiled package from someone else).
  4. Clone the stable build of Hifi from GIthub.
  5. Modify SetupHifiLibrary.cmake under cmake/macros and comment out the lines that add AVX/mavx and AVX2/mavx2/mfma optimizations (as of this writing, lines 22, 24, 32, and 34).
  6. Modify AudioLimiter.h under libraries/audio/src to include #include “stddef.h” just before #include “stdint.h”. (This is the only part of the build process that leaves me confused, since without the inclusion of stddef.h, it will fail due to some undefined error. This was resolved by including that header. I’ll report more on this once I rebuild it without this step to include the log of failure)
  7. Create the build folder and run cmake … (depending on how Qt was set up, you may run into instances of where Qt’s location was not added to paths and some errors will occur. How this is solved is dependent on how Qt was set up).
  8. Make the domain-server and assignment-client.
  9. ???
  10. Profit!

While I doubt the Pi can be used as a full server (10+ people), it is rather interesting that a ~10W computer can host an entire domain without too much of an issue (aside from the aforementioned issue with building). I’ll add a post with a full build guide after I get my new Raspberry Pi 3 (though this will also work fine with a Raspberry Pi 2). Meanwhile, my domain ‘soulis-net’ will be running the Pi version of the domain server. Bear in mind that it will a bit barren but does at least show it allows people to go in and out.


Just a note for anyone thinking of running a Pi for any extended-use purpose: make sure it is on a battery-backup circuit with some sort of power-fail safe shutdown available! My own experience with using these (specifically Pi 3 units) in art installations is that a power-fail without correct shut-down of the Linux system has about a 1-in-10 chance of frying the SD card (The Pi itself is fine under a fresh SD card, but even with re-flashing the old SD card doesn’t work ever again!)

I just got in some of these though haven’t had a chance to play with them yet.

I don’t actually consider the Pi particularly suited for anything critical or long-term - a lot of design corners were cut to keep the price down. Having said that, the Pi is absolute #1 for education and experimentation - that is what it was designed specifically for, so I don’t even consider the issues from the corner-cutting a problem, just a design-decision. As such I have them stocked for student use at my university section in quite large quantities.

A Pi comp module on a custom board with appropriately-designed support circuitry is another matter, of course. From what I have seen, those units are manufactured to a more commercial specification (as they are intended for actual commercial use, of course).

The Pi is also, at present, the most truly open ARM-based architecture available by a long margin! This is very a very important factor to consider in the platform’s favor too.

Nividia TX2 (ARM)

What RSPI version were you building this one on? I’d also be interested in trying this out after I get my PI3+ (or later) someday down the line. Currently still only have a PI2 sitting as my gateway to my own local network but I am interesting in acquiring more.

I currently run my domain(s) on my “game server” (Athlon II X3 420E), and it can just fine run upto 6 people (havent had large groups tested yet), but Highfidelity seems to take much more bigger advantage of multicore systems, even with servers or parts of server (See last Voice stress test where we had 60< on a domain) and there been improvements to the audio stream throttling by range.


I use RPI2 and 3s for my noise monitoring network. They sit outdoors in a weather resistant box along with a sound meter in temperatures ranging from 29F to 96F (-1.6 to 35C). The box has enough air volume inside to buffer the temperature swings and they have worked excellently for over two years. Though their physical design may have cut corners for value engineering purposes, they can be quite robust so long as you understand their design limits. As a test, I ran an RPI at 75C core temp. I added heat sinks to the CPU and other chips, and It lasted almost a year.

In an indoor environment about the only thing to worry about is prematurely destroying the microSD card because of too many write operations. My suggestion on using a Raspberry PI as a domain server is to get a network attached or USB attached SSD and use that for the domain data files. Then the microSD card just handles syslog and other low volume data writes. Definitely configure the system to not do much paging. Or, move your swap space to the SSD.

Speaking of USB, this is the weak point for Raspberry PIs. It cannot handle too many devices and it uses a polyfuse that can cause voltage drops enough to power USB devices out of spec.


At this time, a Raspberry Pi 2 with Ubuntu 14.04 and Qt 5.6.0. I only had to use swap space for Qt compiling, but once that is done, no additional memory is needed. I have also had good success with an ODROID C1 (In fact, back when I was having issues with compiling Qt, I used the ODROID to experiment around first and apply what I learned there to fix the Raspberry version).

My first set of struggles were on a first generation Pi, but in the end, after 40 hours of compiling Qt, I got halted by the Intel TBB library preventing me from compiling Hifi. I covered this discovery here if you want to see where things started to go wrong.

EDIT: I actually remember that day for also discovering the cmake doesn’t checks on GCC’s version. This was back when you needed at least 4.7 and the Pi, by default, comes with 4.6.

EDIT EDIT: Just realized there are now TWO versions of Pi 2: ARM Cortex-A7 (1.0) and ARM Cortex-A53 (1.2). Mine is an ARM Cortex-A7. On my ODROID, I attempted to compile Qt as a 64bit setup (as it has support for it) but it had issues. I’m not sure if the domain-server/assignment-client are 64bit compatible, but it’d be interesting to see if it was possible.

[quote=“Balpien.Hammerer, post:4, topic:12263”]
Speaking of USB, this is the weak point for Raspberry PIs. It cannot handle too many devices and it uses a polyfuse that can cause voltage drops enough to power USB devices out of spec.[/quote]

I forget the article, but you can solder a capacitor on the power rail near the USB ports to give it boost when plugging in power hungry devices (which normally causes the entire Pi to lose power and restart).

Thankfully I’ve never had this happen (I think I had ONE case of where the SD card seemed to just corrupt itself, but that was back when I was using a Model B (first revision) for Bitcoin mining (loved Adafruit’s tutorial, but their display code wasn’t the same once I was done with it).


They are great little boards in general and I really don’t like knocking them! It is quite possible they have worked out a soft- or hard-fix since last student assessment period (when we get the most intensive use of the devices here) or will do before next time we go into intensive wide use of the devices. It will be 4-5 months until the next such assessment period and I will be keeping a close eye on things then.

Small SD cards are cheap, but make sure any important data is backed up somewhere very regularly (which is probably good general advice anyway!)


BTW, that was one of the corner cutting decisions omitting inrush current mitigation :slight_smile:
cc: @LaeMing


I would really like to see a ‘Pi Pro’ which is exactly like a regular Pi device but with the cut corners reinstated (and the associated price bump). And a socket for Odroid eMMC cards.


An RPI2 collecting noise data.