I’ve said this before but perhaps it bears repeating. And it’s likely not going to make the community happy. Nor will the answer be short.
The dilemma we face about creating a Roon end point for Octave runs deep to the core of why we built Octave in the first place. We are building Octave so that we may control the end to end experience for our users. In this way, we can ensure a
level of performance unachievable with leveraging 3d party apps. And Roon is a 3d party app that relies upon 3d party hardware.
As many of you may or may not remember, this isn’t our first run at building a music server. Long before there was Roon, we built eLyric. It was one of the very first music servers out there (though in fairness Roon was once Sooloos which came
before eLyric). We invested more than I care to remember in eLyric and it was, in the end, not what we had hoped it would be. It was based on 3d party software elements that we wove together. The same can be said of the Bridge. While it’s a great product and
I love the Bridge, it is frustrated (and sometimes our customers too) because it’s a 3d party product we engineered around. And Roon is too. When Roon has an issue we’re at a loss to help until they decide to fix it. And once they do then we have to scramble
to figure out how to implement their changes and beat up our 3d party vendor to do the same.
I remember the last one with Roon when Apple changed their OS and Roon had to issue public apologies etc. because in the end, Roon is running on 3d part software too (the computer’s OS). And meanwhile our customers bear the brunt of this mishegas.
From day one Octave has been built from the ground up on Linux without using any 3d party bits that haven’t been scrubbed and implemented the way we want. Once launched, the decision to upgrade the OS or to upgrade Octave, is entirely up to us
(no OS updates from Microsoft or Apple). This ends the constant nightmare of not being in control of what happens. No longer do we worry about guaranteeing sound quality because yes, sound quality in a server varies from OS to OS, from computer to computer,
from Roon to whatever you are using.
Were we to add a Roon end point to Octave we give up control and are again at the mercy of their sound quality, of their decisions, of the sound of the computer’s required to run them, of the networks required to distribute them, of the metadata
and matches they decide on, etc. Just imagine for a moment from our viewpoint. We offer you a $6K server we are touting as the best sounding and performing music server/streamer yet made (and we tout this because it’s true). You install it,
use Roon to control it, and let us know that it “sounds a bit better than what you had but overall it’s not a lot different/better than what came before it” and thus we have failed to meet our promise to you. Our people ask, “are you running Octave or Roon?”
And you answer Roon and then we say, well, if you stop doing that and run Octave you’ll fix what’s wrong, and you say “that’s not why I bought this. My old server did this or that or sounded this way or that way” and what do we say other than sorry? I am not
in this to say “sorry”.
I can hear it now. “Yeah, ok, just give us the choice. We can decide for ourselves how much better Octave is or isn’t”. And, that’s a good point for some and a possible solution, yet for most people, they want to buy a product and have it work.
One and done. And that’s how it should be.
The whole thing is messy and not within keeping of the purity of purpose we have envisioned for the product.
So, now you know what we’re wrestling with.
Octave is far more than hardware. It feels disingenuous to sell it as just a piece of hardware because it is designed from the ground up to be used as an entity. And, as an entity, it will deliver what we promise. Hobble it and we’ve now delivered
less than its essence.
We’re still thinking and looking inwards for answers.
It cannot be everything to everyone.