DS Technical Architecture FAQ

This page is intended for the technically inclined who wish to understand the technology the DS uses and how it operates.

The DS Itself

Technically, what is a DS?

The DS offers a service to the network; the service of turning data into music at the highest possible quality. It exposes this service to the network over various open protocols.

How does one speak to the DS?

Most users currently use UPnP, although you can also talk to it via LPEC. The DS is not architecturally limited to these protocols and it is both possible and likely that we will implement other mechanisms of communicating with the DS in the future.

What computery stuff is inside a DS?

All DS' share a common processor board. This is a custom bsp designed around a Virtex 4 FX FPGA. The Virtex 4 contains a real, physical powerpc 405 running at 300 MHz and has access to 32 MB flash and 64 MB of ram. The FPGA allows considerable hardware flexibility and is crucial to our pursuit of the highest possible quality.

The ppc runs an OS built on top of the open source rtems unix rtos. In addition to the core scheduler, threading support, c libraries, rtems also provides the Free BSD ip stack. Linn's software is developed on top of this and is written in C++ making full use of exceptions, templates, and modern design patterns.

Communicating with the DS

What is UPnP?

UPnP is a suite of protocols providing discovery, control, and eventing.

• Discovery allows control points to find devices offering particular services on the network without any prior knowledge of their existence or location.
• Control allows control points to request a service from a device.
• Eventing allows devices to notify control points of changes in their state.

It is an open, published standard requiring no fee to obtain it.

Further information and summaries: 

• http://en.wikipedia.org/wiki/UPnP
• http://www.upnp.org/about/default.asp

What is UPnP AV?

The UPnP audio visual standard defines a common way for various parts of a audio visual home network to interact. One of the key insights of this specification was the identification of the following three parts of the network:

• Media Servers: Offer the service of retrieving media from a storage location
• Media Renderers: Offer the service of turning data into its rendered format (music, video, etc). The DS is a Media Renderer.
• Control Points: Control the interaction of the home network. They tell a Media Renderer to retrieve a resource from a Media Server and to render it.

Implemented correctly, this model of the home allows one to have an arbitrary number of media servers, an arbitrary number of media renderers, and an arbitrary number of control points all interacting with each on the same network. This is clearly important in a multiroom home.

Does the DS implement UPnP AV?

Yes. We believe standards conformance is extremely important and aim to have the most compliant UPnP AV devices on the market. T

Is the UPnP AV specification a panacea?

No. There are a number of problems with the specification. Although the theory of the model allows for multiple renderers and control points, there are a number of problems in the details of the specification that prevent this from working effectively. One major problem area is that in UPnP AV, control points, rather than the renderers store the playlist. This means that a 2nd control point that joins the network cannot determine the playlist of a particular renderer.

But the DS works with multiple control points! How'd you do that?

We recongised the problems with the specification and have defined and implement some UPnP AV extensions which we believe correctly address the issues.

Do the Linn Upnp extensions mean you're not compliant with the specification?

No. You can interact with the DS solely via the UPnP AV specification if you wish. This is how the Nokia N800, N95, Cidero and 3rd party UPnP Av control points interact with the DS. Alongside of the base UPnP AV implementation, you can also choose to interact with the increased functionality of the Linn DS extensions. This is how the LinnGUI, Kinsky, LeiaDS, Songbook, and a number of unreleased applications interact with the DS. We have no desire to hide this (or any) functionality of the DS and we hope to see the extensions standardised into the main specification in the future.

Control point software

What's Kinksy?

Kinsky is an open source (BSD license) software control point. It is capable of interacting with both Linn DS products as well as any product that implements the UPnP AV protocol (Roku, Sonos, various others).

What's the LinnGUI?

The LinnGUI is Linn's official release of the open source Kinsky project.

Why doesn't it look beautiful like SlickMediaPlayer?

Some history is probably useful here. The interaction and aesthetic of the LinnGUI was originally designed for use with touch panels like the Samsung Q1. Big buttons, a simple interaction model, high contrast, with minimal flashy stuff was central to the design. Arguably, it works quite well for that use case.

However, many DS users use the LinnGUI on their desktop or laptop computers. Others wish they could use it on their pda. Both of these are different use cases, requiring different graphics, a different interaction model, and different feature sets. We are very aware that the LinnGUI as it currently exists is not ideal for use outside the touch panel. We are moving quickly to address this.

Why doesn't the LinnGUI have cover art?

Unfortunately, when it was originally released, the most commonly used media servers didn't support flac cover art. They do now, but the interaction model of LinnGUI v1 doesn't lend itself to album art. Note that the DS itself works with cover art.

Will the next version of the LinnGUI utilise cover art?

Yes.

Must I use the Kinksy or the LinnGUI to interact with the DS?

No. Because of the DS' open interfaces, you can use any software that implements those interfaces. See the questions on Upnp AV above.

What's Kinsky written in?

.NET 2.0. In addition to Microsoft's runtime, it also compiles and runs on Mono's open source runtime. Therefore, Kinsky can run on any target platform that Mono supports. Currently mono fully supports Windows and Linux. Their MacOSX support is rapidly improving, but there are still some bugs.

What is .NET?

.NET is a cross platform, cross language, software environment. See: http://en.wikipedia.org/wiki/Microsoft_.NET

Isn't .NET actually a Windows only technology?

No. It's true that the most complete implementation of .NET is provided by Microsoft only for their platforms.

However, we are committed to ensuring that our code always runs and compiles under the open source Mono implementation. As mono is both open and cross platform, this ensures that Kinsky will also always be open and cross platform.

I've heard on the forums that Linn is anti Mac and chose .NET to prevent mac users from using the DS. Is this true?

No. We are very keen to have first class support for Mac and are working towards it.

That said, Kinsky actually works reasonably well on the Mac today. There are some bugs, and it's not as easy as we'd like to setup and configure, however, we are working to resolve those issues. It's because of these issues that the official LinnGUI does not yet list support for the Mac.

So why'd you choose .NET then?

Primarily two reasons:

1. Because the .NET library framework is outstanding and allowed us to focus on developing what we need rather than dealing with esoteric low level platform issues.
2. Because .NET via mono is one of the most cross platform development environments out there. Mono has implemented most of the .NET apis from scratch in "managed code" which means that they should behave much the same on all platforms. It wasn't sensible for us to develop a native UPnP library and GUI for multiple platforms, so a cross platform library made a lot of sense. Arguably, we could have chosen Java, but that is not without its own problems.