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.
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!
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.
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).
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.
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.
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.
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.
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 https://github.com/mikebrady/shairport-sync 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.
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?
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.