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 myoliveone.com.
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 ~$ 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.
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.
@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).
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.