Linn Forums

Current time: 2017-12-16, 06:14 Hello There, Guest! (LoginRegister)

Linn Forums / Linn Music Systems & Hi-fi Separates / Network Music Players & Music Streamers v / Roon support for Linn DS

Post Reply 
Roon support for Linn DS
2016-10-11, 04:19 (This post was last modified: 2016-10-11 04:24 by dannyroonlabs.)
Post: #31
RE: Roon support for Linn DS
My name is Danny Dulai and I am one of the founders of Roon Labs.

I'd like to address some of the theories here about Roon/Meridian/MQA. Some of the points are driven by speculations about the state of Roon and our company’s structure, so I’ll actually start by addressing those topics as well.

a) Roon is not operating at a loss. It’s an understandable guess, as we are a startup, but it couldn’t be more wrong.

- We hit cash-flow positive 12 months after launch, and have grown the team 33% over the past five months, completely out of operating revenue.

- Our subscriber base grows faster and faster every month, and we currently have no investment, loans, or outside interest. More expansion and growth is expected.

b) We are not trying to get acquired. In fact, we have actively turned down multiple investment and buyout offers in the last 18 months.

We have explored partnership opportunities, but they are very different from a situation where we would lose any control in the company.

Having lived through the experience of selling a startup (Sooloos), we structured Roon Labs to ensure that we wouldn't be beholden to investors with goals that might conflict with our own.

c) We invented and pitched RAAT to the industry because we see serious user experience problems with the “UPnP model”, and are not satisfied with the sound quality compromises of Airplay and similar protocols. I’ve spoken to the details of this on our community site https://community.roonlabs.com numerous times.

We currently have over 65 partners (some have shipped, some have announced, and some are quietly working), but not a single one paid for RAAT or the Roon Ready SDK.

Our goal is not to sell RAAT, but to provide the world with a better cross-manufacturer streaming solution driven by Roon’s user experience.

There are several important points to clarify in this respect:

- The RAAT protocol and the Roon Ready SDK are unmonetized

- RAAT contains no Meridian technology or intellectual property.

- Meridian has no financial interest in RAAT (or any Roon Labs products/technology).

- Part of the delivery of source code for the SDK and the redistribution of that code is a contract that states that Roon Labs is not charging for this access.


d) Sooloos was acquired by Meridian back in December of 2008, and that same team was spun back out to form Roon Labs in January of 2015.

This exodus was initiated by myself (Danny Dulai) and Enno Vandermeer, and not by Meridian.

“Spinout” is a funny word too, as Meridian has no equity interest in Roon Labs (nor does anyone outside of the Roon Team).

Although we remain friendly with Meridian, the support for their products within Roon is a historical reality rather than a strategic action, as we already had working implementations when we launched.

e) The Roon team has been together for over a decade, and we still provide metadata for the Meridian Sooloos line of products, and support streaming to our products specified back in 2004. I think our track record speaks for itself when it comes to supporting our solutions long term.

In closing… for all the speculation, there is no hidden agenda with RAAT.

Our only goal is to make Roon awesome, and we feel that tightly integrating Roon with the widest possible variety of partner devices via RAAT/Roon Ready is a critical part of that goal. If you don’t want to use Roon, it is entirely optional if your device supports something other than RAAT. No one is asking any product to be exclusively Roon Ready, we just want it be one of the options.

I hope this clears things up, and I’d like to reiterate here that we are extremely open about the state of the company and our goals. We have worked from day one to be as open and transparent as possible with our subscribers, because this kind of honesty is what will make Roon the best it can be.

Feel free to hop on our community site https://community.roonlabs.com and ask (publicly) whatever you’d like. Unless an NDA stops us from answering, we will probably just tell you what you want to know.
Visit this user's website Find all posts by this user
Quote this message in a reply
2016-10-11, 04:25
Post: #32
Roon support for Linn DS
As I posted above, my name is Danny Dulai and I am one of the founders of Roon Labs. Before I start, I’d like to say that this whole Linn/Roon thing is a sad state of affairs and apologize for our part in creating the confusion.


Keith’s summaries of the situation in posts #1 and #16 of this thread are spot on. The poor communication Roon Labs has had with Linn can be chalked up to changing goals and market positions, but in the end, we acknowledge we could have done better here, and for that, we apologize to everyone who felt that they have been led on, or in some way deceived.


Ultimately, Roon and Linn share the same goal… to serve our customers in the best way. Our understanding of how to do that has kept evolving as we’ve grown in the very short 18 months since launch, and unfortunately, we didn’t do a great job of communicating about this, either with Linn or with end-users.


Here, I will try to improve our communication….


Back in May 2015, Roon Labs was a brand new company (we didn’t launch Roon until May 12th 2015). RAAT was still a work in progress at the time, and the only possible avenue to support Linn devices was to integrate their existing OpenHome/Songcast protocols. We spoke to Linn at a business level and at a technical level multiple times. There were disagreements about OpenHome, but we agreed to the Songcast approach. We started implementing Songcast using Linn’s ohNet/ohMedia libraries, and some technical hitches caused us to pause that work.


A bad experience we had working with some non-Linn Songcast hardware also left us unsure that Songcast support was a good idea after we found that the protocol wasn’t consistently implemented in the real world- Songcast support cannot be limited to Linn devices, and inconsistent implementations would be a guaranteed support issue..


As our launch progressed, work was prioritized on the v1.1 and v1.2 releases- Taking care of our current subscribers with features like iOS remotes and DSD were front-burner issues that superseded the opportunity to find new subscribers with Linn support.


The Roon Ready program was launched, we maintained an aggressive development cadence providing the features that were in highest demand by our subscribers, and the Songcast project was never resumed.


As we arrive to today and look ahead to our upcoming 1.3 release, we find that the world is different now, and what we believe to be the best solution for Linn and Roon customers has changed.


RAAT/Roon Ready has exploded in popularity, and we have a large share of manufacturers in the HiFi space adopting RAAT and creating Roon Ready devices.


One of the goals of this protocol is to produce a unified and consistent experience when mixing hardware from different manufacturers, particularly during multi-zone playback. If we implement Songcast, Linn users will not be able to enjoy those benefits.


We again apologize for any confusion along the way, but it is now clear to us that Songcast implementation would make Linn users second class citizens in the Roon community, which is the last thing we would want to see.


With these things in mind, we believe that a RAAT-based integration is a better final outcome for our mutual customers.


There are a few points that we should probably clarify so that everyone understands how the Roon Ready relationship works, since there has been some confusion around this.


* The RAAT/Roon Ready SDK is available to all hardware manufacturers who make networked audio devices. There are no license fees or charges involved.


* Manufacturers are free to implement any other protocols they would like alongside RAAT.


* Access to the RAAT/Roon Ready SDK requires signing a contract which gives permission to use Roon trademarks.


* Most importantly, the SDK contract requires partner devices to go through a certification process prior to commercial release, which allows us to ensure consistent quality across all implementations.


* The certification process works both ways, as the hardware manufacturer gets a chance to sign off that Roon is not doing anything to compromise audio quality.


The SDK we deliver to Linn looks very much like what they would get from an Open Source project--a small ANSI C codebase that they are free to integrate and customize for their platform. Although they are not free to redistribute this source code externally, they are free to use it in Linn products. This puts Linn in control of their source base. They can even submit patches back to us if desired.


When it comes to actually getting this integration done, the practical distinction between our SDK and an open source project is that the code is not also available to the general public. I’m not sure why the politics of open source software are entering the situation, or if this is a misunderstanding of the fact that we do make source code available to partners.


Ironically, the decision to require certification and create a structured SDK program was made partially in response to the experience we had when we were working with SongCast.


We had no Linn hardware at the time, and a partner of ours had sent us a Songcast-compatible device. We were going to use that device to test our Songcast implementation, but that ended quickly because we found the implementation limited and unstable. This was completely the fault of the partner, and when we talked to Linn, they were unaware that this partner had even shipped a product with Songcast support and were not in a position to rectify the situation, because Songcast is an open source project.


This felt to us like a repeat of the same issues that plague UPnP. We decided to avoid this problem with RAAT by securing a business relationship with manufacturers and ensuring that we are in a position to control the quality of our ecosystem.


We also have some business issues with going “open source” or for us to “openly specify RAAT”. RAAT/Roon Ready is more than a piece of technology--it is also a set of business relationships and processes that work to enable a wide variety of consistently implemented, high quality Roon Ready implementations in the marketplace. Roon’s primary value is the UX we provide, and RAAT/Roon Ready is our solution to solving the UX compromises of the “UPnP model”, and quality losses from the “Airplay model”. This is a two way street, as the manufacturer gets to confirm that no audio compromises have been made, and we get confirm that no UX compromises have been made.


Asking us to open source the code or the protocol is not reasonable because it undermines this goal completely. It removes our ability to assure quality via certification and puts our reputation at risk. This is tantamount to us asking for Linn to open source their hardware design specifications and then allowing anyone to build products with Linn’s brand on them.


I know that many see RAAT as just another streaming protocol out there, but the confidence both manufacturers and users have in its consistent, reliable quality is a major reason for its success.


In conclusion….


I’ve tried to lay out the situation from the Roon side of things. If the Linn team is indeed willing to start work on this tomorrow, getting going with the Roon Ready SDK and proceeding as a Roon Ready Partner would be the best way to serve our mutual customers. We would likely be done in a month’s time.


As stated before, 65+ other hardware manufacturers have done or are doing this, and we would very much like Linn to be one of them.


We feel strongly that Linn customers should have access to the same features and benefits as our other partners’ customers, and to enjoy ongoing development as we continually improve and extend the feature set of the RAAT and Roon Ready programs.


We look forward to working with the team at Linn and are committed to providing any support necessary, as we do with all our partners.
Visit this user's website Find all posts by this user
Quote this message in a reply
2016-10-11, 05:29
Post: #33
RE: Roon support for Linn DS
Danny and Keith, thank you both for your comments. You have managed to bring a degree of clarity to a series of discussions on both Linn's and Roon's forums that to date had really done little more than make obvious the frustration of those of us wishing to use Linn and Roon together in a way that does not involve Airplay and does not involve acquiring (or making) additional streamers to plug into our fairly expensive Linn streamers (where that is even possible).

Unfortunately, we appear to remain at an impasse, since Roon does not intend to adopt Songcast support, or to open-source its RAAT code or publish an open spec for RAAT, and Linn does not intend to implement RAAT otherwise.

I can understand why Roon does not wish to open-source the RAAT code or spec. I can also understand Linn's lack of interest in adopting third-party proprietary code into its products. There would appear to be two main problems from Linn's point of view, which I would think could be addressed by appropriate license terms if both parties were willing:

1) Linn wants to know that it could not be held hostage in the future if it adopted RAAT code into its products. If the rights Linn obtains to the RAAT code are perpetual and irrevocable (and include the right to continue modifying the code going forward), and do not impose limitation on other activities of Linn, this concern could be largely ameliorated (from my, admittedly limited, perspective).

2) Linn also wants to know that the certification process will never interfere with Linn's ability to ship products or updates as it sees fit. This is where the more difficult problems are likely to arise. If certification is necessary only in order to display a Roon Ready (or similar) label, this problem is also ameliorated, since Linn could then always ship when it needs to, with the caveat that the Roon Ready label could be applied only after certification had been obtained. However, if the RAAT license permits the RAAT code/specifications to be used only in products that have been certified, Linn will have an understandable problem, since it would not want to have the choice of either (a) delaying shipping if certification for any reason ever were slow or not forthcoming or (b) having to alter its firmware to remove the RAAT code and functionality in such cases.

Certification is also more problematic for Linn than for many of Roon's announced partners, since streaming is at the heart of a great number of Linn's products, rather than one or two streamers.

From Roon's point of view, the main problem is that Roon would not want to dilute the quality of its brand/image by allowing sub-standard implementations to be associated with Roon or RAAT, and would not want to open-source or otherwise publicize its code and spec in a way that would enable competitors to use it to develop competing protocols.

One could imagine terms of a certification program that would give Linn comfort on these points, while also protecting Roon's brand by ensuring that Roon Ready and similar labeling only appears on products that have been certified. For example, once Roon had certified particular code (such as a version of Davaar) in a particular DS product, re-certification should not be necessary when the code is used in other products. In addition, as noted above, certification would ideally be a condition only to display of a Roon Ready or similar label, rather than to use of code. I don't know if the current RAAT license terms are currently structured this way, but they could be.

As you may guess, I have drafted an agreement or two of this type in my time... I honestly think this is a case where the parties (Roon and Linn) have common interests in making the best experience available to their customers, and that with some creativity it would be possible to reach terms that would work for each party. It will require more work on each side, though, than simply demanding that RAAT must be open-sourced or that Linn must sign up to standard RAAT license terms (unless the standard terms really address the above points in a way that would be comfortable to Linn).

I encourage both sides to sit down in a room and try in good faith to work through the substantive issues. Given the obvious intelligence and creativity of both companies, a solution could be reached if the motivation is there.

In the short term, I also encourage Roon to reconsider Songcast at least as a stop-gap measure, ideally coupled with assurances from Linn that Linn would continue to discuss in good faith supporting RAAT.

Sorry for such a long-winded post -- please chalk it up to occupational hazard.
Find all posts by this user
Quote this message in a reply
2016-10-11, 06:02 (This post was last modified: 2016-10-11 06:09 by Tin.)
Post: #34
RE: Roon support for Linn DS
Hello Danny,

Thank you for your reply.

Closed protocols are a thing of the past. If your UX is good enough to attract customers, than opening up RAAT won't change that. If it isn't, keeping it closed won't change that either.
What keeping it closed and having a good UX will inspire is that a 3rd party will try to recreate something RAAT like, open it and push RAAT, and Roon out of the way.

Closed protocols have never been prosperous on the long run. When Microsoft developed Active X and made sure it would only work with IE it served them well on the short run, but they're in decline ever since, and that was mostly because companies and people started to realise they don't want to be boxed in.
Apple has been succesful for a couple of years afterwards as well, but more and more people start to object against the closed infrastructure at that end as well.

I can understand appreciate that if you want to be aquired, and having a very small startup by myself, I can't judge you on that, and I know that a closed RAAT will help you with that goal, and so will the certification part.
If you open up RAAT, you will change your goals, and growth will be slower, but more persistent towards the future.
It is your choice, but it is a fundamental one.
You could even have certification while making the protocol open if the certification part is the reason that keeps you awake at night.

The only thing I can add is that I urge you to reconsider.
So, er.. please reconsider... Smile
Find all posts by this user
Quote this message in a reply
2016-10-11, 06:18
Post: #35
RE: Roon support for Linn DS
So, to summarize: Roon won't happen on Linn. Fine. Time to return to the music...

Main: KDSM/2 - Solos/D - Akubariks

HeadFi: KRDS/1 - Simaudio Moon Neo 430 HA - HiFiMAN HE1000
Find all posts by this user
Quote this message in a reply
2016-10-11, 09:46
Post: #36
RE: Roon support for Linn DS
It would be interesting to hear Keith's reply however it would also be understood if LINN did not wish to reply on an open forum.

My two cents (for what it is worth) speaking as a Linn customer:

1) ROON and Linn - don't bother with Songcast. LINN customers have spent significant money on our streamers and do not want to compromise on sound quality

2) if ROON cannot be implemented than LINN, please, give us something better than Kazoo which comes close to a ROON type experience in UX

Naim 552/500 into Kudos Titans
Cymbiosis Signature LP12/Chris Harban Plinth/Keel/Karmen/Radikal/Urika/Chord Music/Aro/Kandid
KDS/3-Chord Music
Find all posts by this user
Quote this message in a reply
2016-10-11, 11:11 (This post was last modified: 2016-10-11 22:10 by mcgillroy.)
Post: #37
RE: Roon support for Linn DS
(2016-10-11 04:19)dannyroonlabs Wrote:  My name is Danny Dulai and I am one of the founders of Roon Labs.

I'd like to address some of the theories here about Roon/Meridian/MQA. Some of the points are driven by speculations about the state of Roon and our company’s structure, so I’ll actually start by addressing those topics as well.

a) Roon is not operating at a loss. It’s an understandable guess, as we are a startup, but it couldn’t be more wrong.

- We hit cash-flow positive 12 months after launch, and have grown the team 33% over the past five months, completely out of operating revenue.

- Our subscriber base grows faster and faster every month, and we currently have no investment, loans, or outside interest. More expansion and growth is expected.

b) We are not trying to get acquired. In fact, we have actively turned down multiple investment and buyout offers in the last 18 months.

We have explored partnership opportunities, but they are very different from a situation where we would lose any control in the company.

Having lived through the experience of selling a startup (Sooloos), we structured Roon Labs to ensure that we wouldn't be beholden to investors with goals that might conflict with our own.

c) We invented and pitched RAAT to the industry because we see serious user experience problems with the “UPnP model”, and are not satisfied with the sound quality compromises of Airplay and similar protocols. I’ve spoken to the details of this on our community site https://community.roonlabs.com numerous times.

We currently have over 65 partners (some have shipped, some have announced, and some are quietly working), but not a single one paid for RAAT or the Roon Ready SDK.

Our goal is not to sell RAAT, but to provide the world with a better cross-manufacturer streaming solution driven by Roon’s user experience.

There are several important points to clarify in this respect:

- The RAAT protocol and the Roon Ready SDK are unmonetized

- RAAT contains no Meridian technology or intellectual property.

- Meridian has no financial interest in RAAT (or any Roon Labs products/technology).

- Part of the delivery of source code for the SDK and the redistribution of that code is a contract that states that Roon Labs is not charging for this access.


d) Sooloos was acquired by Meridian back in December of 2008, and that same team was spun back out to form Roon Labs in January of 2015.

This exodus was initiated by myself (Danny Dulai) and Enno Vandermeer, and not by Meridian.

“Spinout” is a funny word too, as Meridian has no equity interest in Roon Labs (nor does anyone outside of the Roon Team).

Although we remain friendly with Meridian, the support for their products within Roon is a historical reality rather than a strategic action, as we already had working implementations when we launched.

e) The Roon team has been together for over a decade, and we still provide metadata for the Meridian Sooloos line of products, and support streaming to our products specified back in 2004. I think our track record speaks for itself when it comes to supporting our solutions long term.

In closing… for all the speculation, there is no hidden agenda with RAAT.

Our only goal is to make Roon awesome, and we feel that tightly integrating Roon with the widest possible variety of partner devices via RAAT/Roon Ready is a critical part of that goal. If you don’t want to use Roon, it is entirely optional if your device supports something other than RAAT. No one is asking any product to be exclusively Roon Ready, we just want it be one of the options.

I hope this clears things up, and I’d like to reiterate here that we are extremely open about the state of the company and our goals. We have worked from day one to be as open and transparent as possible with our subscribers, because this kind of honesty is what will make Roon the best it can be.

Feel free to hop on our community site https://community.roonlabs.com and ask (publicly) whatever you’d like. Unless an NDA stops us from answering, we will probably just tell you what you want to know.

Danni,

thx for this very informative and enlightening post! I wish more companies would communicate like this.

I am happy to learn that Roon is doing well and that my assumptions mostly seem unjustified or plainly wrong.

Evidently Linn and Roon differ in their approach and I hope an agreement can be worked out. Given the business interests at stake short and long term the situation seem not to look very promising. But who knows, maybe there are surprises along the way.

edit: typo

http://www.last.fm/user/mcgillroy

MDSM/2 - 6100/D - active Kabers - Nubert 441w sub + Qobuz Sublime.
Find all posts by this user
Quote this message in a reply
2016-10-11, 14:42 (This post was last modified: 2016-10-11 14:46 by dannyroonlabs.)
Post: #38
RE: Roon support for Linn DS
(2016-10-11 05:29)stuartb Wrote:  1) Linn wants to know that it could not be held hostage in the future if it adopted RAAT code into its products. If the rights Linn obtains to the RAAT code are perpetual and irrevocable (and include the right to continue modifying the code going forward), and do not impose limitation on other activities of Linn, this concern could be largely ameliorated (from my, admittedly limited, perspective).

2) Linn also wants to know that the certification process will never interfere with Linn's ability to ship products or updates as it sees fit. This is where the more difficult problems are likely to arise. If certification is necessary only in order to display a Roon Ready (or similar) label, this problem is also ameliorated, since Linn could then always ship when it needs to, with the caveat that the Roon Ready label could be applied only after certification had been obtained. However, if the RAAT license permits the RAAT code/specifications to be used only in products that have been certified, Linn will have an understandable problem, since it would not want to have the choice of either (a) delaying shipping if certification for any reason ever were slow or not forthcoming or (b) having to alter its firmware to remove the RAAT code and functionality in such cases.

The source is not revocable, and certification is only done once, at initial release. If later updates happen to break certification, we will work with the manufacturer to get it fixed on their schedule. If they refuse to fix, we display "uncertified" in Roon, but it still works (as well as it can). This happened only once before and the manufacturer just fixed the issues in a subsequent update.

Some manufacturers have tried to release beta quality integrations, and we asked them to stop and Roon always showed uncertified. However people did use those implementations in the meanwhile. Here is a very public case of this discussed on our community site with Bryston. In that discussion is information on how certification works and feedback from Bryston as well.
https://community.roonlabs.com/t/bryston...roper/8209

We understand the problem here. Even a company with a legal team much larger than Linn has signed up for Roon Ready (not released yet). If our terms interfered with release or ownership, no one would sign up. Big or small, no one wants another company to be a factor in these aspects of their operations.

If there ever was a situation where the manufacturer was advertising uncertified Roon Ready support, and was being uncooperative with fixing the concerns we had, we'd send them a legal statement asking them to stop using our brand. It wouldn't stop them from shipping uncertified, just stop them using the brand.
Visit this user's website Find all posts by this user
Quote this message in a reply
2016-10-11, 15:27
Post: #39
RE: Roon support for Linn DS
Danny, thanks again -- this is very heartening.

Keith, I hope Linn will take a serious look at the RAAT license terms. If, as Danny explains, the license will never interfere with Linn's ability to ship, and the worst case (in the event of any certification issues) is that use of the Roon brand would have to be suspended, it sounds as if the license terms are livable, even if not meeting Linn's preferred open source ideal.
Find all posts by this user
Quote this message in a reply
2016-10-11, 16:22
Post: #40
RE: Roon support for Linn DS
(2016-10-11 15:27)stuartb Wrote:  Danny, thanks again -- this is very heartening.

Keith, I hope Linn will take a serious look at the RAAT license terms. If, as Danny explains, the license will never interfere with Linn's ability to ship, and the worst case (in the event of any certification issues) is that use of the Roon brand would have to be suspended, it sounds as if the license terms are livable, even if not meeting Linn's preferred open source ideal.

Is it just me that is finding this thread has drifted into an uncomfortable place (inadvertently I am sure but nevertheless).
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 2 Guest(s)