Roon on the Olive ONE player

Hi Roon team,

we recently purchased a great embedded player/amp from Olive Inc. as part of an Indiegogo campaign. Unfortunately for us backers, the company now seem to have gone offline, leaving the backers with a player that only supports half of the promised features. Currently, we are gathering the backers on Slack to discuss alternatives. Our favored alternative is Roon, as it integrates most features we originally backed for…and of course many additional features. There are 1,414 backers out there with approx 1 unit per person and amount X of customers who bought the Olive ONE via HiFi stores, Amazon or directly at
The hardware is fantastic and the backers would love to keep the unit alive into the future. However, the software is a mess with random problems of all kinds (database inconsistencies, Bluetooth problems, WiFi reconnects during streaming, random playback pauses, etc.).

Fortunately for us, we have the root password for the unit and were able to extract some information about the device:

  • We have been able to play sound from the command line using: cat /dev/urandom | aplay -f S16_LE -c 2, and it seems to have configured ALSA.

  • The unit is running BusyBox on: Linux OLIVE 3.0.35 #1 SMP Tue Apr 26 14:52:01 CST 2016 armv7l GNU/Linux

  • Processor : ARMv7 Processor rev 10 (v7l) processor : 0 BogoMIPS : 790.52 Features : swp half thumb fastmult vfp edsp neon vfpv3 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part : 0xc09 CPU revision : 10

  • root@OLIVE ~$ lsusb Bus 001 Device 001: ID 1d6b:0002 Bus 002 Device 001: ID 1d6b:0002 Bus 002 Device 002: ID 0489:e00d

  • root@OLIVE ~$ free total used free shared buffers Mem: 447772 359540 88232 0 10660 -/+ buffers: 348880 98892 Swap: 0 0 0

  • root@OLIVE ~$ mount rootfs on / type rootfs (rw) /dev/root on / type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered) proc on /proc type proc (rw,relatime) /sys on /sys type sysfs (rw,relatime) /tmp on /dev type tmpfs (rw,relatime,mode=755) devpts on /dev/pts type devpts (rw,relatime,mode=600) shm on /dev/shm type tmpfs (rw,relatime) rwfs on /mnt/rwfs type tmpfs (rw,relatime,size=204800k) rwfs on /tmp type tmpfs (rw,relatime,size=204800k) /tmp on /tmp type tmpfs (rw,nosuid,nodev,relatime) /dev/mmcblk0p4 on /cfg type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered) /dev/sda on /cfg/data type ext4 (rw,relatime,user_xattr,commit=30,barrier=0,data=ordered) root@OLIVE ~$ df -h Filesystem Size Used Avail Use% Mounted on rootfs 788M 471M 277M 64% / /dev/root 788M 471M 277M 64% / /tmp 219M 56K 219M 1% /dev shm 219M 0 219M 0% /dev/shm rwfs 200M 0 200M 0% /mnt/rwfs rwfs 219M 4.4M 215M 2% /tmp /tmp 219M 4.4M 215M 2% /tmp /dev/mmcblk0p4 2.0G 40M 1.8G 3% /cfg /dev/sda 917G 32G 840G 4% /cfg/data

  • root@OLIVE ~$ lspci 00:00.0 Class 0604: 16c3:abcd 01:00.0 Class 0101: 1b21:0611

  • `root@OLIVE ~$ python
    Could not find platform independent libraries
    Could not find platform dependent libraries <exec_prefix>
    Consider setting $PYTHONHOME to [:<exec_prefix>]
    ‘import site’ failed; use -v for traceback
    Python 2.4.4 (#1, Jul 16 2013, 18:38:13)
    [GCC 4.6.2 20110630 (prerelease)] on linux2
    Type “help”, “copyright”, “credits” or “license” for more information.


  • root@OLIVE ~$ cat /proc/meminfo MemTotal: 447772 kB MemFree: 87048 kB Buffers: 10740 kB Cached: 75792 kB SwapCached: 0 kB Active: 249660 kB Inactive: 65484 kB Active(anon): 228904 kB Inactive(anon): 4048 kB Active(file): 20756 kB Inactive(file): 61436 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 447772 kB LowFree: 87048 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 4 kB Writeback: 0 kB AnonPages: 228624 kB Mapped: 29768 kB Shmem: 4364 kB Slab: 33196 kB SReclaimable: 27684 kB SUnreclaim: 5512 kB KernelStack: 1496 kB PageTables: 1952 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 223884 kB Committed_AS: 1310032 kB VmallocTotal: 1335296 kB VmallocUsed: 2116 kB VmallocChunk: 1332204 kB

Could you please give us some pointers on the dependencies of the distribution so that I can get a grip of the scope of porting Roon?

I guess there are many of us willing and able to subscribe a membership to get Roon to the Olive ONE, as the ONE offers a great hardware for music enthusiasts like us!

Any help is greatly appreciated,
Max & Kidahl

1 Like

I’m not a Roon representative, however, as it’s an armv7 device the best you could do is install Roon Bridge on it and use it as a Roon endpoint.

If you’re able to access the boot image it’d be useful to image it using dd for safekeeping and perhaps pop a copy onto Dropbox - happy to have a look at it to see if I can make some suggestions.

Hi Max and Kidahl,

I’m not part of the Roon team, just a user and volunteer moderator. I don’t know to what extent the Roon developers are able to assist, but the wider Roon user community includes people with a broad range of skills and experience who are often able to help each other.

The starting point is to understand Roon Architecture and the roles of Core, Control and Output. There are a number of Software packages reflecting those different roles.

The Olive One was intended to fill all of these roles within its’ own architecture, but is only suited for one of them in Roon.

Firstly, the Olive One won’t run a Core. The ARMv7 is below spec and Linux Roon and Roon Server are only compiled for x86_64 platforms.

It is, however, possible that it could run as an Output. Linux Roon Bridge is compiled for armv7hf. The dependencies required are set out here.

Running Roon Bridge would mean the display on the Olive One would not be functional and you would need a computer running a Core. You could then use a Control (computer, tablet or phone) to send audio to the Olive.

You might be able to install Roon Bridge on to the current Olive OS or, depending on access, you could try booting the Olive with a whole new OS. Roon Bridge will run on Debian. Armbian, Arch Linux and many other distros. I can’t say how easily any new OS would interface with the DAC and amplifiers within the Olive.

Edit: typed the above before seeing @evand’s post. We’re saying much the same thing.

1 Like

@evand and @andybob
Thanks for your reply, running the bridge is indeed the only realistic option.

There are however some roadblocks getting this to run on a unit that contains no compiler environment. The unit uses LibC 2.13, so all binaries refuses to run.

Getting a new OS to cross compile and run on the unit is a huge undertaking. I´m no expert in these matters, but I suspect that we will also have trouble getting the audio hardware to work if we for example took a Raspberry Pi distro.

Is there any hope of Roon providing a statically linked Bridge ARM distribution? That would unfortunately also have to include the dependencies (they are only provided in binary form for x86).

Karl Ivar Dahl

Let’s ask some grown-ups, @brian and @danny ?

Roon Bridge is already provided for armv7h …

Seeing as you have root access, download and attempt to install it. Given you’ve got aplay going I suspect you’ve already got all you need iro ALSA.

Thanks for bringing this to our attention, @andybob.

I’m going to raise a discussion about this internally before responding with a ton of details. No idea where it will go–definitely an unusual situation.

1 Like

The Bridge is indeed available as a binary, but it requires a later LibC version:

root@OLIVE /root/RoonBridge/Bridge$ ./RoonBridge
RoonBridge: /lib/ version `GLIBC_2.16' not found (required by RoonBridge)

Then it is also the matter of the dependencies not being available in binary form.

Could it be an idea to provide statically linked binaries, libC included?

…and yes, alsa is available. I can make sound using the following command:

cat /dev/urandom | aplay -f S16_LE -c 2

You need more than that. Our builds are for hard float environments–that’s an armv7l environment. It will blow up as soon as you hit a floating point instruction even if you resolve the library stuff.

Static linking is far from trivial for our builds. If we were to make binaries for that device, we’d start with a toolchain that matched its environment. There’s no way to DIY this.

@brian, would replacement of the OS with a suitable ARM Linux userspace not enable Roon Bridge to run?

I don’t think you can go to hard-float without replacing the kernel.

If someone put in the effort to replace the OS with something more modern + based on hardfp, Roon Bridge should run just fine. That doesn’t light up the screen, though.

1 Like

Ok, so we should probably focus on establishing a viable platform first. Do you have a recommendation to what we should consider? The unit has a disk drive so storage is no problem.

I have had a look at OpenWRT but would rather build on a proper distribution such as RasPi.

I’m biased so I’d recommend Arch Linux for ARM. Debian for ARM may also be a good candidate.

Thanks, I’ll check it out

Out of interest, what’s the resolution of the display?

The display resolution is pretty low, the screen is by far the least impressive part of the device. I do however not know the specs.

However, I have an update on our progress. Jörg Krause over at has provided us with a statically linked ShairPlay-Sync binary that so far seems to work flawlessly.

If I understand correcly, Roon may stream to AirPlay targets, so If I understand correctly we are functionally pretty close to the benefits of the Roon bridge?

Thank you so much for your interest in helping us out on this. I think we will consolidate our efforts now to see how far we can get with Shairplay as a starting point.

1 Like

Once the Roon API is released, it will be possible to make a lightweight UI for the device (since running Roon Remote on it seems pretty unlikely). We’re going to expose enough functionality to drive home automation touch-panels.

If you get the OS into a sane/modern place, then Roon Bridge + an API-based UI would be a reasonable outcome that is doable without our help.

I think getting control of the OS is step 1. If you can figure out what the chip is and back that out to which dev board/platform/vendor they used to develop the product, you might find that there’s a shortcut available or a distribution that already works. It will also help you figure out how to boot the thing with a new kernel.


It would sure we great to use these as a RoonBridge. The UI is not really as much of an issue since there are alternatives.
Has any progress been made?

What’s the root password for these devices?

[I Have No Idea What I’m Talking About]

Could you install squeezeplay, and/or LMS, and turn it into a squeezebox, then use the squeezebox support built into roon to stream to it? wouldn’t address the display i imagine.

[/I Have No Idea What I’m Talking About]