Difference between revisions of "DS Technical Architecture FAQ"

From LinnDocs
Jump to: navigation, search
Line 13: Line 13:
 
=== What's inside a DS ===
 
=== What's 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.
+
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 [[http://www.rtems.com|RTEMS]] [[http://en.wikipedia.org/wiki/Real-time_operating_system|RTOS]]
+
The ppc runs an OS built on top of the open source [http://www.rtems.com rtems] [http://en.wikipedia.org/wiki/Real-time_operating_system rtos]
  
 
== Communicating with the DS ==
 
== Communicating with the DS ==

Revision as of 13:41, 8 September 2008

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's 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 rtos

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: 

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 it's renderer format (music or video). 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. This link may also be interesting: http://oss.linn.co.uk/trac/wiki/UPnPNonConformance

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 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. You can find information about the additional services provided by the DS' at http://oss.linn.co.uk/trac/wiki/LinnMediaService

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.