http://wiki.openhome.org/mediawiki/index.php?feed=atom&target=Joshh&title=Special%3AContributionsOpenHome - User contributions [en]2026-05-22T04:21:33ZFrom OpenHomeMediaWiki 1.16.2http://wiki.openhome.org/wiki/Av:Developer:ProductServiceAv:Developer:ProductService2013-06-13T08:31:47Z<p>Joshh: /* ProductRoom */</p>
<hr />
<div>= Architectural Overview =<br />
The Product service contains a summary of a single product’s capabilities. Control points should begin their interaction with an av.openhome device by searching for the Product service. Presence of various other services can be inferred from the sources and attributes this reports.<br />
<br />
= Actions =<br />
== Sources ==<br />
The set of available sources does not vary at run-time (although some source attributes may change). There is always a single source active. Only the active source will play audio or report state updates.<br />
=== SourceCount ===<br />
Query the value of the (read-only) SourceCount state variable.<br />
=== SetSourceIndex ===<br />
Set the currently active source. The value specified is zero-based and used to index into the source list returned by the SourceXml action / state variable.<br />
=== SetSourceIndexByName ===<br />
Set the currently active source. The value specified is matched against the Type attributes from the SourceXml action / state variable.<br />
=== SourceXml ===<br />
Query the value of the SourceXml state variable.<br />
=== SourceXmlChangeCount ===<br />
Query how often the SourceXml state variable has been updated. This action can be polled by clients that don’t support eventing. Whenever the value returned increases, the SourceXml has been updated so should be queried again.<br />
<br />
== Network Presentation ==<br />
=== Attributes ===<br />
Return the value of the Attributes state variable.<br />
<br />
=== Manufacturer ===<br />
Return the values of the ManufacturerName, ManufacturerInfo, ManufacturerUrl, ManufacturerImageUri state variables. All are read-only so the values returned will not vary at runtime.<br />
=== Model ===<br />
Return the values of the ModelName, ModelInfo, ModelUrl, ModelImageUri state variables. All are read-only so the values returned will not vary at runtime.<br />
=== Product ===<br />
Return the values of the ProductRoom, ProductName, ProductInfo, ProductUrl, ProductImageUri state variables.<br />
<br />
== Standby ==<br />
=== Standby ===<br />
Return the value of the Standby state variable.<br />
=== SetStandby ===<br />
Set the value of the Standby state variable.<br />
The SetStandby action provides a means of setting the current standby state of the product.<br />
<br />
= State Variables =<br />
== Sources ==<br />
=== SourceCount ===<br />
The number of available sources. Read-only.<br />
=== SourceIndex ===<br />
The index of the currently active source. This is zero-based so will be in the range [0..SourceCount-1]<br />
=== SourceXml ===<br />
Returns a summary of all sources in the form<br />
<br />
<syntaxhighlight lang="xml"><br />
<SourceList><br />
<Source><br />
<Name>[user name for source]</Name><br />
<Type>[system name for source. Read-only]</Type><br />
<Visible>[Boolean. Whether control points should display source]</Visible><br />
</sourcetag><br />
</SourceList><br />
</syntaxhighlight><br />
<br />
== Network Presentation ==<br />
=== Attributes ===<br />
Space delimited set of values. Each value guarantees the availability of a service or resource, saving a control point for searching for each of these in turn. Supported values for attributes include<br />
- Info – the av.openhome.org:Info:1 service is available<br />
- Time – the av.openhome.org:Time:1 service is available<br />
- Volume – the av.openhome.org:Volume:1 service is available<br />
- Sender - the av.openhome.org:Sender:1 service is available<br />
- App:Config=[link] – web UI for device configuration is available at the url [link]<br />
=== ManufacturerImageUri ===<br />
Uri for manufacturer’s logo. Read-only.<br />
=== ManufacturerInfo ===<br />
Manufacturer information. Read-only<br />
=== ManufacturerName ===<br />
Manufacturer name. Read-only.<br />
=== ManufacturerUrl ===<br />
URL for manufacturer web site. Read only.<br />
=== ModelImageUri ===<br />
Uri for model’s icon. Read-only.<br />
=== ModelInfo ===<br />
Model information. Read-only.<br />
=== ModelName ===<br />
Model name. Read-only.<br />
=== ModelUrl ===<br />
URL for model web site. Read-only.<br />
=== ProductImageUri ===<br />
Uri for product image. Read-only.<br />
<br />
=== ProductInfo ===<br />
Product information. Read-only.<br />
=== ProductName ===<br />
User-visible product name. By default this is set to ModelName.<br />
Note that the UPnP friendly name is derived by combining this with Room name in the form Room : Name<br />
=== ProductRoom ===<br />
The name of the room where the Product is located. Set to “Main Room” by default.<br />
ProductRoom is used to group the Product with other related Products in the same physical room (e.g. a source with a pre-amp). Products which are physically linked must always share the same ProductRoom name.<br />
<br />
=== ProductUrl ===<br />
URL for product web site. This may be the UPnP presentation page.<br />
<br />
== Standby ==<br />
=== Standby ===<br />
The standby state of a product (true => standby enabled)<br />
<br />
= Product Service Description (XML) =<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="utf-8"?><br />
<scpd xmlns="urn:schemas-upnp-org:service-1-0"><br />
<specVersion><br />
<major>1</major><br />
<minor>0</minor><br />
</specVersion><br />
<actionList><br />
<action><br />
<name>Manufacturer</name><br />
<argumentList><br />
<argument><br />
<name>Name</name><br />
<direction>out</direction><br />
<relatedStateVariable>ManufacturerName</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Info</name><br />
<direction>out</direction><br />
<relatedStateVariable>ManufacturerInfo</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Url</name><br />
<direction>out</direction><br />
<relatedStateVariable>ManufacturerUrl</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>ImageUri</name><br />
<direction>out</direction><br />
<relatedStateVariable>ManufacturerImageUri</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Model</name><br />
<argumentList><br />
<argument><br />
<name>Name</name><br />
<direction>out</direction><br />
<relatedStateVariable>ModelName</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Info</name><br />
<direction>out</direction><br />
<relatedStateVariable>ModelInfo</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Url</name><br />
<direction>out</direction><br />
<relatedStateVariable>ModelUrl</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>ImageUri</name><br />
<direction>out</direction><br />
<relatedStateVariable>ModelImageUri</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Product</name><br />
<argumentList><br />
<argument><br />
<name>Room</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProductRoom</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Name</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProductName</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Info</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProductInfo</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Url</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProductUrl</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>ImageUri</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProductImageUri</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Standby</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Standby</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SetStandby</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Standby</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SourceCount</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceCount</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SourceXml</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceXml</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SourceIndex</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceIndex</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SetSourceIndex</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>SourceIndex</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SetSourceIndexByName</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>SourceName</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Source</name><br />
<argumentList><br />
<argument><br />
<name>Index</name><br />
<direction>in</direction><br />
<relatedStateVariable>SourceIndex</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>SystemName</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceName</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Type</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceType</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Name</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceName</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Visible</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceVisible</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Attributes</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Attributes</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SourceXmlChangeCount</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceXmlChangeCount</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
</actionList><br />
<serviceStateTable><br />
<stateVariable sendEvents="yes"><br />
<name>ManufacturerName</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ManufacturerInfo</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ManufacturerUrl</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ManufacturerImageUri</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ModelName</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ModelInfo</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ModelUrl</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ModelImageUri</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProductRoom</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProductName</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProductInfo</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProductUrl</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProductImageUri</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Standby</name><br />
<dataType>boolean</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>SourceIndex</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>SourceCount</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>SourceXml</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Attributes</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>SourceXmlChangeCount</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>SourceType</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>SourceName</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>SourceVisible</name><br />
<dataType>boolean</dataType><br />
</stateVariable><br />
</serviceStateTable><br />
</scpd><br />
</syntaxhighlight></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:ProductServiceAv:Developer:ProductService2013-06-13T08:30:46Z<p>Joshh: /* ProductImageUri */</p>
<hr />
<div>= Architectural Overview =<br />
The Product service contains a summary of a single product’s capabilities. Control points should begin their interaction with an av.openhome device by searching for the Product service. Presence of various other services can be inferred from the sources and attributes this reports.<br />
<br />
= Actions =<br />
== Sources ==<br />
The set of available sources does not vary at run-time (although some source attributes may change). There is always a single source active. Only the active source will play audio or report state updates.<br />
=== SourceCount ===<br />
Query the value of the (read-only) SourceCount state variable.<br />
=== SetSourceIndex ===<br />
Set the currently active source. The value specified is zero-based and used to index into the source list returned by the SourceXml action / state variable.<br />
=== SetSourceIndexByName ===<br />
Set the currently active source. The value specified is matched against the Type attributes from the SourceXml action / state variable.<br />
=== SourceXml ===<br />
Query the value of the SourceXml state variable.<br />
=== SourceXmlChangeCount ===<br />
Query how often the SourceXml state variable has been updated. This action can be polled by clients that don’t support eventing. Whenever the value returned increases, the SourceXml has been updated so should be queried again.<br />
<br />
== Network Presentation ==<br />
=== Attributes ===<br />
Return the value of the Attributes state variable.<br />
<br />
=== Manufacturer ===<br />
Return the values of the ManufacturerName, ManufacturerInfo, ManufacturerUrl, ManufacturerImageUri state variables. All are read-only so the values returned will not vary at runtime.<br />
=== Model ===<br />
Return the values of the ModelName, ModelInfo, ModelUrl, ModelImageUri state variables. All are read-only so the values returned will not vary at runtime.<br />
=== Product ===<br />
Return the values of the ProductRoom, ProductName, ProductInfo, ProductUrl, ProductImageUri state variables.<br />
<br />
== Standby ==<br />
=== Standby ===<br />
Return the value of the Standby state variable.<br />
=== SetStandby ===<br />
Set the value of the Standby state variable.<br />
The SetStandby action provides a means of setting the current standby state of the product.<br />
<br />
= State Variables =<br />
== Sources ==<br />
=== SourceCount ===<br />
The number of available sources. Read-only.<br />
=== SourceIndex ===<br />
The index of the currently active source. This is zero-based so will be in the range [0..SourceCount-1]<br />
=== SourceXml ===<br />
Returns a summary of all sources in the form<br />
<br />
<syntaxhighlight lang="xml"><br />
<SourceList><br />
<Source><br />
<Name>[user name for source]</Name><br />
<Type>[system name for source. Read-only]</Type><br />
<Visible>[Boolean. Whether control points should display source]</Visible><br />
</sourcetag><br />
</SourceList><br />
</syntaxhighlight><br />
<br />
== Network Presentation ==<br />
=== Attributes ===<br />
Space delimited set of values. Each value guarantees the availability of a service or resource, saving a control point for searching for each of these in turn. Supported values for attributes include<br />
- Info – the av.openhome.org:Info:1 service is available<br />
- Time – the av.openhome.org:Time:1 service is available<br />
- Volume – the av.openhome.org:Volume:1 service is available<br />
- Sender - the av.openhome.org:Sender:1 service is available<br />
- App:Config=[link] – web UI for device configuration is available at the url [link]<br />
=== ManufacturerImageUri ===<br />
Uri for manufacturer’s logo. Read-only.<br />
=== ManufacturerInfo ===<br />
Manufacturer information. Read-only<br />
=== ManufacturerName ===<br />
Manufacturer name. Read-only.<br />
=== ManufacturerUrl ===<br />
URL for manufacturer web site. Read only.<br />
=== ModelImageUri ===<br />
Uri for model’s icon. Read-only.<br />
=== ModelInfo ===<br />
Model information. Read-only.<br />
=== ModelName ===<br />
Model name. Read-only.<br />
=== ModelUrl ===<br />
URL for model web site. Read-only.<br />
=== ProductImageUri ===<br />
Uri for product image. Read-only.<br />
<br />
=== ProductInfo ===<br />
Product information. Read-only.<br />
=== ProductName ===<br />
User-visible product name. By default this is set to ModelName.<br />
Note that the UPnP friendly name is derived by combining this with Room name in the form Room : Name<br />
=== ProductRoom ===<br />
The name of the room where the Product is located. Set to “Main Room” by default.<br />
ProductRoom is used to group the Product with other related Products in the same physical room (e.g. a source with a pre-amp). Products which are physically linked must always share the same ProductRoom name. Room is set to Main Room by default.<br />
=== ProductUrl ===<br />
URL for product web site. This may be the UPnP presentation page.<br />
<br />
== Standby ==<br />
=== Standby ===<br />
The standby state of a product (true => standby enabled)<br />
<br />
= Product Service Description (XML) =<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="utf-8"?><br />
<scpd xmlns="urn:schemas-upnp-org:service-1-0"><br />
<specVersion><br />
<major>1</major><br />
<minor>0</minor><br />
</specVersion><br />
<actionList><br />
<action><br />
<name>Manufacturer</name><br />
<argumentList><br />
<argument><br />
<name>Name</name><br />
<direction>out</direction><br />
<relatedStateVariable>ManufacturerName</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Info</name><br />
<direction>out</direction><br />
<relatedStateVariable>ManufacturerInfo</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Url</name><br />
<direction>out</direction><br />
<relatedStateVariable>ManufacturerUrl</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>ImageUri</name><br />
<direction>out</direction><br />
<relatedStateVariable>ManufacturerImageUri</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Model</name><br />
<argumentList><br />
<argument><br />
<name>Name</name><br />
<direction>out</direction><br />
<relatedStateVariable>ModelName</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Info</name><br />
<direction>out</direction><br />
<relatedStateVariable>ModelInfo</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Url</name><br />
<direction>out</direction><br />
<relatedStateVariable>ModelUrl</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>ImageUri</name><br />
<direction>out</direction><br />
<relatedStateVariable>ModelImageUri</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Product</name><br />
<argumentList><br />
<argument><br />
<name>Room</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProductRoom</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Name</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProductName</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Info</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProductInfo</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Url</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProductUrl</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>ImageUri</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProductImageUri</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Standby</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Standby</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SetStandby</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Standby</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SourceCount</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceCount</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SourceXml</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceXml</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SourceIndex</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceIndex</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SetSourceIndex</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>SourceIndex</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SetSourceIndexByName</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>SourceName</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Source</name><br />
<argumentList><br />
<argument><br />
<name>Index</name><br />
<direction>in</direction><br />
<relatedStateVariable>SourceIndex</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>SystemName</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceName</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Type</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceType</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Name</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceName</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Visible</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceVisible</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Attributes</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Attributes</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SourceXmlChangeCount</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceXmlChangeCount</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
</actionList><br />
<serviceStateTable><br />
<stateVariable sendEvents="yes"><br />
<name>ManufacturerName</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ManufacturerInfo</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ManufacturerUrl</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ManufacturerImageUri</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ModelName</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ModelInfo</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ModelUrl</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ModelImageUri</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProductRoom</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProductName</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProductInfo</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProductUrl</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProductImageUri</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Standby</name><br />
<dataType>boolean</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>SourceIndex</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>SourceCount</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>SourceXml</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Attributes</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>SourceXmlChangeCount</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>SourceType</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>SourceName</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>SourceVisible</name><br />
<dataType>boolean</dataType><br />
</stateVariable><br />
</serviceStateTable><br />
</scpd><br />
</syntaxhighlight></div>Joshhhttp://wiki.openhome.org/wiki/OhMediaOhMedia2011-12-15T21:08:44Z<p>Joshh: /* ohProduct and ohTopology */</p>
<hr />
<div>= ohMedia Overview =<br />
<br />
ohMedia is an open standard that allows the seamless interaction of media within your home.<br />
<br />
ohMedia's high level design is influenced by the UPnP AV standard (UAV). UAV correctly modelled media in the home as the interaction between 3 types of devices: Control Points, Media Renderers, and Media Servers.<br />
<<picture>><br />
This model correctly identified the potential presence of an arbitrary number of each of these devices. However, the Media Server specification, and in particular the Media Renderer specification is deeply flawed. The next section explains those flaws and outlines how ohMedia fixes them.<br />
<br />
= Flaws in the UPnP AV Standard =<br />
<br />
== Problem 1: No support for gap-less audio ==<br />
<br />
The UPnP AV media renderer specification is technically able to support gap-less audio though the AV Transport service actions, setAVTRansportURI and setNextAVTransportURI. However, the UPnP forum chose to make the setNextAVTransportURI action optional. This meant that no, or very few, media renderer manufacturers chose to support the action, which in turn, meant that no control points have added support for gap-less audio. So the real world situation is that UPnP AV has no support for gap-less audio.<br />
<br />
== Problem 2: No support for a user's playlist to continue playing when a control point is turned off ==<br />
<br />
The UPnP AV media renderer specification only allows for a media renderer to store a maximum of two URIs, but, as previously discussed, the real world maximum is in fact only a single URI. This means that in order for a media renderer to play a user created playlist the control point has to be continually monitoring the media renderer. When the media renderer indicates that it has finished playing the current URI the control point then has to set the next URI. If the control point is turned off and not monitoring the media renderer then the media renderer will not be informed of the next URI and playback will stop.<br />
<br />
== Problem 3: No support for multiple control points ==<br />
<br />
The UPnP AV media renderer specification caters for the case where a user wants multiple control points to show the metadata that is associated with the currently playing URI. However when it comes to controlling a media renderer from multiple control points the standard quickly shows it inadequacies.<br />
<br />
The main problems comes from the fact that the media renderer only holds a URI for the currently playing URI. This means that only the control point that the user used to create a playlist has knowledge about the playlist. As described earlier, because this control point holds the user's playlist it is actually controlling the flow of URIs to the media renderer. What happens if the same user adds tracks to a different control point? At this point two control points are trying to control the flow of different URIs to the media renderer. At this point the whole system fails to operate as the user expects.<br />
<br />
When a user creates a playlist on their control point and starts playback on a UPnP AV media renderer the renderer only holds the currently playing URI. When the renderer finishes the current URI the control point provides the renderer with next URI. If the control point is turned off at the point when the renderer finishes playing the current URI the renderer will stop playback.<br />
<br />
With the control point controlling the flow of URIs to the media renderer the UPnP AV media renderer specification violates the 3 box model separation where the control point should, without any intervention, enable content to flow between the media server and media renderer.<br />
<br />
== Problem 4: No concept of a Hi-Fi system comprising of more than one product or a home comprising of more than one Hi-Fi system ==<br />
<br />
A modern home can have one or more Hi-Fi systems of which each Hi-Fi system can comprise of one or more products connected together, e.g. a media player and a pre-amp.<br />
<br />
The UPnP AV standard assumes a single box which is made up of a single source and possibly a volume control. The standard has no way of representing a system that is made up of several different boxes connected together, e.g. a media renderer connected into a pre-amp. Taking the example of a media renderer connected to a pre-amp, without the ability to represent the different boxes and how they are connected it is impossible, using the UPnP AV standard, to select the input on the pre-amp that the media renderer is connected to when the user selects the media renderer in a control point.<br />
<br />
== Problem 5: Media's URI changing when media server rebuilds its database ==<br />
<br />
The UPnP AV media server specification does not have a requirement for media servers to present a piece of media to the network with the same URI. This has resulted in media server implementations that change media URIs when a user changes their media collection. This results in unexpected behaviour for the user. For example, a user plays some media on their renderer. The user then modifies their media collection which results in the media server rebuilding its database. The user then presses play on their renderer to only hear nothing (the URI is now no longer valid) or worse some different piece of media (the URI now represents some different media).<br />
<br />
= ohMeida Solutions =<br />
The ohMedia standard has been designed to solve all the problems described above.<br />
<br />
The first three problems are solved through the [[#ohPlaylist|ohPlaylist]] service specification.<br />
<br />
Problem 4 is solved through the [[#ohProduct_and_ohTopology|ohProduct service specification and the ohTopology algorithm]].<br />
<br />
Problem 5 is solved through the [[#Server|ohMedia server]] specification.<br />
<br />
The ohMedia standard goes further and adds the [[#ohSongcast|ohSongcast]] standard. [[#ohSongcast|ohSongcast]] provides the ability to synchronise playback between products, commonly referred to as party mode. However in general [[#ohSongcast|ohSongcast]] provides the ability for a product to stream its audio over a standard home network and for any product that supports the [[#ohSongcast|ohSongcast]] receiver specification to receive the audio and play it back.<br />
<br />
= How it works =<br />
<br />
ohMedia models media in the home through the interaction of 3 types of device, Control Points, Media Players and Media Servers.<br />
<br />
<<picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve>><br />
<br />
The Control Point first browses the Media Server to locate the desired media. The Control Point then tells the Media Player to play the selected media and finally Media Player retrieves the media from the Media Server.<br />
<br />
== ohProduct and ohTopology ==<br />
<br />
ohMedia models a home as a number Hi-Fi systems, which are located in rooms.<br />
<br />
ohMedia models a Hi-Fi system as a hierarchical tree of products, where a product is defined as a single physical box that is located in a room, has a unique name within the room, has one output and any number of sources.<br />
<br />
<<diagram of a product with multi-in, one out>><br />
<br />
A product is modelled through the ohProduct service specification.<br />
<br />
When a control point wants to construct a model of a user's home they use the ohTopology algorithm. The ohTopology algorithm is as follows,<br />
<br />
#discover all the products in the home that have an ohProduct service<br />
#group the discovered products based on the room they are in<br />
#create a hierarchical tree structure by matching source names to product names<br />
#discover source functionality based on source type<br />
#discover additional functionality based on product attributes<br />
<br />
e.g. if we had two products, a pre-amp and a media player, which were connected together then both their ohProduct services would return the same room name and one of the source names returned by the pre-amp's ohProduct service would be the same as the product name returned by the media renderer's ohProduct service.<br />
<br />
<<picture of example>><br />
<br />
== Sources ==<br />
<br />
ohMedia defines four source types,<br />
<br />
#Playlist – product supports on device playlists<br />
#Radio – product supports internet radio with presets<br />
#Receiver – product supports receiving ohSongcast broadcasts<br />
#UpnpAv – product also implements the UPnP AV media renderer specification<br />
<br />
If a source type is not one of the types above an ohMedia control point will be able to switch to the source but will treat the source as a non controllable external input e.g. Analogue, TOS or HDMI.<br />
<br />
== Attributes ==<br />
<br />
ohMedia defines three attributes,<br />
<br />
#Volume – product supports volume control<br />
#Info – product supports providing information about the currently playing media<br />
#Time – product supports providing the current time within the currently playing media<br />
#Sender – product supports ohSongcast broadcasting<br />
<br />
== ohPlaylist ==<br />
<br />
The ohPlaylist specification has been designed to allow gap-less audio, playlists to proceed without the intervention of a control point and to function correctly under the manipulation of multiple control points.<br />
<br />
The ohPlaylist is a list of media associated with a unique ID. Media is defined by its URI and metadata. A control point is required to keep in memory the current list of playlist IDs. This list of IDs can then be used to list the media in the order of play, obtain the metadata and manipulate the list.<br />
<br />
The Playlist service provides the API that allow control points to manipulate, keep track of playlist changes and control playback.<br />
<br />
== ohSongcast ==<br />
<br />
<<to do>><br />
<br />
== Server ==<br />
<br />
<<to do>><br />
<br />
= Developers =<br />
<br />
If you are interested in ohMedia development, more information can be found [[Av:Developer|here]]</div>Joshhhttp://wiki.openhome.org/wiki/Oh:OverviewOh:Overview2011-12-15T21:07:46Z<p>Joshh: /* ohOs */</p>
<hr />
<div>The adoption of broadband internet and the proliferation of wifi-connected devices such as smartphones, web tablets, and netbooks has resulted in the computer network becoming a standard feature of the modern home. But there are a number of ways in which the modern family is yet to realize the full benefit of this home networking revolution.<br />
<br />
OpenHome is an independent body committed to redressing this through the design, implementation, and promotion of open standards. It stimulates innovation by transforming the home network into a rich environment for applications that fit with the way families live.<br />
<br />
= [[OhOs|ohOs]] =<br />
<br />
Users of personal computers and portable computing devices are familiar with the process of installing applications according to their own personal tastes or needs. But there are a number of applications that do not fit neatly into this pattern of deployment and use.<br />
<br />
The OpenHome Operating System, [[OhOs|ohOs]], fills this gap by providing a place to deploy software that is for use not only by a single individual but by all family members. And in doing so [[OhOs|ohOs]] opens the way for applications that:<br />
<blockquote><br />
* Allow the family to access and control a wide range of domestic appliances, such as lights, media players, and security cameras, organized from the perspective of the home as a whole.<br />
<br />
[Illustration of someone controlling lights using an iPad-like device]<br />
<br />
* Allow the family to view, and maintain structured information that is most meaningful in the context of the home, such as shared calendars, family address books, and photo albums.<br />
<br />
[Illustration of someone putting car servicing appointment into a family calendar using an iPad-like device]<br />
<br />
* Provide opportunities for creativity and fun for the family as a whole. <br />
<br />
[Illustration of family members each with their own iPad or iPhone jointly doing a crossword?]<br />
<br />
* Provide rich, user-friendly control over otherwise technically challenging networking facilities, such as parental control over internet access.<br />
<br />
[Illustration of a child unable to access the internet from their bedroom at night with happy care-free parents downstairs?]<br />
<br />
* Provide a trusted domain for archiving and messaging that keeps all information safely within the boundary of the domestic network.<br />
<br />
[Illustration of someone storing the code for a safe using an iPhone-like device?]<br />
</blockquote><br />
[[OhOs|ohOs]] achieves this by providing lightweight, always-on, networked computing for applications that can be installed from a readily accessible app store and used by any web-browser-enabled device.<br />
<br />
= [[OhMedia|ohMedia]] =<br />
<br />
Networked audio was arguably the first popular application for the networked home. The idea of storing a digital music collection on a central server and playing it on a range of networked audio devices has begun to take hold. Add to this the idea that choosing and controlling that music should be possible from wirelessly networked mobile devices and we have the basic architecture for home audio that was first outlined in the UPnP AV specification.<br />
<br />
[Illustration of networked audio home with music being enjoyed in different rooms and being controlled by iPad-like devices]<br />
<br />
However, UPnP AV contains serious oversights and flaws that prevent it from delivering an appealing networked music experience throughout the home.<br />
<br />
OpenHome addresses this by creating a set of open extensions to UPnP AV that were designed from the ground up from a home-centered perspective. Furthermore, OpenHome goes beyond UPnP AV by developing completely new network standards, such as Songcast, which deliver additional home-centered functionality. More details are avaliable [[OhMedia|here]].<br />
<br />
= [[Oh:Downloads|ohDownload]] =<br />
<br />
OpenHome maintains that open standards are best developed in parallel with real-world implementations of those standards. This ensures that they are both fit for use and immediately available for use.<br />
<br />
[Possible illustration of person in ivory tower dreaming of ridiculous fantastical car, and person on the ground dreaming of really good car]<br />
<br />
In pursuit of this principle, OpenHome publishes an ever-growing suite of high quality, open software that is actively maintained and already proven in successful commercial products.<br />
<br />
This includes:<br />
<br />
* [[OhNet|ohNet]], the OpenHome networking stack, which facilitates the creation of service-oriented, SOAP-based networking software with inherent UPnP support.<br />
<br />
* [[OhSongcast|ohSongcast]], which implements OpenHome standards for one-to-many transmission of audio around a home network<br />
<br />
* [[OhNetworkMonitor|ohNetworkMonitor]], which provides facilities for troubleshooting home networking problems<br />
<br />
OpenHome software may be downloaded [[Oh:Downloads|here]].<br />
<br />
__NOTOC__</div>Joshhhttp://wiki.openhome.org/wiki/Oh:OverviewOh:Overview2011-12-15T21:05:56Z<p>Joshh: /* ohOs */</p>
<hr />
<div>The adoption of broadband internet and the proliferation of wifi-connected devices such as smartphones, web tablets, and netbooks has resulted in the computer network becoming a standard feature of the modern home. But there are a number of ways in which the modern family is yet to realize the full benefit of this home networking revolution.<br />
<br />
OpenHome is an independent body committed to redressing this through the design, implementation, and promotion of open standards. It stimulates innovation by transforming the home network into a rich environment for applications that fit with the way families live.<br />
<br />
= [[OhOs|ohOs]] =<br />
<br />
Users of personal computers and portable computing devices are familiar with the process of installing applications according to their own personal tastes or needs. But there are a number of applications that do not fit neatly into this pattern of deployment and use.<br />
<br />
The OpenHome Operating System, [[OhOs|ohOs]], fills this gap by providing a place to deploy software that is for use not only by a single individual but by all family members. And in doing so [[OhOs|ohOs]] opens the way for applications that:<br />
<br />
; Allow the family to access and control a wide range of domestic appliances, such as lights, media players, and security cameras, organized from the perspective of the home as a whole.<br />
<br />
[Illustration of someone controlling lights using an iPad-like device]<br />
<br />
; Allow the family to view, and maintain structured information that is most meaningful in the context of the home, such as shared calendars, family address books, and photo albums.<br />
<br />
[Illustration of someone putting car servicing appointment into a family calendar using an iPad-like device]<br />
<br />
# Provide opportunities for creativity and fun for the family as a whole. <br />
<br />
[Illustration of family members each with their own iPad or iPhone jointly doing a crossword?]<br />
<br />
# Provide rich, user-friendly control over otherwise technically challenging networking facilities, such as parental control over internet access.<br />
<br />
[Illustration of a child unable to access the internet from their bedroom at night with happy care-free parents downstairs?]<br />
<br />
# Provide a trusted domain for archiving and messaging that keeps all information safely within the boundary of the domestic network.<br />
<br />
[Illustration of someone storing the code for a safe using an iPhone-like device?]<br />
<br />
[[OhOs|ohOs]] achieves this by providing lightweight, always-on, networked computing for applications that can be installed from a readily accessible app store and used by any web-browser-enabled device.<br />
<br />
= [[OhMedia|ohMedia]] =<br />
<br />
Networked audio was arguably the first popular application for the networked home. The idea of storing a digital music collection on a central server and playing it on a range of networked audio devices has begun to take hold. Add to this the idea that choosing and controlling that music should be possible from wirelessly networked mobile devices and we have the basic architecture for home audio that was first outlined in the UPnP AV specification.<br />
<br />
[Illustration of networked audio home with music being enjoyed in different rooms and being controlled by iPad-like devices]<br />
<br />
However, UPnP AV contains serious oversights and flaws that prevent it from delivering an appealing networked music experience throughout the home.<br />
<br />
OpenHome addresses this by creating a set of open extensions to UPnP AV that were designed from the ground up from a home-centered perspective. Furthermore, OpenHome goes beyond UPnP AV by developing completely new network standards, such as Songcast, which deliver additional home-centered functionality. More details are avaliable [[OhMedia|here]].<br />
<br />
= [[Oh:Downloads|ohDownload]] =<br />
<br />
OpenHome maintains that open standards are best developed in parallel with real-world implementations of those standards. This ensures that they are both fit for use and immediately available for use.<br />
<br />
[Possible illustration of person in ivory tower dreaming of ridiculous fantastical car, and person on the ground dreaming of really good car]<br />
<br />
In pursuit of this principle, OpenHome publishes an ever-growing suite of high quality, open software that is actively maintained and already proven in successful commercial products.<br />
<br />
This includes:<br />
<br />
* [[OhNet|ohNet]], the OpenHome networking stack, which facilitates the creation of service-oriented, SOAP-based networking software with inherent UPnP support.<br />
<br />
* [[OhSongcast|ohSongcast]], which implements OpenHome standards for one-to-many transmission of audio around a home network<br />
<br />
* [[OhNetworkMonitor|ohNetworkMonitor]], which provides facilities for troubleshooting home networking problems<br />
<br />
OpenHome software may be downloaded [[Oh:Downloads|here]].<br />
<br />
__NOTOC__</div>Joshhhttp://wiki.openhome.org/wiki/Oh:OverviewOh:Overview2011-12-15T21:05:42Z<p>Joshh: /* ohOs */</p>
<hr />
<div>The adoption of broadband internet and the proliferation of wifi-connected devices such as smartphones, web tablets, and netbooks has resulted in the computer network becoming a standard feature of the modern home. But there are a number of ways in which the modern family is yet to realize the full benefit of this home networking revolution.<br />
<br />
OpenHome is an independent body committed to redressing this through the design, implementation, and promotion of open standards. It stimulates innovation by transforming the home network into a rich environment for applications that fit with the way families live.<br />
<br />
= [[OhOs|ohOs]] =<br />
<br />
Users of personal computers and portable computing devices are familiar with the process of installing applications according to their own personal tastes or needs. But there are a number of applications that do not fit neatly into this pattern of deployment and use.<br />
<br />
The OpenHome Operating System, [[OhOs|ohOs]], fills this gap by providing a place to deploy software that is for use not only by a single individual but by all family members. And in doing so [[OhOs|ohOs]] opens the way for applications that:<br />
<br />
# Allow the family to access and control a wide range of domestic appliances, such as lights, media players, and security cameras, organized from the perspective of the home as a whole.<br />
<br />
[Illustration of someone controlling lights using an iPad-like device]<br />
<br />
# Allow the family to view, and maintain structured information that is most meaningful in the context of the home, such as shared calendars, family address books, and photo albums.<br />
<br />
[Illustration of someone putting car servicing appointment into a family calendar using an iPad-like device]<br />
<br />
# Provide opportunities for creativity and fun for the family as a whole. <br />
<br />
[Illustration of family members each with their own iPad or iPhone jointly doing a crossword?]<br />
<br />
# Provide rich, user-friendly control over otherwise technically challenging networking facilities, such as parental control over internet access.<br />
<br />
[Illustration of a child unable to access the internet from their bedroom at night with happy care-free parents downstairs?]<br />
<br />
# Provide a trusted domain for archiving and messaging that keeps all information safely within the boundary of the domestic network.<br />
<br />
[Illustration of someone storing the code for a safe using an iPhone-like device?]<br />
<br />
[[OhOs|ohOs]] achieves this by providing lightweight, always-on, networked computing for applications that can be installed from a readily accessible app store and used by any web-browser-enabled device.<br />
<br />
= [[OhMedia|ohMedia]] =<br />
<br />
Networked audio was arguably the first popular application for the networked home. The idea of storing a digital music collection on a central server and playing it on a range of networked audio devices has begun to take hold. Add to this the idea that choosing and controlling that music should be possible from wirelessly networked mobile devices and we have the basic architecture for home audio that was first outlined in the UPnP AV specification.<br />
<br />
[Illustration of networked audio home with music being enjoyed in different rooms and being controlled by iPad-like devices]<br />
<br />
However, UPnP AV contains serious oversights and flaws that prevent it from delivering an appealing networked music experience throughout the home.<br />
<br />
OpenHome addresses this by creating a set of open extensions to UPnP AV that were designed from the ground up from a home-centered perspective. Furthermore, OpenHome goes beyond UPnP AV by developing completely new network standards, such as Songcast, which deliver additional home-centered functionality. More details are avaliable [[OhMedia|here]].<br />
<br />
= [[Oh:Downloads|ohDownload]] =<br />
<br />
OpenHome maintains that open standards are best developed in parallel with real-world implementations of those standards. This ensures that they are both fit for use and immediately available for use.<br />
<br />
[Possible illustration of person in ivory tower dreaming of ridiculous fantastical car, and person on the ground dreaming of really good car]<br />
<br />
In pursuit of this principle, OpenHome publishes an ever-growing suite of high quality, open software that is actively maintained and already proven in successful commercial products.<br />
<br />
This includes:<br />
<br />
* [[OhNet|ohNet]], the OpenHome networking stack, which facilitates the creation of service-oriented, SOAP-based networking software with inherent UPnP support.<br />
<br />
* [[OhSongcast|ohSongcast]], which implements OpenHome standards for one-to-many transmission of audio around a home network<br />
<br />
* [[OhNetworkMonitor|ohNetworkMonitor]], which provides facilities for troubleshooting home networking problems<br />
<br />
OpenHome software may be downloaded [[Oh:Downloads|here]].<br />
<br />
__NOTOC__</div>Joshhhttp://wiki.openhome.org/wiki/OhMediaOhMedia2011-12-15T21:04:12Z<p>Joshh: /* Attributes */</p>
<hr />
<div>= ohMedia Overview =<br />
<br />
ohMedia is an open standard that allows the seamless interaction of media within your home.<br />
<br />
ohMedia's high level design is influenced by the UPnP AV standard (UAV). UAV correctly modelled media in the home as the interaction between 3 types of devices: Control Points, Media Renderers, and Media Servers.<br />
<<picture>><br />
This model correctly identified the potential presence of an arbitrary number of each of these devices. However, the Media Server specification, and in particular the Media Renderer specification is deeply flawed. The next section explains those flaws and outlines how ohMedia fixes them.<br />
<br />
= Flaws in the UPnP AV Standard =<br />
<br />
== Problem 1: No support for gap-less audio ==<br />
<br />
The UPnP AV media renderer specification is technically able to support gap-less audio though the AV Transport service actions, setAVTRansportURI and setNextAVTransportURI. However, the UPnP forum chose to make the setNextAVTransportURI action optional. This meant that no, or very few, media renderer manufacturers chose to support the action, which in turn, meant that no control points have added support for gap-less audio. So the real world situation is that UPnP AV has no support for gap-less audio.<br />
<br />
== Problem 2: No support for a user's playlist to continue playing when a control point is turned off ==<br />
<br />
The UPnP AV media renderer specification only allows for a media renderer to store a maximum of two URIs, but, as previously discussed, the real world maximum is in fact only a single URI. This means that in order for a media renderer to play a user created playlist the control point has to be continually monitoring the media renderer. When the media renderer indicates that it has finished playing the current URI the control point then has to set the next URI. If the control point is turned off and not monitoring the media renderer then the media renderer will not be informed of the next URI and playback will stop.<br />
<br />
== Problem 3: No support for multiple control points ==<br />
<br />
The UPnP AV media renderer specification caters for the case where a user wants multiple control points to show the metadata that is associated with the currently playing URI. However when it comes to controlling a media renderer from multiple control points the standard quickly shows it inadequacies.<br />
<br />
The main problems comes from the fact that the media renderer only holds a URI for the currently playing URI. This means that only the control point that the user used to create a playlist has knowledge about the playlist. As described earlier, because this control point holds the user's playlist it is actually controlling the flow of URIs to the media renderer. What happens if the same user adds tracks to a different control point? At this point two control points are trying to control the flow of different URIs to the media renderer. At this point the whole system fails to operate as the user expects.<br />
<br />
When a user creates a playlist on their control point and starts playback on a UPnP AV media renderer the renderer only holds the currently playing URI. When the renderer finishes the current URI the control point provides the renderer with next URI. If the control point is turned off at the point when the renderer finishes playing the current URI the renderer will stop playback.<br />
<br />
With the control point controlling the flow of URIs to the media renderer the UPnP AV media renderer specification violates the 3 box model separation where the control point should, without any intervention, enable content to flow between the media server and media renderer.<br />
<br />
== Problem 4: No concept of a Hi-Fi system comprising of more than one product or a home comprising of more than one Hi-Fi system ==<br />
<br />
A modern home can have one or more Hi-Fi systems of which each Hi-Fi system can comprise of one or more products connected together, e.g. a media player and a pre-amp.<br />
<br />
The UPnP AV standard assumes a single box which is made up of a single source and possibly a volume control. The standard has no way of representing a system that is made up of several different boxes connected together, e.g. a media renderer connected into a pre-amp. Taking the example of a media renderer connected to a pre-amp, without the ability to represent the different boxes and how they are connected it is impossible, using the UPnP AV standard, to select the input on the pre-amp that the media renderer is connected to when the user selects the media renderer in a control point.<br />
<br />
== Problem 5: Media's URI changing when media server rebuilds its database ==<br />
<br />
The UPnP AV media server specification does not have a requirement for media servers to present a piece of media to the network with the same URI. This has resulted in media server implementations that change media URIs when a user changes their media collection. This results in unexpected behaviour for the user. For example, a user plays some media on their renderer. The user then modifies their media collection which results in the media server rebuilding its database. The user then presses play on their renderer to only hear nothing (the URI is now no longer valid) or worse some different piece of media (the URI now represents some different media).<br />
<br />
= ohMeida Solutions =<br />
The ohMedia standard has been designed to solve all the problems described above.<br />
<br />
The first three problems are solved through the [[#ohPlaylist|ohPlaylist]] service specification.<br />
<br />
Problem 4 is solved through the [[#ohProduct_and_ohTopology|ohProduct service specification and the ohTopology algorithm]].<br />
<br />
Problem 5 is solved through the [[#Server|ohMedia server]] specification.<br />
<br />
The ohMedia standard goes further and adds the [[#ohSongcast|ohSongcast]] standard. [[#ohSongcast|ohSongcast]] provides the ability to synchronise playback between products, commonly referred to as party mode. However in general [[#ohSongcast|ohSongcast]] provides the ability for a product to stream its audio over a standard home network and for any product that supports the [[#ohSongcast|ohSongcast]] receiver specification to receive the audio and play it back.<br />
<br />
= How it works =<br />
<br />
ohMedia models media in the home through the interaction of 3 types of device, Control Points, Media Players and Media Servers.<br />
<br />
<<picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve>><br />
<br />
The Control Point first browses the Media Server to locate the desired media. The Control Point then tells the Media Player to play the selected media and finally Media Player retrieves the media from the Media Server.<br />
<br />
== ohProduct and ohTopology ==<br />
<br />
ohMedia models a home as a number Hi-Fi systems, which are located in rooms.<br />
<br />
ohMedia models a Hi-Fi system as a hierarchical tree of products, where a product is defined as a single physical box that is located in a room, has a unique name within the room, has one output and any number of sources.<br />
<br />
<<diagram of a product with multi-in, one out>><br />
<br />
A product is modelled through the ohProduct service specification.<br />
<br />
When a control point wants to construct a model of a user's home they use the ohTopology algorithm. The ohTopology algorithm is as follows,<br />
<br />
1.discover all the products in the home that have an ohProduct service<br />
2.group the discovered products based on the room they are in<br />
3.create a hierarchical tree structure by matching source names to product names<br />
4.discover source functionality based on source type<br />
5.discover additional functionality based on product attributes<br />
<br />
e.g. if we had two products, a pre-amp and a media player, which were connected together then both their ohProduct services would return the same room name and one of the source names returned by the pre-amp's ohProduct service would be the same as the product name returned by the media renderer's ohProduct service.<br />
<br />
<<picture of example>><br />
<br />
== Sources ==<br />
<br />
ohMedia defines four source types,<br />
<br />
#Playlist – product supports on device playlists<br />
#Radio – product supports internet radio with presets<br />
#Receiver – product supports receiving ohSongcast broadcasts<br />
#UpnpAv – product also implements the UPnP AV media renderer specification<br />
<br />
If a source type is not one of the types above an ohMedia control point will be able to switch to the source but will treat the source as a non controllable external input e.g. Analogue, TOS or HDMI.<br />
<br />
== Attributes ==<br />
<br />
ohMedia defines three attributes,<br />
<br />
#Volume – product supports volume control<br />
#Info – product supports providing information about the currently playing media<br />
#Time – product supports providing the current time within the currently playing media<br />
#Sender – product supports ohSongcast broadcasting<br />
<br />
== ohPlaylist ==<br />
<br />
The ohPlaylist specification has been designed to allow gap-less audio, playlists to proceed without the intervention of a control point and to function correctly under the manipulation of multiple control points.<br />
<br />
The ohPlaylist is a list of media associated with a unique ID. Media is defined by its URI and metadata. A control point is required to keep in memory the current list of playlist IDs. This list of IDs can then be used to list the media in the order of play, obtain the metadata and manipulate the list.<br />
<br />
The Playlist service provides the API that allow control points to manipulate, keep track of playlist changes and control playback.<br />
<br />
== ohSongcast ==<br />
<br />
<<to do>><br />
<br />
== Server ==<br />
<br />
<<to do>><br />
<br />
= Developers =<br />
<br />
If you are interested in ohMedia development, more information can be found [[Av:Developer|here]]</div>Joshhhttp://wiki.openhome.org/wiki/OhMediaOhMedia2011-12-15T21:03:54Z<p>Joshh: /* Sources */</p>
<hr />
<div>= ohMedia Overview =<br />
<br />
ohMedia is an open standard that allows the seamless interaction of media within your home.<br />
<br />
ohMedia's high level design is influenced by the UPnP AV standard (UAV). UAV correctly modelled media in the home as the interaction between 3 types of devices: Control Points, Media Renderers, and Media Servers.<br />
<<picture>><br />
This model correctly identified the potential presence of an arbitrary number of each of these devices. However, the Media Server specification, and in particular the Media Renderer specification is deeply flawed. The next section explains those flaws and outlines how ohMedia fixes them.<br />
<br />
= Flaws in the UPnP AV Standard =<br />
<br />
== Problem 1: No support for gap-less audio ==<br />
<br />
The UPnP AV media renderer specification is technically able to support gap-less audio though the AV Transport service actions, setAVTRansportURI and setNextAVTransportURI. However, the UPnP forum chose to make the setNextAVTransportURI action optional. This meant that no, or very few, media renderer manufacturers chose to support the action, which in turn, meant that no control points have added support for gap-less audio. So the real world situation is that UPnP AV has no support for gap-less audio.<br />
<br />
== Problem 2: No support for a user's playlist to continue playing when a control point is turned off ==<br />
<br />
The UPnP AV media renderer specification only allows for a media renderer to store a maximum of two URIs, but, as previously discussed, the real world maximum is in fact only a single URI. This means that in order for a media renderer to play a user created playlist the control point has to be continually monitoring the media renderer. When the media renderer indicates that it has finished playing the current URI the control point then has to set the next URI. If the control point is turned off and not monitoring the media renderer then the media renderer will not be informed of the next URI and playback will stop.<br />
<br />
== Problem 3: No support for multiple control points ==<br />
<br />
The UPnP AV media renderer specification caters for the case where a user wants multiple control points to show the metadata that is associated with the currently playing URI. However when it comes to controlling a media renderer from multiple control points the standard quickly shows it inadequacies.<br />
<br />
The main problems comes from the fact that the media renderer only holds a URI for the currently playing URI. This means that only the control point that the user used to create a playlist has knowledge about the playlist. As described earlier, because this control point holds the user's playlist it is actually controlling the flow of URIs to the media renderer. What happens if the same user adds tracks to a different control point? At this point two control points are trying to control the flow of different URIs to the media renderer. At this point the whole system fails to operate as the user expects.<br />
<br />
When a user creates a playlist on their control point and starts playback on a UPnP AV media renderer the renderer only holds the currently playing URI. When the renderer finishes the current URI the control point provides the renderer with next URI. If the control point is turned off at the point when the renderer finishes playing the current URI the renderer will stop playback.<br />
<br />
With the control point controlling the flow of URIs to the media renderer the UPnP AV media renderer specification violates the 3 box model separation where the control point should, without any intervention, enable content to flow between the media server and media renderer.<br />
<br />
== Problem 4: No concept of a Hi-Fi system comprising of more than one product or a home comprising of more than one Hi-Fi system ==<br />
<br />
A modern home can have one or more Hi-Fi systems of which each Hi-Fi system can comprise of one or more products connected together, e.g. a media player and a pre-amp.<br />
<br />
The UPnP AV standard assumes a single box which is made up of a single source and possibly a volume control. The standard has no way of representing a system that is made up of several different boxes connected together, e.g. a media renderer connected into a pre-amp. Taking the example of a media renderer connected to a pre-amp, without the ability to represent the different boxes and how they are connected it is impossible, using the UPnP AV standard, to select the input on the pre-amp that the media renderer is connected to when the user selects the media renderer in a control point.<br />
<br />
== Problem 5: Media's URI changing when media server rebuilds its database ==<br />
<br />
The UPnP AV media server specification does not have a requirement for media servers to present a piece of media to the network with the same URI. This has resulted in media server implementations that change media URIs when a user changes their media collection. This results in unexpected behaviour for the user. For example, a user plays some media on their renderer. The user then modifies their media collection which results in the media server rebuilding its database. The user then presses play on their renderer to only hear nothing (the URI is now no longer valid) or worse some different piece of media (the URI now represents some different media).<br />
<br />
= ohMeida Solutions =<br />
The ohMedia standard has been designed to solve all the problems described above.<br />
<br />
The first three problems are solved through the [[#ohPlaylist|ohPlaylist]] service specification.<br />
<br />
Problem 4 is solved through the [[#ohProduct_and_ohTopology|ohProduct service specification and the ohTopology algorithm]].<br />
<br />
Problem 5 is solved through the [[#Server|ohMedia server]] specification.<br />
<br />
The ohMedia standard goes further and adds the [[#ohSongcast|ohSongcast]] standard. [[#ohSongcast|ohSongcast]] provides the ability to synchronise playback between products, commonly referred to as party mode. However in general [[#ohSongcast|ohSongcast]] provides the ability for a product to stream its audio over a standard home network and for any product that supports the [[#ohSongcast|ohSongcast]] receiver specification to receive the audio and play it back.<br />
<br />
= How it works =<br />
<br />
ohMedia models media in the home through the interaction of 3 types of device, Control Points, Media Players and Media Servers.<br />
<br />
<<picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve>><br />
<br />
The Control Point first browses the Media Server to locate the desired media. The Control Point then tells the Media Player to play the selected media and finally Media Player retrieves the media from the Media Server.<br />
<br />
== ohProduct and ohTopology ==<br />
<br />
ohMedia models a home as a number Hi-Fi systems, which are located in rooms.<br />
<br />
ohMedia models a Hi-Fi system as a hierarchical tree of products, where a product is defined as a single physical box that is located in a room, has a unique name within the room, has one output and any number of sources.<br />
<br />
<<diagram of a product with multi-in, one out>><br />
<br />
A product is modelled through the ohProduct service specification.<br />
<br />
When a control point wants to construct a model of a user's home they use the ohTopology algorithm. The ohTopology algorithm is as follows,<br />
<br />
1.discover all the products in the home that have an ohProduct service<br />
2.group the discovered products based on the room they are in<br />
3.create a hierarchical tree structure by matching source names to product names<br />
4.discover source functionality based on source type<br />
5.discover additional functionality based on product attributes<br />
<br />
e.g. if we had two products, a pre-amp and a media player, which were connected together then both their ohProduct services would return the same room name and one of the source names returned by the pre-amp's ohProduct service would be the same as the product name returned by the media renderer's ohProduct service.<br />
<br />
<<picture of example>><br />
<br />
== Sources ==<br />
<br />
ohMedia defines four source types,<br />
<br />
#Playlist – product supports on device playlists<br />
#Radio – product supports internet radio with presets<br />
#Receiver – product supports receiving ohSongcast broadcasts<br />
#UpnpAv – product also implements the UPnP AV media renderer specification<br />
<br />
If a source type is not one of the types above an ohMedia control point will be able to switch to the source but will treat the source as a non controllable external input e.g. Analogue, TOS or HDMI.<br />
<br />
== Attributes ==<br />
<br />
ohMedia defines three attributes,<br />
<br />
1.Volume – product supports volume control<br />
2.Info – product supports providing information about the currently playing media<br />
3.Time – product supports providing the current time within the currently playing media<br />
4.Sender – product supports ohSongcast broadcasting<br />
<br />
== ohPlaylist ==<br />
<br />
The ohPlaylist specification has been designed to allow gap-less audio, playlists to proceed without the intervention of a control point and to function correctly under the manipulation of multiple control points.<br />
<br />
The ohPlaylist is a list of media associated with a unique ID. Media is defined by its URI and metadata. A control point is required to keep in memory the current list of playlist IDs. This list of IDs can then be used to list the media in the order of play, obtain the metadata and manipulate the list.<br />
<br />
The Playlist service provides the API that allow control points to manipulate, keep track of playlist changes and control playback.<br />
<br />
== ohSongcast ==<br />
<br />
<<to do>><br />
<br />
== Server ==<br />
<br />
<<to do>><br />
<br />
= Developers =<br />
<br />
If you are interested in ohMedia development, more information can be found [[Av:Developer|here]]</div>Joshhhttp://wiki.openhome.org/wiki/OhMediaOhMedia2011-12-15T21:03:01Z<p>Joshh: /* Server */</p>
<hr />
<div>= ohMedia Overview =<br />
<br />
ohMedia is an open standard that allows the seamless interaction of media within your home.<br />
<br />
ohMedia's high level design is influenced by the UPnP AV standard (UAV). UAV correctly modelled media in the home as the interaction between 3 types of devices: Control Points, Media Renderers, and Media Servers.<br />
<<picture>><br />
This model correctly identified the potential presence of an arbitrary number of each of these devices. However, the Media Server specification, and in particular the Media Renderer specification is deeply flawed. The next section explains those flaws and outlines how ohMedia fixes them.<br />
<br />
= Flaws in the UPnP AV Standard =<br />
<br />
== Problem 1: No support for gap-less audio ==<br />
<br />
The UPnP AV media renderer specification is technically able to support gap-less audio though the AV Transport service actions, setAVTRansportURI and setNextAVTransportURI. However, the UPnP forum chose to make the setNextAVTransportURI action optional. This meant that no, or very few, media renderer manufacturers chose to support the action, which in turn, meant that no control points have added support for gap-less audio. So the real world situation is that UPnP AV has no support for gap-less audio.<br />
<br />
== Problem 2: No support for a user's playlist to continue playing when a control point is turned off ==<br />
<br />
The UPnP AV media renderer specification only allows for a media renderer to store a maximum of two URIs, but, as previously discussed, the real world maximum is in fact only a single URI. This means that in order for a media renderer to play a user created playlist the control point has to be continually monitoring the media renderer. When the media renderer indicates that it has finished playing the current URI the control point then has to set the next URI. If the control point is turned off and not monitoring the media renderer then the media renderer will not be informed of the next URI and playback will stop.<br />
<br />
== Problem 3: No support for multiple control points ==<br />
<br />
The UPnP AV media renderer specification caters for the case where a user wants multiple control points to show the metadata that is associated with the currently playing URI. However when it comes to controlling a media renderer from multiple control points the standard quickly shows it inadequacies.<br />
<br />
The main problems comes from the fact that the media renderer only holds a URI for the currently playing URI. This means that only the control point that the user used to create a playlist has knowledge about the playlist. As described earlier, because this control point holds the user's playlist it is actually controlling the flow of URIs to the media renderer. What happens if the same user adds tracks to a different control point? At this point two control points are trying to control the flow of different URIs to the media renderer. At this point the whole system fails to operate as the user expects.<br />
<br />
When a user creates a playlist on their control point and starts playback on a UPnP AV media renderer the renderer only holds the currently playing URI. When the renderer finishes the current URI the control point provides the renderer with next URI. If the control point is turned off at the point when the renderer finishes playing the current URI the renderer will stop playback.<br />
<br />
With the control point controlling the flow of URIs to the media renderer the UPnP AV media renderer specification violates the 3 box model separation where the control point should, without any intervention, enable content to flow between the media server and media renderer.<br />
<br />
== Problem 4: No concept of a Hi-Fi system comprising of more than one product or a home comprising of more than one Hi-Fi system ==<br />
<br />
A modern home can have one or more Hi-Fi systems of which each Hi-Fi system can comprise of one or more products connected together, e.g. a media player and a pre-amp.<br />
<br />
The UPnP AV standard assumes a single box which is made up of a single source and possibly a volume control. The standard has no way of representing a system that is made up of several different boxes connected together, e.g. a media renderer connected into a pre-amp. Taking the example of a media renderer connected to a pre-amp, without the ability to represent the different boxes and how they are connected it is impossible, using the UPnP AV standard, to select the input on the pre-amp that the media renderer is connected to when the user selects the media renderer in a control point.<br />
<br />
== Problem 5: Media's URI changing when media server rebuilds its database ==<br />
<br />
The UPnP AV media server specification does not have a requirement for media servers to present a piece of media to the network with the same URI. This has resulted in media server implementations that change media URIs when a user changes their media collection. This results in unexpected behaviour for the user. For example, a user plays some media on their renderer. The user then modifies their media collection which results in the media server rebuilding its database. The user then presses play on their renderer to only hear nothing (the URI is now no longer valid) or worse some different piece of media (the URI now represents some different media).<br />
<br />
= ohMeida Solutions =<br />
The ohMedia standard has been designed to solve all the problems described above.<br />
<br />
The first three problems are solved through the [[#ohPlaylist|ohPlaylist]] service specification.<br />
<br />
Problem 4 is solved through the [[#ohProduct_and_ohTopology|ohProduct service specification and the ohTopology algorithm]].<br />
<br />
Problem 5 is solved through the [[#Server|ohMedia server]] specification.<br />
<br />
The ohMedia standard goes further and adds the [[#ohSongcast|ohSongcast]] standard. [[#ohSongcast|ohSongcast]] provides the ability to synchronise playback between products, commonly referred to as party mode. However in general [[#ohSongcast|ohSongcast]] provides the ability for a product to stream its audio over a standard home network and for any product that supports the [[#ohSongcast|ohSongcast]] receiver specification to receive the audio and play it back.<br />
<br />
= How it works =<br />
<br />
ohMedia models media in the home through the interaction of 3 types of device, Control Points, Media Players and Media Servers.<br />
<br />
<<picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve>><br />
<br />
The Control Point first browses the Media Server to locate the desired media. The Control Point then tells the Media Player to play the selected media and finally Media Player retrieves the media from the Media Server.<br />
<br />
== ohProduct and ohTopology ==<br />
<br />
ohMedia models a home as a number Hi-Fi systems, which are located in rooms.<br />
<br />
ohMedia models a Hi-Fi system as a hierarchical tree of products, where a product is defined as a single physical box that is located in a room, has a unique name within the room, has one output and any number of sources.<br />
<br />
<<diagram of a product with multi-in, one out>><br />
<br />
A product is modelled through the ohProduct service specification.<br />
<br />
When a control point wants to construct a model of a user's home they use the ohTopology algorithm. The ohTopology algorithm is as follows,<br />
<br />
1.discover all the products in the home that have an ohProduct service<br />
2.group the discovered products based on the room they are in<br />
3.create a hierarchical tree structure by matching source names to product names<br />
4.discover source functionality based on source type<br />
5.discover additional functionality based on product attributes<br />
<br />
e.g. if we had two products, a pre-amp and a media player, which were connected together then both their ohProduct services would return the same room name and one of the source names returned by the pre-amp's ohProduct service would be the same as the product name returned by the media renderer's ohProduct service.<br />
<br />
<<picture of example>><br />
<br />
== Sources ==<br />
<br />
ohMedia defines four source types,<br />
<br />
1.Playlist – product supports on device playlists<br />
2.Radio – product supports internet radio with presets<br />
3.Receiver – product supports receiving ohSongcast broadcasts<br />
4.UpnpAv – product also implements the UPnP AV media renderer specification<br />
<br />
If a source type is not one of the types above an ohMedia control point will be able to switch to the source but will treat the source as a non controllable external input e.g. Analogue, TOS or HDMI.<br />
<br />
== Attributes ==<br />
<br />
ohMedia defines three attributes,<br />
<br />
1.Volume – product supports volume control<br />
2.Info – product supports providing information about the currently playing media<br />
3.Time – product supports providing the current time within the currently playing media<br />
4.Sender – product supports ohSongcast broadcasting<br />
<br />
== ohPlaylist ==<br />
<br />
The ohPlaylist specification has been designed to allow gap-less audio, playlists to proceed without the intervention of a control point and to function correctly under the manipulation of multiple control points.<br />
<br />
The ohPlaylist is a list of media associated with a unique ID. Media is defined by its URI and metadata. A control point is required to keep in memory the current list of playlist IDs. This list of IDs can then be used to list the media in the order of play, obtain the metadata and manipulate the list.<br />
<br />
The Playlist service provides the API that allow control points to manipulate, keep track of playlist changes and control playback.<br />
<br />
== ohSongcast ==<br />
<br />
<<to do>><br />
<br />
== Server ==<br />
<br />
<<to do>><br />
<br />
= Developers =<br />
<br />
If you are interested in ohMedia development, more information can be found [[Av:Developer|here]]</div>Joshhhttp://wiki.openhome.org/wiki/OhMediaOhMedia2011-12-15T21:01:01Z<p>Joshh: /* ohMeida Solutions */</p>
<hr />
<div>= ohMedia Overview =<br />
<br />
ohMedia is an open standard that allows the seamless interaction of media within your home.<br />
<br />
ohMedia's high level design is influenced by the UPnP AV standard (UAV). UAV correctly modelled media in the home as the interaction between 3 types of devices: Control Points, Media Renderers, and Media Servers.<br />
<<picture>><br />
This model correctly identified the potential presence of an arbitrary number of each of these devices. However, the Media Server specification, and in particular the Media Renderer specification is deeply flawed. The next section explains those flaws and outlines how ohMedia fixes them.<br />
<br />
= Flaws in the UPnP AV Standard =<br />
<br />
== Problem 1: No support for gap-less audio ==<br />
<br />
The UPnP AV media renderer specification is technically able to support gap-less audio though the AV Transport service actions, setAVTRansportURI and setNextAVTransportURI. However, the UPnP forum chose to make the setNextAVTransportURI action optional. This meant that no, or very few, media renderer manufacturers chose to support the action, which in turn, meant that no control points have added support for gap-less audio. So the real world situation is that UPnP AV has no support for gap-less audio.<br />
<br />
== Problem 2: No support for a user's playlist to continue playing when a control point is turned off ==<br />
<br />
The UPnP AV media renderer specification only allows for a media renderer to store a maximum of two URIs, but, as previously discussed, the real world maximum is in fact only a single URI. This means that in order for a media renderer to play a user created playlist the control point has to be continually monitoring the media renderer. When the media renderer indicates that it has finished playing the current URI the control point then has to set the next URI. If the control point is turned off and not monitoring the media renderer then the media renderer will not be informed of the next URI and playback will stop.<br />
<br />
== Problem 3: No support for multiple control points ==<br />
<br />
The UPnP AV media renderer specification caters for the case where a user wants multiple control points to show the metadata that is associated with the currently playing URI. However when it comes to controlling a media renderer from multiple control points the standard quickly shows it inadequacies.<br />
<br />
The main problems comes from the fact that the media renderer only holds a URI for the currently playing URI. This means that only the control point that the user used to create a playlist has knowledge about the playlist. As described earlier, because this control point holds the user's playlist it is actually controlling the flow of URIs to the media renderer. What happens if the same user adds tracks to a different control point? At this point two control points are trying to control the flow of different URIs to the media renderer. At this point the whole system fails to operate as the user expects.<br />
<br />
When a user creates a playlist on their control point and starts playback on a UPnP AV media renderer the renderer only holds the currently playing URI. When the renderer finishes the current URI the control point provides the renderer with next URI. If the control point is turned off at the point when the renderer finishes playing the current URI the renderer will stop playback.<br />
<br />
With the control point controlling the flow of URIs to the media renderer the UPnP AV media renderer specification violates the 3 box model separation where the control point should, without any intervention, enable content to flow between the media server and media renderer.<br />
<br />
== Problem 4: No concept of a Hi-Fi system comprising of more than one product or a home comprising of more than one Hi-Fi system ==<br />
<br />
A modern home can have one or more Hi-Fi systems of which each Hi-Fi system can comprise of one or more products connected together, e.g. a media player and a pre-amp.<br />
<br />
The UPnP AV standard assumes a single box which is made up of a single source and possibly a volume control. The standard has no way of representing a system that is made up of several different boxes connected together, e.g. a media renderer connected into a pre-amp. Taking the example of a media renderer connected to a pre-amp, without the ability to represent the different boxes and how they are connected it is impossible, using the UPnP AV standard, to select the input on the pre-amp that the media renderer is connected to when the user selects the media renderer in a control point.<br />
<br />
== Problem 5: Media's URI changing when media server rebuilds its database ==<br />
<br />
The UPnP AV media server specification does not have a requirement for media servers to present a piece of media to the network with the same URI. This has resulted in media server implementations that change media URIs when a user changes their media collection. This results in unexpected behaviour for the user. For example, a user plays some media on their renderer. The user then modifies their media collection which results in the media server rebuilding its database. The user then presses play on their renderer to only hear nothing (the URI is now no longer valid) or worse some different piece of media (the URI now represents some different media).<br />
<br />
= ohMeida Solutions =<br />
The ohMedia standard has been designed to solve all the problems described above.<br />
<br />
The first three problems are solved through the [[#ohPlaylist|ohPlaylist]] service specification.<br />
<br />
Problem 4 is solved through the [[#ohProduct_and_ohTopology|ohProduct service specification and the ohTopology algorithm]].<br />
<br />
Problem 5 is solved through the [[#Server|ohMedia server]] specification.<br />
<br />
The ohMedia standard goes further and adds the [[#ohSongcast|ohSongcast]] standard. [[#ohSongcast|ohSongcast]] provides the ability to synchronise playback between products, commonly referred to as party mode. However in general [[#ohSongcast|ohSongcast]] provides the ability for a product to stream its audio over a standard home network and for any product that supports the [[#ohSongcast|ohSongcast]] receiver specification to receive the audio and play it back.<br />
<br />
= How it works =<br />
<br />
ohMedia models media in the home through the interaction of 3 types of device, Control Points, Media Players and Media Servers.<br />
<br />
<<picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve>><br />
<br />
The Control Point first browses the Media Server to locate the desired media. The Control Point then tells the Media Player to play the selected media and finally Media Player retrieves the media from the Media Server.<br />
<br />
== ohProduct and ohTopology ==<br />
<br />
ohMedia models a home as a number Hi-Fi systems, which are located in rooms.<br />
<br />
ohMedia models a Hi-Fi system as a hierarchical tree of products, where a product is defined as a single physical box that is located in a room, has a unique name within the room, has one output and any number of sources.<br />
<br />
<<diagram of a product with multi-in, one out>><br />
<br />
A product is modelled through the ohProduct service specification.<br />
<br />
When a control point wants to construct a model of a user's home they use the ohTopology algorithm. The ohTopology algorithm is as follows,<br />
<br />
1.discover all the products in the home that have an ohProduct service<br />
2.group the discovered products based on the room they are in<br />
3.create a hierarchical tree structure by matching source names to product names<br />
4.discover source functionality based on source type<br />
5.discover additional functionality based on product attributes<br />
<br />
e.g. if we had two products, a pre-amp and a media player, which were connected together then both their ohProduct services would return the same room name and one of the source names returned by the pre-amp's ohProduct service would be the same as the product name returned by the media renderer's ohProduct service.<br />
<br />
<<picture of example>><br />
<br />
== Sources ==<br />
<br />
ohMedia defines four source types,<br />
<br />
1.Playlist – product supports on device playlists<br />
2.Radio – product supports internet radio with presets<br />
3.Receiver – product supports receiving ohSongcast broadcasts<br />
4.UpnpAv – product also implements the UPnP AV media renderer specification<br />
<br />
If a source type is not one of the types above an ohMedia control point will be able to switch to the source but will treat the source as a non controllable external input e.g. Analogue, TOS or HDMI.<br />
<br />
== Attributes ==<br />
<br />
ohMedia defines three attributes,<br />
<br />
1.Volume – product supports volume control<br />
2.Info – product supports providing information about the currently playing media<br />
3.Time – product supports providing the current time within the currently playing media<br />
4.Sender – product supports ohSongcast broadcasting<br />
<br />
== ohPlaylist ==<br />
<br />
The ohPlaylist specification has been designed to allow gap-less audio, playlists to proceed without the intervention of a control point and to function correctly under the manipulation of multiple control points.<br />
<br />
The ohPlaylist is a list of media associated with a unique ID. Media is defined by its URI and metadata. A control point is required to keep in memory the current list of playlist IDs. This list of IDs can then be used to list the media in the order of play, obtain the metadata and manipulate the list.<br />
<br />
The Playlist service provides the API that allow control points to manipulate, keep track of playlist changes and control playback.<br />
<br />
== ohSongcast ==<br />
<br />
<<to do>><br />
<br />
== Server ==<br />
<br />
<<to do>></div>Joshhhttp://wiki.openhome.org/wiki/OhMediaOhMedia2011-12-15T21:00:14Z<p>Joshh: </p>
<hr />
<div>= ohMedia Overview =<br />
<br />
ohMedia is an open standard that allows the seamless interaction of media within your home.<br />
<br />
ohMedia's high level design is influenced by the UPnP AV standard (UAV). UAV correctly modelled media in the home as the interaction between 3 types of devices: Control Points, Media Renderers, and Media Servers.<br />
<<picture>><br />
This model correctly identified the potential presence of an arbitrary number of each of these devices. However, the Media Server specification, and in particular the Media Renderer specification is deeply flawed. The next section explains those flaws and outlines how ohMedia fixes them.<br />
<br />
= Flaws in the UPnP AV Standard =<br />
<br />
== Problem 1: No support for gap-less audio ==<br />
<br />
The UPnP AV media renderer specification is technically able to support gap-less audio though the AV Transport service actions, setAVTRansportURI and setNextAVTransportURI. However, the UPnP forum chose to make the setNextAVTransportURI action optional. This meant that no, or very few, media renderer manufacturers chose to support the action, which in turn, meant that no control points have added support for gap-less audio. So the real world situation is that UPnP AV has no support for gap-less audio.<br />
<br />
== Problem 2: No support for a user's playlist to continue playing when a control point is turned off ==<br />
<br />
The UPnP AV media renderer specification only allows for a media renderer to store a maximum of two URIs, but, as previously discussed, the real world maximum is in fact only a single URI. This means that in order for a media renderer to play a user created playlist the control point has to be continually monitoring the media renderer. When the media renderer indicates that it has finished playing the current URI the control point then has to set the next URI. If the control point is turned off and not monitoring the media renderer then the media renderer will not be informed of the next URI and playback will stop.<br />
<br />
== Problem 3: No support for multiple control points ==<br />
<br />
The UPnP AV media renderer specification caters for the case where a user wants multiple control points to show the metadata that is associated with the currently playing URI. However when it comes to controlling a media renderer from multiple control points the standard quickly shows it inadequacies.<br />
<br />
The main problems comes from the fact that the media renderer only holds a URI for the currently playing URI. This means that only the control point that the user used to create a playlist has knowledge about the playlist. As described earlier, because this control point holds the user's playlist it is actually controlling the flow of URIs to the media renderer. What happens if the same user adds tracks to a different control point? At this point two control points are trying to control the flow of different URIs to the media renderer. At this point the whole system fails to operate as the user expects.<br />
<br />
When a user creates a playlist on their control point and starts playback on a UPnP AV media renderer the renderer only holds the currently playing URI. When the renderer finishes the current URI the control point provides the renderer with next URI. If the control point is turned off at the point when the renderer finishes playing the current URI the renderer will stop playback.<br />
<br />
With the control point controlling the flow of URIs to the media renderer the UPnP AV media renderer specification violates the 3 box model separation where the control point should, without any intervention, enable content to flow between the media server and media renderer.<br />
<br />
== Problem 4: No concept of a Hi-Fi system comprising of more than one product or a home comprising of more than one Hi-Fi system ==<br />
<br />
A modern home can have one or more Hi-Fi systems of which each Hi-Fi system can comprise of one or more products connected together, e.g. a media player and a pre-amp.<br />
<br />
The UPnP AV standard assumes a single box which is made up of a single source and possibly a volume control. The standard has no way of representing a system that is made up of several different boxes connected together, e.g. a media renderer connected into a pre-amp. Taking the example of a media renderer connected to a pre-amp, without the ability to represent the different boxes and how they are connected it is impossible, using the UPnP AV standard, to select the input on the pre-amp that the media renderer is connected to when the user selects the media renderer in a control point.<br />
<br />
== Problem 5: Media's URI changing when media server rebuilds its database ==<br />
<br />
The UPnP AV media server specification does not have a requirement for media servers to present a piece of media to the network with the same URI. This has resulted in media server implementations that change media URIs when a user changes their media collection. This results in unexpected behaviour for the user. For example, a user plays some media on their renderer. The user then modifies their media collection which results in the media server rebuilding its database. The user then presses play on their renderer to only hear nothing (the URI is now no longer valid) or worse some different piece of media (the URI now represents some different media).<br />
<br />
= ohMeida Solutions =<br />
The ohMedia standard has been designed to solve all the problems described above.<br />
<br />
The first three problems are solved through the [[#ohPlaylist|ohPlaylist]] service specification.<br />
<br />
Problem 4 is solved through the [[#ohProduct_and_ohTopology|ohProduct service specification and the ohTopology algorithm]].<br />
<br />
Problem 5 is solved through the [[#Server|ohMedia server]] specification.<br />
<br />
The ohMedia standard goes further and adds the [[#ohSongcast|ohSongcast]] standard. ohSongcast provides the ability to synchronise playback between products, commonly referred to as party mode. However in general ohSongcast provides the ability for a product to stream its audio over a standard home network and for any product that supports the ohSongcast receiver specification to receive the audio and play it back.<br />
<br />
= How it works =<br />
<br />
ohMedia models media in the home through the interaction of 3 types of device, Control Points, Media Players and Media Servers.<br />
<br />
<<picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve>><br />
<br />
The Control Point first browses the Media Server to locate the desired media. The Control Point then tells the Media Player to play the selected media and finally Media Player retrieves the media from the Media Server.<br />
<br />
== ohProduct and ohTopology ==<br />
<br />
ohMedia models a home as a number Hi-Fi systems, which are located in rooms.<br />
<br />
ohMedia models a Hi-Fi system as a hierarchical tree of products, where a product is defined as a single physical box that is located in a room, has a unique name within the room, has one output and any number of sources.<br />
<br />
<<diagram of a product with multi-in, one out>><br />
<br />
A product is modelled through the ohProduct service specification.<br />
<br />
When a control point wants to construct a model of a user's home they use the ohTopology algorithm. The ohTopology algorithm is as follows,<br />
<br />
1.discover all the products in the home that have an ohProduct service<br />
2.group the discovered products based on the room they are in<br />
3.create a hierarchical tree structure by matching source names to product names<br />
4.discover source functionality based on source type<br />
5.discover additional functionality based on product attributes<br />
<br />
e.g. if we had two products, a pre-amp and a media player, which were connected together then both their ohProduct services would return the same room name and one of the source names returned by the pre-amp's ohProduct service would be the same as the product name returned by the media renderer's ohProduct service.<br />
<br />
<<picture of example>><br />
<br />
== Sources ==<br />
<br />
ohMedia defines four source types,<br />
<br />
1.Playlist – product supports on device playlists<br />
2.Radio – product supports internet radio with presets<br />
3.Receiver – product supports receiving ohSongcast broadcasts<br />
4.UpnpAv – product also implements the UPnP AV media renderer specification<br />
<br />
If a source type is not one of the types above an ohMedia control point will be able to switch to the source but will treat the source as a non controllable external input e.g. Analogue, TOS or HDMI.<br />
<br />
== Attributes ==<br />
<br />
ohMedia defines three attributes,<br />
<br />
1.Volume – product supports volume control<br />
2.Info – product supports providing information about the currently playing media<br />
3.Time – product supports providing the current time within the currently playing media<br />
4.Sender – product supports ohSongcast broadcasting<br />
<br />
== ohPlaylist ==<br />
<br />
The ohPlaylist specification has been designed to allow gap-less audio, playlists to proceed without the intervention of a control point and to function correctly under the manipulation of multiple control points.<br />
<br />
The ohPlaylist is a list of media associated with a unique ID. Media is defined by its URI and metadata. A control point is required to keep in memory the current list of playlist IDs. This list of IDs can then be used to list the media in the order of play, obtain the metadata and manipulate the list.<br />
<br />
The Playlist service provides the API that allow control points to manipulate, keep track of playlist changes and control playback.<br />
<br />
== ohSongcast ==<br />
<br />
<<to do>><br />
<br />
== Server ==<br />
<br />
<<to do>></div>Joshhhttp://wiki.openhome.org/wiki/OhMediaOhMedia2011-12-15T20:57:32Z<p>Joshh: /* ohSongcast */</p>
<hr />
<div>= ohMedia Overview =<br />
<br />
ohMedia is an open standard that allows the seamless interaction of media within your home.<br />
<br />
ohMedia's high level design is influenced by the UPnP AV standard (UAV). UAV correctly modelled media in the home as the interaction between 3 types of devices: Control Points, Media Renderers, and Media Servers.<br />
<<picture>><br />
This model correctly identified the potential presence of an arbitrary number of each of these devices. However, the Media Server specification, and in particular the Media Renderer specification is deeply flawed. The next section explains those flaws and outlines how ohMedia fixes them.<br />
<br />
= Flaws in the UPnP AV Standard =<br />
<br />
== Problem 1: No support for gap-less audio ==<br />
<br />
The UPnP AV media renderer specification is technically able to support gap-less audio though the AV Transport service actions, setAVTRansportURI and setNextAVTransportURI. However, the UPnP forum chose to make the setNextAVTransportURI action optional. This meant that no, or very few, media renderer manufacturers chose to support the action, which in turn, meant that no control points have added support for gap-less audio. So the real world situation is that UPnP AV has no support for gap-less audio.<br />
<br />
== Problem 2: No support for a user's playlist to continue playing when a control point is turned off ==<br />
<br />
The UPnP AV media renderer specification only allows for a media renderer to store a maximum of two URIs, but, as previously discussed, the real world maximum is in fact only a single URI. This means that in order for a media renderer to play a user created playlist the control point has to be continually monitoring the media renderer. When the media renderer indicates that it has finished playing the current URI the control point then has to set the next URI. If the control point is turned off and not monitoring the media renderer then the media renderer will not be informed of the next URI and playback will stop.<br />
<br />
== Problem 3: No support for multiple control points ==<br />
<br />
The UPnP AV media renderer specification caters for the case where a user wants multiple control points to show the metadata that is associated with the currently playing URI. However when it comes to controlling a media renderer from multiple control points the standard quickly shows it inadequacies.<br />
<br />
The main problems comes from the fact that the media renderer only holds a URI for the currently playing URI. This means that only the control point that the user used to create a playlist has knowledge about the playlist. As described earlier, because this control point holds the user's playlist it is actually controlling the flow of URIs to the media renderer. What happens if the same user adds tracks to a different control point? At this point two control points are trying to control the flow of different URIs to the media renderer. At this point the whole system fails to operate as the user expects.<br />
<br />
When a user creates a playlist on their control point and starts playback on a UPnP AV media renderer the renderer only holds the currently playing URI. When the renderer finishes the current URI the control point provides the renderer with next URI. If the control point is turned off at the point when the renderer finishes playing the current URI the renderer will stop playback.<br />
<br />
With the control point controlling the flow of URIs to the media renderer the UPnP AV media renderer specification violates the 3 box model separation where the control point should, without any intervention, enable content to flow between the media server and media renderer.<br />
<br />
== Problem 4: No concept of a Hi-Fi system comprising of more than one product or a home comprising of more than one Hi-Fi system ==<br />
<br />
A modern home can have one or more Hi-Fi systems of which each Hi-Fi system can comprise of one or more products connected together, e.g. a media player and a pre-amp.<br />
<br />
The UPnP AV standard assumes a single box which is made up of a single source and possibly a volume control. The standard has no way of representing a system that is made up of several different boxes connected together, e.g. a media renderer connected into a pre-amp. Taking the example of a media renderer connected to a pre-amp, without the ability to represent the different boxes and how they are connected it is impossible, using the UPnP AV standard, to select the input on the pre-amp that the media renderer is connected to when the user selects the media renderer in a control point.<br />
<br />
== Problem 5: Media's URI changing when media server rebuilds its database ==<br />
<br />
The UPnP AV media server specification does not have a requirement for media servers to present a piece of media to the network with the same URI. This has resulted in media server implementations that change media URIs when a user changes their media collection. This results in unexpected behaviour for the user. For example, a user plays some media on their renderer. The user then modifies their media collection which results in the media server rebuilding its database. The user then presses play on their renderer to only hear nothing (the URI is now no longer valid) or worse some different piece of media (the URI now represents some different media).<br />
<br />
= ohMeida Solutions =<br />
The ohMedia standard has been designed to solve all the problems described above.<br />
<br />
The first three problems are solved through the [[#ohPlaylist|ohPlaylist]] service specification.<br />
<br />
Problem 4 is solved through the [[#ohProduct_and_ohTopology|ohProduct service specification and the ohTopology algorithm]].<br />
<br />
Problem 5 is solved through the ohMedia server specification. <<link to how it works>><br />
<br />
The ohMedia standard goes further and adds the ohSongcast standard. ohSongcast provides the ability to synchronise playback between products, commonly referred to as party mode. However in general ohSongcast provides the ability for a product to stream its audio over a standard home network and for any product that supports the ohSongcast receiver specification to receive the audio and play it back. <<link to how it works>><br />
<br />
= How it works =<br />
<br />
ohMedia models media in the home through the interaction of 3 types of device, Control Points, Media Players and Media Servers.<br />
<br />
<<picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve>><br />
<br />
The Control Point first browses the Media Server to locate the desired media. The Control Point then tells the Media Player to play the selected media and finally Media Player retrieves the media from the Media Server.<br />
<br />
== ohProduct and ohTopology ==<br />
<br />
ohMedia models a home as a number Hi-Fi systems, which are located in rooms.<br />
<br />
ohMedia models a Hi-Fi system as a hierarchical tree of products, where a product is defined as a single physical box that is located in a room, has a unique name within the room, has one output and any number of sources.<br />
<br />
<<diagram of a product with multi-in, one out>><br />
<br />
A product is modelled through the ohProduct service specification.<br />
<br />
When a control point wants to construct a model of a user's home they use the ohTopology algorithm. The ohTopology algorithm is as follows,<br />
<br />
1.discover all the products in the home that have an ohProduct service<br />
2.group the discovered products based on the room they are in<br />
3.create a hierarchical tree structure by matching source names to product names<br />
4.discover source functionality based on source type<br />
5.discover additional functionality based on product attributes<br />
<br />
e.g. if we had two products, a pre-amp and a media player, which were connected together then both their ohProduct services would return the same room name and one of the source names returned by the pre-amp's ohProduct service would be the same as the product name returned by the media renderer's ohProduct service.<br />
<br />
<<picture of example>><br />
<br />
== Sources ==<br />
<br />
ohMedia defines four source types,<br />
<br />
1.Playlist – product supports on device playlists<br />
2.Radio – product supports internet radio with presets<br />
3.Receiver – product supports receiving ohSongcast broadcasts<br />
4.UpnpAv – product also implements the UPnP AV media renderer specification<br />
<br />
If a source type is not one of the types above an ohMedia control point will be able to switch to the source but will treat the source as a non controllable external input e.g. Analogue, TOS or HDMI.<br />
<br />
== Attributes ==<br />
<br />
ohMedia defines three attributes,<br />
<br />
1.Volume – product supports volume control<br />
2.Info – product supports providing information about the currently playing media<br />
3.Time – product supports providing the current time within the currently playing media<br />
4.Sender – product supports ohSongcast broadcasting<br />
<br />
== ohPlaylist ==<br />
<br />
The ohPlaylist specification has been designed to allow gap-less audio, playlists to proceed without the intervention of a control point and to function correctly under the manipulation of multiple control points.<br />
<br />
The ohPlaylist is a list of media associated with a unique ID. Media is defined by its URI and metadata. A control point is required to keep in memory the current list of playlist IDs. This list of IDs can then be used to list the media in the order of play, obtain the metadata and manipulate the list.<br />
<br />
The Playlist service provides the API that allow control points to manipulate, keep track of playlist changes and control playback.<br />
<br />
== ohSongcast ==<br />
<br />
<<to do>><br />
<br />
== Server ==<br />
<br />
<<to do>><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
of either of these two concepts so a control point can only provide a user with a flat list of UPnP AV products in the home. Whilst this might work reasonably well for a user with a single UPnP AV product it is far from ideal when they have multiple UPnP AV products.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
In the UPnP AV system architecture the control point holds all the information about the sequence of URIs that a media renderer will play. When there are multiple control points on the network there is no way for them all to have a common understanding of what a media renderer's sequence of URIs is. This results in each control point having its own, conflicting, understanding of a media renderer's state and when the current URI stops playing it becomes a race between the control points to set what they each believe to be the next URI.<br />
<br />
<br />
<br />
<br />
<br />
<br />
Problem 4: No support for synchronised playback across products<br />
<br />
The UPnP AV standard does not provide any solution to being able to synchronise playback across products.<br />
<br />
<br />
The ohMedia standard solves this deficiency by storing the user created playlist on the media renderer. This means that an ohMedia media renderer can play a user created playlist without the need for a control point to be switched on.<br />
<br />
The ohMedia standard solves this deficiency by moving the state of a media renderer from the control point into the media renderer. This means that all control points can now share a common understanding of what a media renderer's current state is.<br />
<br />
The ohMedia standard solves this problem by storing the playlist on the media renderer. This allows the ohMedia media renderer can start playback of the next URI immediately after the current URI has finished playing.<br />
<br />
The ohMedia standard solves the deficiency with ohSongcast. ohSongcast is an open network protocol that allows audio synchronisation between products that implement the ohSongcast protocol.<br />
<br />
The ohMedia standard solves this deficiency through ohTopology. ohTopology defines how products are found on the network, how products are grouped together and how the grouped products are connected together.<br />
<br />
How It Works<br />
<br />
The ohMedia standard uses the same playback architecture as used in the UPnP AV standard. The architecture is commonly known as the 3 box model. The 3 boxes in the 3 box model are, Media Renderer, Media Server and Control Point. The three components each work together to perform the task of playing back media. The media server contains the content available to a user. The user interacts with the control point's user interface to search and select the desired content on the media server and then to select the media renderer to playback the desired content. Playback of the content is achieved by out of band communication between the media server and media renderer, the control point is no involved.</div>Joshhhttp://wiki.openhome.org/wiki/OhMediaOhMedia2011-12-15T20:56:04Z<p>Joshh: /* ohMeida Solutions */</p>
<hr />
<div>= ohMedia Overview =<br />
<br />
ohMedia is an open standard that allows the seamless interaction of media within your home.<br />
<br />
ohMedia's high level design is influenced by the UPnP AV standard (UAV). UAV correctly modelled media in the home as the interaction between 3 types of devices: Control Points, Media Renderers, and Media Servers.<br />
<<picture>><br />
This model correctly identified the potential presence of an arbitrary number of each of these devices. However, the Media Server specification, and in particular the Media Renderer specification is deeply flawed. The next section explains those flaws and outlines how ohMedia fixes them.<br />
<br />
= Flaws in the UPnP AV Standard =<br />
<br />
== Problem 1: No support for gap-less audio ==<br />
<br />
The UPnP AV media renderer specification is technically able to support gap-less audio though the AV Transport service actions, setAVTRansportURI and setNextAVTransportURI. However, the UPnP forum chose to make the setNextAVTransportURI action optional. This meant that no, or very few, media renderer manufacturers chose to support the action, which in turn, meant that no control points have added support for gap-less audio. So the real world situation is that UPnP AV has no support for gap-less audio.<br />
<br />
== Problem 2: No support for a user's playlist to continue playing when a control point is turned off ==<br />
<br />
The UPnP AV media renderer specification only allows for a media renderer to store a maximum of two URIs, but, as previously discussed, the real world maximum is in fact only a single URI. This means that in order for a media renderer to play a user created playlist the control point has to be continually monitoring the media renderer. When the media renderer indicates that it has finished playing the current URI the control point then has to set the next URI. If the control point is turned off and not monitoring the media renderer then the media renderer will not be informed of the next URI and playback will stop.<br />
<br />
== Problem 3: No support for multiple control points ==<br />
<br />
The UPnP AV media renderer specification caters for the case where a user wants multiple control points to show the metadata that is associated with the currently playing URI. However when it comes to controlling a media renderer from multiple control points the standard quickly shows it inadequacies.<br />
<br />
The main problems comes from the fact that the media renderer only holds a URI for the currently playing URI. This means that only the control point that the user used to create a playlist has knowledge about the playlist. As described earlier, because this control point holds the user's playlist it is actually controlling the flow of URIs to the media renderer. What happens if the same user adds tracks to a different control point? At this point two control points are trying to control the flow of different URIs to the media renderer. At this point the whole system fails to operate as the user expects.<br />
<br />
When a user creates a playlist on their control point and starts playback on a UPnP AV media renderer the renderer only holds the currently playing URI. When the renderer finishes the current URI the control point provides the renderer with next URI. If the control point is turned off at the point when the renderer finishes playing the current URI the renderer will stop playback.<br />
<br />
With the control point controlling the flow of URIs to the media renderer the UPnP AV media renderer specification violates the 3 box model separation where the control point should, without any intervention, enable content to flow between the media server and media renderer.<br />
<br />
== Problem 4: No concept of a Hi-Fi system comprising of more than one product or a home comprising of more than one Hi-Fi system ==<br />
<br />
A modern home can have one or more Hi-Fi systems of which each Hi-Fi system can comprise of one or more products connected together, e.g. a media player and a pre-amp.<br />
<br />
The UPnP AV standard assumes a single box which is made up of a single source and possibly a volume control. The standard has no way of representing a system that is made up of several different boxes connected together, e.g. a media renderer connected into a pre-amp. Taking the example of a media renderer connected to a pre-amp, without the ability to represent the different boxes and how they are connected it is impossible, using the UPnP AV standard, to select the input on the pre-amp that the media renderer is connected to when the user selects the media renderer in a control point.<br />
<br />
== Problem 5: Media's URI changing when media server rebuilds its database ==<br />
<br />
The UPnP AV media server specification does not have a requirement for media servers to present a piece of media to the network with the same URI. This has resulted in media server implementations that change media URIs when a user changes their media collection. This results in unexpected behaviour for the user. For example, a user plays some media on their renderer. The user then modifies their media collection which results in the media server rebuilding its database. The user then presses play on their renderer to only hear nothing (the URI is now no longer valid) or worse some different piece of media (the URI now represents some different media).<br />
<br />
= ohMeida Solutions =<br />
The ohMedia standard has been designed to solve all the problems described above.<br />
<br />
The first three problems are solved through the [[#ohPlaylist|ohPlaylist]] service specification.<br />
<br />
Problem 4 is solved through the [[#ohProduct_and_ohTopology|ohProduct service specification and the ohTopology algorithm]].<br />
<br />
Problem 5 is solved through the ohMedia server specification. <<link to how it works>><br />
<br />
The ohMedia standard goes further and adds the ohSongcast standard. ohSongcast provides the ability to synchronise playback between products, commonly referred to as party mode. However in general ohSongcast provides the ability for a product to stream its audio over a standard home network and for any product that supports the ohSongcast receiver specification to receive the audio and play it back. <<link to how it works>><br />
<br />
= How it works =<br />
<br />
ohMedia models media in the home through the interaction of 3 types of device, Control Points, Media Players and Media Servers.<br />
<br />
<<picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve>><br />
<br />
The Control Point first browses the Media Server to locate the desired media. The Control Point then tells the Media Player to play the selected media and finally Media Player retrieves the media from the Media Server.<br />
<br />
== ohProduct and ohTopology ==<br />
<br />
ohMedia models a home as a number Hi-Fi systems, which are located in rooms.<br />
<br />
ohMedia models a Hi-Fi system as a hierarchical tree of products, where a product is defined as a single physical box that is located in a room, has a unique name within the room, has one output and any number of sources.<br />
<br />
<<diagram of a product with multi-in, one out>><br />
<br />
A product is modelled through the ohProduct service specification.<br />
<br />
When a control point wants to construct a model of a user's home they use the ohTopology algorithm. The ohTopology algorithm is as follows,<br />
<br />
1.discover all the products in the home that have an ohProduct service<br />
2.group the discovered products based on the room they are in<br />
3.create a hierarchical tree structure by matching source names to product names<br />
4.discover source functionality based on source type<br />
5.discover additional functionality based on product attributes<br />
<br />
e.g. if we had two products, a pre-amp and a media player, which were connected together then both their ohProduct services would return the same room name and one of the source names returned by the pre-amp's ohProduct service would be the same as the product name returned by the media renderer's ohProduct service.<br />
<br />
<<picture of example>><br />
<br />
== Sources ==<br />
<br />
ohMedia defines four source types,<br />
<br />
1.Playlist – product supports on device playlists<br />
2.Radio – product supports internet radio with presets<br />
3.Receiver – product supports receiving ohSongcast broadcasts<br />
4.UpnpAv – product also implements the UPnP AV media renderer specification<br />
<br />
If a source type is not one of the types above an ohMedia control point will be able to switch to the source but will treat the source as a non controllable external input e.g. Analogue, TOS or HDMI.<br />
<br />
== Attributes ==<br />
<br />
ohMedia defines three attributes,<br />
<br />
1.Volume – product supports volume control<br />
2.Info – product supports providing information about the currently playing media<br />
3.Time – product supports providing the current time within the currently playing media<br />
4.Sender – product supports ohSongcast broadcasting<br />
<br />
== ohPlaylist ==<br />
<br />
The ohPlaylist specification has been designed to allow gap-less audio, playlists to proceed without the intervention of a control point and to function correctly under the manipulation of multiple control points.<br />
<br />
The ohPlaylist is a list of media associated with a unique ID. Media is defined by its URI and metadata. A control point is required to keep in memory the current list of playlist IDs. This list of IDs can then be used to list the media in the order of play, obtain the metadata and manipulate the list.<br />
<br />
The Playlist service provides the API that allow control points to manipulate, keep track of playlist changes and control playback.<br />
<br />
== ohSongcast ==<br />
<br />
<<to do>><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
of either of these two concepts so a control point can only provide a user with a flat list of UPnP AV products in the home. Whilst this might work reasonably well for a user with a single UPnP AV product it is far from ideal when they have multiple UPnP AV products.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
In the UPnP AV system architecture the control point holds all the information about the sequence of URIs that a media renderer will play. When there are multiple control points on the network there is no way for them all to have a common understanding of what a media renderer's sequence of URIs is. This results in each control point having its own, conflicting, understanding of a media renderer's state and when the current URI stops playing it becomes a race between the control points to set what they each believe to be the next URI.<br />
<br />
<br />
<br />
<br />
<br />
<br />
Problem 4: No support for synchronised playback across products<br />
<br />
The UPnP AV standard does not provide any solution to being able to synchronise playback across products.<br />
<br />
<br />
The ohMedia standard solves this deficiency by storing the user created playlist on the media renderer. This means that an ohMedia media renderer can play a user created playlist without the need for a control point to be switched on.<br />
<br />
The ohMedia standard solves this deficiency by moving the state of a media renderer from the control point into the media renderer. This means that all control points can now share a common understanding of what a media renderer's current state is.<br />
<br />
The ohMedia standard solves this problem by storing the playlist on the media renderer. This allows the ohMedia media renderer can start playback of the next URI immediately after the current URI has finished playing.<br />
<br />
The ohMedia standard solves the deficiency with ohSongcast. ohSongcast is an open network protocol that allows audio synchronisation between products that implement the ohSongcast protocol.<br />
<br />
The ohMedia standard solves this deficiency through ohTopology. ohTopology defines how products are found on the network, how products are grouped together and how the grouped products are connected together.<br />
<br />
How It Works<br />
<br />
The ohMedia standard uses the same playback architecture as used in the UPnP AV standard. The architecture is commonly known as the 3 box model. The 3 boxes in the 3 box model are, Media Renderer, Media Server and Control Point. The three components each work together to perform the task of playing back media. The media server contains the content available to a user. The user interacts with the control point's user interface to search and select the desired content on the media server and then to select the media renderer to playback the desired content. Playback of the content is achieved by out of band communication between the media server and media renderer, the control point is no involved.</div>Joshhhttp://wiki.openhome.org/wiki/OhMediaOhMedia2011-12-15T20:55:02Z<p>Joshh: /* ohTopology */</p>
<hr />
<div>= ohMedia Overview =<br />
<br />
ohMedia is an open standard that allows the seamless interaction of media within your home.<br />
<br />
ohMedia's high level design is influenced by the UPnP AV standard (UAV). UAV correctly modelled media in the home as the interaction between 3 types of devices: Control Points, Media Renderers, and Media Servers.<br />
<<picture>><br />
This model correctly identified the potential presence of an arbitrary number of each of these devices. However, the Media Server specification, and in particular the Media Renderer specification is deeply flawed. The next section explains those flaws and outlines how ohMedia fixes them.<br />
<br />
= Flaws in the UPnP AV Standard =<br />
<br />
== Problem 1: No support for gap-less audio ==<br />
<br />
The UPnP AV media renderer specification is technically able to support gap-less audio though the AV Transport service actions, setAVTRansportURI and setNextAVTransportURI. However, the UPnP forum chose to make the setNextAVTransportURI action optional. This meant that no, or very few, media renderer manufacturers chose to support the action, which in turn, meant that no control points have added support for gap-less audio. So the real world situation is that UPnP AV has no support for gap-less audio.<br />
<br />
== Problem 2: No support for a user's playlist to continue playing when a control point is turned off ==<br />
<br />
The UPnP AV media renderer specification only allows for a media renderer to store a maximum of two URIs, but, as previously discussed, the real world maximum is in fact only a single URI. This means that in order for a media renderer to play a user created playlist the control point has to be continually monitoring the media renderer. When the media renderer indicates that it has finished playing the current URI the control point then has to set the next URI. If the control point is turned off and not monitoring the media renderer then the media renderer will not be informed of the next URI and playback will stop.<br />
<br />
== Problem 3: No support for multiple control points ==<br />
<br />
The UPnP AV media renderer specification caters for the case where a user wants multiple control points to show the metadata that is associated with the currently playing URI. However when it comes to controlling a media renderer from multiple control points the standard quickly shows it inadequacies.<br />
<br />
The main problems comes from the fact that the media renderer only holds a URI for the currently playing URI. This means that only the control point that the user used to create a playlist has knowledge about the playlist. As described earlier, because this control point holds the user's playlist it is actually controlling the flow of URIs to the media renderer. What happens if the same user adds tracks to a different control point? At this point two control points are trying to control the flow of different URIs to the media renderer. At this point the whole system fails to operate as the user expects.<br />
<br />
When a user creates a playlist on their control point and starts playback on a UPnP AV media renderer the renderer only holds the currently playing URI. When the renderer finishes the current URI the control point provides the renderer with next URI. If the control point is turned off at the point when the renderer finishes playing the current URI the renderer will stop playback.<br />
<br />
With the control point controlling the flow of URIs to the media renderer the UPnP AV media renderer specification violates the 3 box model separation where the control point should, without any intervention, enable content to flow between the media server and media renderer.<br />
<br />
== Problem 4: No concept of a Hi-Fi system comprising of more than one product or a home comprising of more than one Hi-Fi system ==<br />
<br />
A modern home can have one or more Hi-Fi systems of which each Hi-Fi system can comprise of one or more products connected together, e.g. a media player and a pre-amp.<br />
<br />
The UPnP AV standard assumes a single box which is made up of a single source and possibly a volume control. The standard has no way of representing a system that is made up of several different boxes connected together, e.g. a media renderer connected into a pre-amp. Taking the example of a media renderer connected to a pre-amp, without the ability to represent the different boxes and how they are connected it is impossible, using the UPnP AV standard, to select the input on the pre-amp that the media renderer is connected to when the user selects the media renderer in a control point.<br />
<br />
== Problem 5: Media's URI changing when media server rebuilds its database ==<br />
<br />
The UPnP AV media server specification does not have a requirement for media servers to present a piece of media to the network with the same URI. This has resulted in media server implementations that change media URIs when a user changes their media collection. This results in unexpected behaviour for the user. For example, a user plays some media on their renderer. The user then modifies their media collection which results in the media server rebuilding its database. The user then presses play on their renderer to only hear nothing (the URI is now no longer valid) or worse some different piece of media (the URI now represents some different media).<br />
<br />
= ohMeida Solutions =<br />
The ohMedia standard has been designed to solve all the problems described above.<br />
<br />
The first three problems are solved through the [[#ohPlaylist|ohPlaylist]] service specification.<br />
<br />
Problem 4 is solved through the ohProduct service specification and the ohTopology algorithm. <<link to how it works>><br />
<br />
Problem 5 is solved through the ohMedia server specification. <<link to how it works>><br />
<br />
The ohMedia standard goes further and adds the ohSongcast standard. ohSongcast provides the ability to synchronise playback between products, commonly referred to as party mode. However in general ohSongcast provides the ability for a product to stream its audio over a standard home network and for any product that supports the ohSongcast receiver specification to receive the audio and play it back. <<link to how it works>><br />
<br />
= How it works =<br />
<br />
ohMedia models media in the home through the interaction of 3 types of device, Control Points, Media Players and Media Servers.<br />
<br />
<<picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve>><br />
<br />
The Control Point first browses the Media Server to locate the desired media. The Control Point then tells the Media Player to play the selected media and finally Media Player retrieves the media from the Media Server.<br />
<br />
== ohProduct and ohTopology ==<br />
<br />
ohMedia models a home as a number Hi-Fi systems, which are located in rooms.<br />
<br />
ohMedia models a Hi-Fi system as a hierarchical tree of products, where a product is defined as a single physical box that is located in a room, has a unique name within the room, has one output and any number of sources.<br />
<br />
<<diagram of a product with multi-in, one out>><br />
<br />
A product is modelled through the ohProduct service specification.<br />
<br />
When a control point wants to construct a model of a user's home they use the ohTopology algorithm. The ohTopology algorithm is as follows,<br />
<br />
1.discover all the products in the home that have an ohProduct service<br />
2.group the discovered products based on the room they are in<br />
3.create a hierarchical tree structure by matching source names to product names<br />
4.discover source functionality based on source type<br />
5.discover additional functionality based on product attributes<br />
<br />
e.g. if we had two products, a pre-amp and a media player, which were connected together then both their ohProduct services would return the same room name and one of the source names returned by the pre-amp's ohProduct service would be the same as the product name returned by the media renderer's ohProduct service.<br />
<br />
<<picture of example>><br />
<br />
== Sources ==<br />
<br />
ohMedia defines four source types,<br />
<br />
1.Playlist – product supports on device playlists<br />
2.Radio – product supports internet radio with presets<br />
3.Receiver – product supports receiving ohSongcast broadcasts<br />
4.UpnpAv – product also implements the UPnP AV media renderer specification<br />
<br />
If a source type is not one of the types above an ohMedia control point will be able to switch to the source but will treat the source as a non controllable external input e.g. Analogue, TOS or HDMI.<br />
<br />
== Attributes ==<br />
<br />
ohMedia defines three attributes,<br />
<br />
1.Volume – product supports volume control<br />
2.Info – product supports providing information about the currently playing media<br />
3.Time – product supports providing the current time within the currently playing media<br />
4.Sender – product supports ohSongcast broadcasting<br />
<br />
== ohPlaylist ==<br />
<br />
The ohPlaylist specification has been designed to allow gap-less audio, playlists to proceed without the intervention of a control point and to function correctly under the manipulation of multiple control points.<br />
<br />
The ohPlaylist is a list of media associated with a unique ID. Media is defined by its URI and metadata. A control point is required to keep in memory the current list of playlist IDs. This list of IDs can then be used to list the media in the order of play, obtain the metadata and manipulate the list.<br />
<br />
The Playlist service provides the API that allow control points to manipulate, keep track of playlist changes and control playback.<br />
<br />
== ohSongcast ==<br />
<br />
<<to do>><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
of either of these two concepts so a control point can only provide a user with a flat list of UPnP AV products in the home. Whilst this might work reasonably well for a user with a single UPnP AV product it is far from ideal when they have multiple UPnP AV products.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
In the UPnP AV system architecture the control point holds all the information about the sequence of URIs that a media renderer will play. When there are multiple control points on the network there is no way for them all to have a common understanding of what a media renderer's sequence of URIs is. This results in each control point having its own, conflicting, understanding of a media renderer's state and when the current URI stops playing it becomes a race between the control points to set what they each believe to be the next URI.<br />
<br />
<br />
<br />
<br />
<br />
<br />
Problem 4: No support for synchronised playback across products<br />
<br />
The UPnP AV standard does not provide any solution to being able to synchronise playback across products.<br />
<br />
<br />
The ohMedia standard solves this deficiency by storing the user created playlist on the media renderer. This means that an ohMedia media renderer can play a user created playlist without the need for a control point to be switched on.<br />
<br />
The ohMedia standard solves this deficiency by moving the state of a media renderer from the control point into the media renderer. This means that all control points can now share a common understanding of what a media renderer's current state is.<br />
<br />
The ohMedia standard solves this problem by storing the playlist on the media renderer. This allows the ohMedia media renderer can start playback of the next URI immediately after the current URI has finished playing.<br />
<br />
The ohMedia standard solves the deficiency with ohSongcast. ohSongcast is an open network protocol that allows audio synchronisation between products that implement the ohSongcast protocol.<br />
<br />
The ohMedia standard solves this deficiency through ohTopology. ohTopology defines how products are found on the network, how products are grouped together and how the grouped products are connected together.<br />
<br />
How It Works<br />
<br />
The ohMedia standard uses the same playback architecture as used in the UPnP AV standard. The architecture is commonly known as the 3 box model. The 3 boxes in the 3 box model are, Media Renderer, Media Server and Control Point. The three components each work together to perform the task of playing back media. The media server contains the content available to a user. The user interacts with the control point's user interface to search and select the desired content on the media server and then to select the media renderer to playback the desired content. Playback of the content is achieved by out of band communication between the media server and media renderer, the control point is no involved.</div>Joshhhttp://wiki.openhome.org/wiki/OhMediaOhMedia2011-12-15T20:54:06Z<p>Joshh: /* ohMeida Solutions */</p>
<hr />
<div>= ohMedia Overview =<br />
<br />
ohMedia is an open standard that allows the seamless interaction of media within your home.<br />
<br />
ohMedia's high level design is influenced by the UPnP AV standard (UAV). UAV correctly modelled media in the home as the interaction between 3 types of devices: Control Points, Media Renderers, and Media Servers.<br />
<<picture>><br />
This model correctly identified the potential presence of an arbitrary number of each of these devices. However, the Media Server specification, and in particular the Media Renderer specification is deeply flawed. The next section explains those flaws and outlines how ohMedia fixes them.<br />
<br />
= Flaws in the UPnP AV Standard =<br />
<br />
== Problem 1: No support for gap-less audio ==<br />
<br />
The UPnP AV media renderer specification is technically able to support gap-less audio though the AV Transport service actions, setAVTRansportURI and setNextAVTransportURI. However, the UPnP forum chose to make the setNextAVTransportURI action optional. This meant that no, or very few, media renderer manufacturers chose to support the action, which in turn, meant that no control points have added support for gap-less audio. So the real world situation is that UPnP AV has no support for gap-less audio.<br />
<br />
== Problem 2: No support for a user's playlist to continue playing when a control point is turned off ==<br />
<br />
The UPnP AV media renderer specification only allows for a media renderer to store a maximum of two URIs, but, as previously discussed, the real world maximum is in fact only a single URI. This means that in order for a media renderer to play a user created playlist the control point has to be continually monitoring the media renderer. When the media renderer indicates that it has finished playing the current URI the control point then has to set the next URI. If the control point is turned off and not monitoring the media renderer then the media renderer will not be informed of the next URI and playback will stop.<br />
<br />
== Problem 3: No support for multiple control points ==<br />
<br />
The UPnP AV media renderer specification caters for the case where a user wants multiple control points to show the metadata that is associated with the currently playing URI. However when it comes to controlling a media renderer from multiple control points the standard quickly shows it inadequacies.<br />
<br />
The main problems comes from the fact that the media renderer only holds a URI for the currently playing URI. This means that only the control point that the user used to create a playlist has knowledge about the playlist. As described earlier, because this control point holds the user's playlist it is actually controlling the flow of URIs to the media renderer. What happens if the same user adds tracks to a different control point? At this point two control points are trying to control the flow of different URIs to the media renderer. At this point the whole system fails to operate as the user expects.<br />
<br />
When a user creates a playlist on their control point and starts playback on a UPnP AV media renderer the renderer only holds the currently playing URI. When the renderer finishes the current URI the control point provides the renderer with next URI. If the control point is turned off at the point when the renderer finishes playing the current URI the renderer will stop playback.<br />
<br />
With the control point controlling the flow of URIs to the media renderer the UPnP AV media renderer specification violates the 3 box model separation where the control point should, without any intervention, enable content to flow between the media server and media renderer.<br />
<br />
== Problem 4: No concept of a Hi-Fi system comprising of more than one product or a home comprising of more than one Hi-Fi system ==<br />
<br />
A modern home can have one or more Hi-Fi systems of which each Hi-Fi system can comprise of one or more products connected together, e.g. a media player and a pre-amp.<br />
<br />
The UPnP AV standard assumes a single box which is made up of a single source and possibly a volume control. The standard has no way of representing a system that is made up of several different boxes connected together, e.g. a media renderer connected into a pre-amp. Taking the example of a media renderer connected to a pre-amp, without the ability to represent the different boxes and how they are connected it is impossible, using the UPnP AV standard, to select the input on the pre-amp that the media renderer is connected to when the user selects the media renderer in a control point.<br />
<br />
== Problem 5: Media's URI changing when media server rebuilds its database ==<br />
<br />
The UPnP AV media server specification does not have a requirement for media servers to present a piece of media to the network with the same URI. This has resulted in media server implementations that change media URIs when a user changes their media collection. This results in unexpected behaviour for the user. For example, a user plays some media on their renderer. The user then modifies their media collection which results in the media server rebuilding its database. The user then presses play on their renderer to only hear nothing (the URI is now no longer valid) or worse some different piece of media (the URI now represents some different media).<br />
<br />
= ohMeida Solutions =<br />
The ohMedia standard has been designed to solve all the problems described above.<br />
<br />
The first three problems are solved through the [[#ohPlaylist|ohPlaylist]] service specification.<br />
<br />
Problem 4 is solved through the ohProduct service specification and the ohTopology algorithm. <<link to how it works>><br />
<br />
Problem 5 is solved through the ohMedia server specification. <<link to how it works>><br />
<br />
The ohMedia standard goes further and adds the ohSongcast standard. ohSongcast provides the ability to synchronise playback between products, commonly referred to as party mode. However in general ohSongcast provides the ability for a product to stream its audio over a standard home network and for any product that supports the ohSongcast receiver specification to receive the audio and play it back. <<link to how it works>><br />
<br />
= How it works =<br />
<br />
ohMedia models media in the home through the interaction of 3 types of device, Control Points, Media Players and Media Servers.<br />
<br />
<<picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve>><br />
<br />
The Control Point first browses the Media Server to locate the desired media. The Control Point then tells the Media Player to play the selected media and finally Media Player retrieves the media from the Media Server.<br />
<br />
== ohTopology ==<br />
<br />
ohMedia models a home as a number Hi-Fi systems, which are located in rooms.<br />
<br />
ohMedia models a Hi-Fi system as a hierarchical tree of products, where a product is defined as a single physical box that is located in a room, has a unique name within the room, has one output and any number of sources.<br />
<br />
<<diagram of a product with multi-in, one out>><br />
<br />
A product is modelled through the ohProduct service specification.<br />
<br />
When a control point wants to construct a model of a user's home they use the ohTopology algorithm. The ohTopology algorithm is as follows,<br />
<br />
1.discover all the products in the home that have an ohProduct service<br />
2.group the discovered products based on the room they are in<br />
3.create a hierarchical tree structure by matching source names to product names<br />
4.discover source functionality based on source type<br />
5.discover additional functionality based on product attributes<br />
<br />
e.g. if we had two products, a pre-amp and a media player, which were connected together then both their ohProduct services would return the same room name and one of the source names returned by the pre-amp's ohProduct service would be the same as the product name returned by the media renderer's ohProduct service.<br />
<br />
<<picture of example>><br />
<br />
== Sources ==<br />
<br />
ohMedia defines four source types,<br />
<br />
1.Playlist – product supports on device playlists<br />
2.Radio – product supports internet radio with presets<br />
3.Receiver – product supports receiving ohSongcast broadcasts<br />
4.UpnpAv – product also implements the UPnP AV media renderer specification<br />
<br />
If a source type is not one of the types above an ohMedia control point will be able to switch to the source but will treat the source as a non controllable external input e.g. Analogue, TOS or HDMI.<br />
<br />
== Attributes ==<br />
<br />
ohMedia defines three attributes,<br />
<br />
1.Volume – product supports volume control<br />
2.Info – product supports providing information about the currently playing media<br />
3.Time – product supports providing the current time within the currently playing media<br />
4.Sender – product supports ohSongcast broadcasting<br />
<br />
== ohPlaylist ==<br />
<br />
The ohPlaylist specification has been designed to allow gap-less audio, playlists to proceed without the intervention of a control point and to function correctly under the manipulation of multiple control points.<br />
<br />
The ohPlaylist is a list of media associated with a unique ID. Media is defined by its URI and metadata. A control point is required to keep in memory the current list of playlist IDs. This list of IDs can then be used to list the media in the order of play, obtain the metadata and manipulate the list.<br />
<br />
The Playlist service provides the API that allow control points to manipulate, keep track of playlist changes and control playback.<br />
<br />
== ohSongcast ==<br />
<br />
<<to do>><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
of either of these two concepts so a control point can only provide a user with a flat list of UPnP AV products in the home. Whilst this might work reasonably well for a user with a single UPnP AV product it is far from ideal when they have multiple UPnP AV products.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
In the UPnP AV system architecture the control point holds all the information about the sequence of URIs that a media renderer will play. When there are multiple control points on the network there is no way for them all to have a common understanding of what a media renderer's sequence of URIs is. This results in each control point having its own, conflicting, understanding of a media renderer's state and when the current URI stops playing it becomes a race between the control points to set what they each believe to be the next URI.<br />
<br />
<br />
<br />
<br />
<br />
<br />
Problem 4: No support for synchronised playback across products<br />
<br />
The UPnP AV standard does not provide any solution to being able to synchronise playback across products.<br />
<br />
<br />
The ohMedia standard solves this deficiency by storing the user created playlist on the media renderer. This means that an ohMedia media renderer can play a user created playlist without the need for a control point to be switched on.<br />
<br />
The ohMedia standard solves this deficiency by moving the state of a media renderer from the control point into the media renderer. This means that all control points can now share a common understanding of what a media renderer's current state is.<br />
<br />
The ohMedia standard solves this problem by storing the playlist on the media renderer. This allows the ohMedia media renderer can start playback of the next URI immediately after the current URI has finished playing.<br />
<br />
The ohMedia standard solves the deficiency with ohSongcast. ohSongcast is an open network protocol that allows audio synchronisation between products that implement the ohSongcast protocol.<br />
<br />
The ohMedia standard solves this deficiency through ohTopology. ohTopology defines how products are found on the network, how products are grouped together and how the grouped products are connected together.<br />
<br />
How It Works<br />
<br />
The ohMedia standard uses the same playback architecture as used in the UPnP AV standard. The architecture is commonly known as the 3 box model. The 3 boxes in the 3 box model are, Media Renderer, Media Server and Control Point. The three components each work together to perform the task of playing back media. The media server contains the content available to a user. The user interacts with the control point's user interface to search and select the desired content on the media server and then to select the media renderer to playback the desired content. Playback of the content is achieved by out of band communication between the media server and media renderer, the control point is no involved.</div>Joshhhttp://wiki.openhome.org/wiki/OhMediaOhMedia2011-12-15T20:45:01Z<p>Joshh: /* How it works */</p>
<hr />
<div>= ohMedia Overview =<br />
<br />
ohMedia is an open standard that allows the seamless interaction of media within your home.<br />
<br />
ohMedia's high level design is influenced by the UPnP AV standard (UAV). UAV correctly modelled media in the home as the interaction between 3 types of devices: Control Points, Media Renderers, and Media Servers.<br />
<<picture>><br />
This model correctly identified the potential presence of an arbitrary number of each of these devices. However, the Media Server specification, and in particular the Media Renderer specification is deeply flawed. The next section explains those flaws and outlines how ohMedia fixes them.<br />
<br />
= Flaws in the UPnP AV Standard =<br />
<br />
== Problem 1: No support for gap-less audio ==<br />
<br />
The UPnP AV media renderer specification is technically able to support gap-less audio though the AV Transport service actions, setAVTRansportURI and setNextAVTransportURI. However, the UPnP forum chose to make the setNextAVTransportURI action optional. This meant that no, or very few, media renderer manufacturers chose to support the action, which in turn, meant that no control points have added support for gap-less audio. So the real world situation is that UPnP AV has no support for gap-less audio.<br />
<br />
== Problem 2: No support for a user's playlist to continue playing when a control point is turned off ==<br />
<br />
The UPnP AV media renderer specification only allows for a media renderer to store a maximum of two URIs, but, as previously discussed, the real world maximum is in fact only a single URI. This means that in order for a media renderer to play a user created playlist the control point has to be continually monitoring the media renderer. When the media renderer indicates that it has finished playing the current URI the control point then has to set the next URI. If the control point is turned off and not monitoring the media renderer then the media renderer will not be informed of the next URI and playback will stop.<br />
<br />
== Problem 3: No support for multiple control points ==<br />
<br />
The UPnP AV media renderer specification caters for the case where a user wants multiple control points to show the metadata that is associated with the currently playing URI. However when it comes to controlling a media renderer from multiple control points the standard quickly shows it inadequacies.<br />
<br />
The main problems comes from the fact that the media renderer only holds a URI for the currently playing URI. This means that only the control point that the user used to create a playlist has knowledge about the playlist. As described earlier, because this control point holds the user's playlist it is actually controlling the flow of URIs to the media renderer. What happens if the same user adds tracks to a different control point? At this point two control points are trying to control the flow of different URIs to the media renderer. At this point the whole system fails to operate as the user expects.<br />
<br />
When a user creates a playlist on their control point and starts playback on a UPnP AV media renderer the renderer only holds the currently playing URI. When the renderer finishes the current URI the control point provides the renderer with next URI. If the control point is turned off at the point when the renderer finishes playing the current URI the renderer will stop playback.<br />
<br />
With the control point controlling the flow of URIs to the media renderer the UPnP AV media renderer specification violates the 3 box model separation where the control point should, without any intervention, enable content to flow between the media server and media renderer.<br />
<br />
== Problem 4: No concept of a Hi-Fi system comprising of more than one product or a home comprising of more than one Hi-Fi system ==<br />
<br />
A modern home can have one or more Hi-Fi systems of which each Hi-Fi system can comprise of one or more products connected together, e.g. a media player and a pre-amp.<br />
<br />
The UPnP AV standard assumes a single box which is made up of a single source and possibly a volume control. The standard has no way of representing a system that is made up of several different boxes connected together, e.g. a media renderer connected into a pre-amp. Taking the example of a media renderer connected to a pre-amp, without the ability to represent the different boxes and how they are connected it is impossible, using the UPnP AV standard, to select the input on the pre-amp that the media renderer is connected to when the user selects the media renderer in a control point.<br />
<br />
== Problem 5: Media's URI changing when media server rebuilds its database ==<br />
<br />
The UPnP AV media server specification does not have a requirement for media servers to present a piece of media to the network with the same URI. This has resulted in media server implementations that change media URIs when a user changes their media collection. This results in unexpected behaviour for the user. For example, a user plays some media on their renderer. The user then modifies their media collection which results in the media server rebuilding its database. The user then presses play on their renderer to only hear nothing (the URI is now no longer valid) or worse some different piece of media (the URI now represents some different media).<br />
<br />
= ohMeida Solutions =<br />
The ohMedia standard has been designed to solve all the problems described above.<br />
<br />
The first three problems are solved through the ohPlaylist service specification. <<link to how it works>><br />
<br />
Problem 4 is solved through the ohProduct service specification and the ohTopology algorithm. <<link to how it works>><br />
<br />
Problem 5 is solved through the ohMedia server specification. <<link to how it works>><br />
<br />
The ohMedia standard goes further and adds the ohSongcast standard. ohSongcast provides the ability to synchronise playback between products, commonly referred to as party mode. However in general ohSongcast provides the ability for a product to stream its audio over a standard home network and for any product that supports the ohSongcast receiver specification to receive the audio and play it back. <<link to how it works>><br />
<br />
= How it works =<br />
<br />
ohMedia models media in the home through the interaction of 3 types of device, Control Points, Media Players and Media Servers.<br />
<br />
<<picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve>><br />
<br />
The Control Point first browses the Media Server to locate the desired media. The Control Point then tells the Media Player to play the selected media and finally Media Player retrieves the media from the Media Server.<br />
<br />
== ohTopology ==<br />
<br />
ohMedia models a home as a number Hi-Fi systems, which are located in rooms.<br />
<br />
ohMedia models a Hi-Fi system as a hierarchical tree of products, where a product is defined as a single physical box that is located in a room, has a unique name within the room, has one output and any number of sources.<br />
<br />
<<diagram of a product with multi-in, one out>><br />
<br />
A product is modelled through the ohProduct service specification.<br />
<br />
When a control point wants to construct a model of a user's home they use the ohTopology algorithm. The ohTopology algorithm is as follows,<br />
<br />
1.discover all the products in the home that have an ohProduct service<br />
2.group the discovered products based on the room they are in<br />
3.create a hierarchical tree structure by matching source names to product names<br />
4.discover source functionality based on source type<br />
5.discover additional functionality based on product attributes<br />
<br />
e.g. if we had two products, a pre-amp and a media player, which were connected together then both their ohProduct services would return the same room name and one of the source names returned by the pre-amp's ohProduct service would be the same as the product name returned by the media renderer's ohProduct service.<br />
<br />
<<picture of example>><br />
<br />
== Sources ==<br />
<br />
ohMedia defines four source types,<br />
<br />
1.Playlist – product supports on device playlists<br />
2.Radio – product supports internet radio with presets<br />
3.Receiver – product supports receiving ohSongcast broadcasts<br />
4.UpnpAv – product also implements the UPnP AV media renderer specification<br />
<br />
If a source type is not one of the types above an ohMedia control point will be able to switch to the source but will treat the source as a non controllable external input e.g. Analogue, TOS or HDMI.<br />
<br />
== Attributes ==<br />
<br />
ohMedia defines three attributes,<br />
<br />
1.Volume – product supports volume control<br />
2.Info – product supports providing information about the currently playing media<br />
3.Time – product supports providing the current time within the currently playing media<br />
4.Sender – product supports ohSongcast broadcasting<br />
<br />
== ohPlaylist ==<br />
<br />
The ohPlaylist specification has been designed to allow gap-less audio, playlists to proceed without the intervention of a control point and to function correctly under the manipulation of multiple control points.<br />
<br />
The ohPlaylist is a list of media associated with a unique ID. Media is defined by its URI and metadata. A control point is required to keep in memory the current list of playlist IDs. This list of IDs can then be used to list the media in the order of play, obtain the metadata and manipulate the list.<br />
<br />
The Playlist service provides the API that allow control points to manipulate, keep track of playlist changes and control playback.<br />
<br />
== ohSongcast ==<br />
<br />
<<to do>><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
of either of these two concepts so a control point can only provide a user with a flat list of UPnP AV products in the home. Whilst this might work reasonably well for a user with a single UPnP AV product it is far from ideal when they have multiple UPnP AV products.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
In the UPnP AV system architecture the control point holds all the information about the sequence of URIs that a media renderer will play. When there are multiple control points on the network there is no way for them all to have a common understanding of what a media renderer's sequence of URIs is. This results in each control point having its own, conflicting, understanding of a media renderer's state and when the current URI stops playing it becomes a race between the control points to set what they each believe to be the next URI.<br />
<br />
<br />
<br />
<br />
<br />
<br />
Problem 4: No support for synchronised playback across products<br />
<br />
The UPnP AV standard does not provide any solution to being able to synchronise playback across products.<br />
<br />
<br />
The ohMedia standard solves this deficiency by storing the user created playlist on the media renderer. This means that an ohMedia media renderer can play a user created playlist without the need for a control point to be switched on.<br />
<br />
The ohMedia standard solves this deficiency by moving the state of a media renderer from the control point into the media renderer. This means that all control points can now share a common understanding of what a media renderer's current state is.<br />
<br />
The ohMedia standard solves this problem by storing the playlist on the media renderer. This allows the ohMedia media renderer can start playback of the next URI immediately after the current URI has finished playing.<br />
<br />
The ohMedia standard solves the deficiency with ohSongcast. ohSongcast is an open network protocol that allows audio synchronisation between products that implement the ohSongcast protocol.<br />
<br />
The ohMedia standard solves this deficiency through ohTopology. ohTopology defines how products are found on the network, how products are grouped together and how the grouped products are connected together.<br />
<br />
How It Works<br />
<br />
The ohMedia standard uses the same playback architecture as used in the UPnP AV standard. The architecture is commonly known as the 3 box model. The 3 boxes in the 3 box model are, Media Renderer, Media Server and Control Point. The three components each work together to perform the task of playing back media. The media server contains the content available to a user. The user interacts with the control point's user interface to search and select the desired content on the media server and then to select the media renderer to playback the desired content. Playback of the content is achieved by out of band communication between the media server and media renderer, the control point is no involved.</div>Joshhhttp://wiki.openhome.org/wiki/OhMediaOhMedia2011-12-15T20:43:25Z<p>Joshh: /* Overview */</p>
<hr />
<div>= ohMedia Overview =<br />
<br />
ohMedia is an open standard that allows the seamless interaction of media within your home.<br />
<br />
ohMedia's high level design is influenced by the UPnP AV standard (UAV). UAV correctly modelled media in the home as the interaction between 3 types of devices: Control Points, Media Renderers, and Media Servers.<br />
<<picture>><br />
This model correctly identified the potential presence of an arbitrary number of each of these devices. However, the Media Server specification, and in particular the Media Renderer specification is deeply flawed. The next section explains those flaws and outlines how ohMedia fixes them.<br />
<br />
= Flaws in the UPnP AV Standard =<br />
<br />
== Problem 1: No support for gap-less audio ==<br />
<br />
The UPnP AV media renderer specification is technically able to support gap-less audio though the AV Transport service actions, setAVTRansportURI and setNextAVTransportURI. However, the UPnP forum chose to make the setNextAVTransportURI action optional. This meant that no, or very few, media renderer manufacturers chose to support the action, which in turn, meant that no control points have added support for gap-less audio. So the real world situation is that UPnP AV has no support for gap-less audio.<br />
<br />
== Problem 2: No support for a user's playlist to continue playing when a control point is turned off ==<br />
<br />
The UPnP AV media renderer specification only allows for a media renderer to store a maximum of two URIs, but, as previously discussed, the real world maximum is in fact only a single URI. This means that in order for a media renderer to play a user created playlist the control point has to be continually monitoring the media renderer. When the media renderer indicates that it has finished playing the current URI the control point then has to set the next URI. If the control point is turned off and not monitoring the media renderer then the media renderer will not be informed of the next URI and playback will stop.<br />
<br />
== Problem 3: No support for multiple control points ==<br />
<br />
The UPnP AV media renderer specification caters for the case where a user wants multiple control points to show the metadata that is associated with the currently playing URI. However when it comes to controlling a media renderer from multiple control points the standard quickly shows it inadequacies.<br />
<br />
The main problems comes from the fact that the media renderer only holds a URI for the currently playing URI. This means that only the control point that the user used to create a playlist has knowledge about the playlist. As described earlier, because this control point holds the user's playlist it is actually controlling the flow of URIs to the media renderer. What happens if the same user adds tracks to a different control point? At this point two control points are trying to control the flow of different URIs to the media renderer. At this point the whole system fails to operate as the user expects.<br />
<br />
When a user creates a playlist on their control point and starts playback on a UPnP AV media renderer the renderer only holds the currently playing URI. When the renderer finishes the current URI the control point provides the renderer with next URI. If the control point is turned off at the point when the renderer finishes playing the current URI the renderer will stop playback.<br />
<br />
With the control point controlling the flow of URIs to the media renderer the UPnP AV media renderer specification violates the 3 box model separation where the control point should, without any intervention, enable content to flow between the media server and media renderer.<br />
<br />
== Problem 4: No concept of a Hi-Fi system comprising of more than one product or a home comprising of more than one Hi-Fi system ==<br />
<br />
A modern home can have one or more Hi-Fi systems of which each Hi-Fi system can comprise of one or more products connected together, e.g. a media player and a pre-amp.<br />
<br />
The UPnP AV standard assumes a single box which is made up of a single source and possibly a volume control. The standard has no way of representing a system that is made up of several different boxes connected together, e.g. a media renderer connected into a pre-amp. Taking the example of a media renderer connected to a pre-amp, without the ability to represent the different boxes and how they are connected it is impossible, using the UPnP AV standard, to select the input on the pre-amp that the media renderer is connected to when the user selects the media renderer in a control point.<br />
<br />
== Problem 5: Media's URI changing when media server rebuilds its database ==<br />
<br />
The UPnP AV media server specification does not have a requirement for media servers to present a piece of media to the network with the same URI. This has resulted in media server implementations that change media URIs when a user changes their media collection. This results in unexpected behaviour for the user. For example, a user plays some media on their renderer. The user then modifies their media collection which results in the media server rebuilding its database. The user then presses play on their renderer to only hear nothing (the URI is now no longer valid) or worse some different piece of media (the URI now represents some different media).<br />
<br />
= ohMeida Solutions =<br />
The ohMedia standard has been designed to solve all the problems described above.<br />
<br />
The first three problems are solved through the ohPlaylist service specification. <<link to how it works>><br />
<br />
Problem 4 is solved through the ohProduct service specification and the ohTopology algorithm. <<link to how it works>><br />
<br />
Problem 5 is solved through the ohMedia server specification. <<link to how it works>><br />
<br />
The ohMedia standard goes further and adds the ohSongcast standard. ohSongcast provides the ability to synchronise playback between products, commonly referred to as party mode. However in general ohSongcast provides the ability for a product to stream its audio over a standard home network and for any product that supports the ohSongcast receiver specification to receive the audio and play it back. <<link to how it works>><br />
<br />
= How it works =<br />
<br />
ohMedia models media in the home through the interaction of 3 types of device, Control Points, Media Players and Media Servers.<br />
<br />
<<picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve>><br />
<br />
The Control Point first browses the Media Server to locate the desired media. The Control Point then tells the Media Player to play the selected media and finally Media Player retrieves the media from the Media Server.<br />
<br />
ohTopology<br />
<br />
ohMedia models a home as a number Hi-Fi systems, which are located in rooms.<br />
<br />
ohMedia models a Hi-Fi system as a hierarchical tree of products, where a product is defined as a single physical box that is located in a room, has a unique name within the room, has one output and any number of sources.<br />
<br />
<<diagram of a product with multi-in, one out>><br />
<br />
A product is modelled through the ohProduct service specification.<br />
<br />
When a control point wants to construct a model of a user's home they use the ohTopology algorithm. The ohTopology algorithm is as follows,<br />
<br />
1.discover all the products in the home that have an ohProduct service<br />
2.group the discovered products based on the room they are in<br />
3.create a hierarchical tree structure by matching source names to product names<br />
4.discover source functionality based on source type<br />
5.discover additional functionality based on product attributes<br />
<br />
e.g. if we had two products, a pre-amp and a media player, which were connected together then both their ohProduct services would return the same room name and one of the source names returned by the pre-amp's ohProduct service would be the same as the product name returned by the media renderer's ohProduct service.<br />
<br />
<<picture of example>><br />
<br />
Sources<br />
<br />
ohMedia defines four source types,<br />
<br />
1.Playlist – product supports on device playlists<br />
2.Radio – product supports internet radio with presets<br />
3.Receiver – product supports receiving ohSongcast broadcasts<br />
4.UpnpAv – product also implements the UPnP AV media renderer specification<br />
<br />
If a source type is not one of the types above an ohMedia control point will be able to switch to the source but will treat the source as a non controllable external input e.g. Analogue, TOS or HDMI.<br />
<br />
Attributes<br />
<br />
ohMedia defines three attributes,<br />
<br />
1.Volume – product supports volume control<br />
2.Info – product supports providing information about the currently playing media<br />
3.Time – product supports providing the current time within the currently playing media<br />
4.Sender – product supports ohSongcast broadcasting<br />
<br />
ohPlaylist<br />
<br />
The ohPlaylist specification has been designed to allow gap-less audio, playlists to proceed without the intervention of a control point and to function correctly under the manipulation of multiple control points.<br />
<br />
The ohPlaylist is a list of media associated with a unique ID. Media is defined by its URI and metadata. A control point is required to keep in memory the current list of playlist IDs. This list of IDs can then be used to list the media in the order of play, obtain the metadata and manipulate the list.<br />
<br />
The Playlist service provides the API that allow control points to manipulate, keep track of playlist changes and control playback.<br />
<br />
ohSongcast<br />
<br />
<<to do>><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
of either of these two concepts so a control point can only provide a user with a flat list of UPnP AV products in the home. Whilst this might work reasonably well for a user with a single UPnP AV product it is far from ideal when they have multiple UPnP AV products.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
In the UPnP AV system architecture the control point holds all the information about the sequence of URIs that a media renderer will play. When there are multiple control points on the network there is no way for them all to have a common understanding of what a media renderer's sequence of URIs is. This results in each control point having its own, conflicting, understanding of a media renderer's state and when the current URI stops playing it becomes a race between the control points to set what they each believe to be the next URI.<br />
<br />
<br />
<br />
<br />
<br />
<br />
Problem 4: No support for synchronised playback across products<br />
<br />
The UPnP AV standard does not provide any solution to being able to synchronise playback across products.<br />
<br />
<br />
The ohMedia standard solves this deficiency by storing the user created playlist on the media renderer. This means that an ohMedia media renderer can play a user created playlist without the need for a control point to be switched on.<br />
<br />
The ohMedia standard solves this deficiency by moving the state of a media renderer from the control point into the media renderer. This means that all control points can now share a common understanding of what a media renderer's current state is.<br />
<br />
The ohMedia standard solves this problem by storing the playlist on the media renderer. This allows the ohMedia media renderer can start playback of the next URI immediately after the current URI has finished playing.<br />
<br />
The ohMedia standard solves the deficiency with ohSongcast. ohSongcast is an open network protocol that allows audio synchronisation between products that implement the ohSongcast protocol.<br />
<br />
The ohMedia standard solves this deficiency through ohTopology. ohTopology defines how products are found on the network, how products are grouped together and how the grouped products are connected together.<br />
<br />
How It Works<br />
<br />
The ohMedia standard uses the same playback architecture as used in the UPnP AV standard. The architecture is commonly known as the 3 box model. The 3 boxes in the 3 box model are, Media Renderer, Media Server and Control Point. The three components each work together to perform the task of playing back media. The media server contains the content available to a user. The user interacts with the control point's user interface to search and select the desired content on the media server and then to select the media renderer to playback the desired content. Playback of the content is achieved by out of band communication between the media server and media renderer, the control point is no involved.</div>Joshhhttp://wiki.openhome.org/wiki/OhMediaOhMedia2011-12-15T20:43:03Z<p>Joshh: Created page with "= Overview = ohMedia is an open standard that allows the seamless interaction of media within your home. ohMedia's high level design is influenced by the UPnP AV standard (UAV)..."</p>
<hr />
<div>= Overview =<br />
<br />
ohMedia is an open standard that allows the seamless interaction of media within your home.<br />
<br />
ohMedia's high level design is influenced by the UPnP AV standard (UAV). UAV correctly modelled media in the home as the interaction between 3 types of devices: Control Points, Media Renderers, and Media Servers.<br />
<<picture>><br />
This model correctly identified the potential presence of an arbitrary number of each of these devices. However, the Media Server specification, and in particular the Media Renderer specification is deeply flawed. The next section explains those flaws and outlines how ohMedia fixes them.<br />
<br />
= Flaws in the UPnP AV Standard =<br />
<br />
== Problem 1: No support for gap-less audio ==<br />
<br />
The UPnP AV media renderer specification is technically able to support gap-less audio though the AV Transport service actions, setAVTRansportURI and setNextAVTransportURI. However, the UPnP forum chose to make the setNextAVTransportURI action optional. This meant that no, or very few, media renderer manufacturers chose to support the action, which in turn, meant that no control points have added support for gap-less audio. So the real world situation is that UPnP AV has no support for gap-less audio.<br />
<br />
== Problem 2: No support for a user's playlist to continue playing when a control point is turned off ==<br />
<br />
The UPnP AV media renderer specification only allows for a media renderer to store a maximum of two URIs, but, as previously discussed, the real world maximum is in fact only a single URI. This means that in order for a media renderer to play a user created playlist the control point has to be continually monitoring the media renderer. When the media renderer indicates that it has finished playing the current URI the control point then has to set the next URI. If the control point is turned off and not monitoring the media renderer then the media renderer will not be informed of the next URI and playback will stop.<br />
<br />
== Problem 3: No support for multiple control points ==<br />
<br />
The UPnP AV media renderer specification caters for the case where a user wants multiple control points to show the metadata that is associated with the currently playing URI. However when it comes to controlling a media renderer from multiple control points the standard quickly shows it inadequacies.<br />
<br />
The main problems comes from the fact that the media renderer only holds a URI for the currently playing URI. This means that only the control point that the user used to create a playlist has knowledge about the playlist. As described earlier, because this control point holds the user's playlist it is actually controlling the flow of URIs to the media renderer. What happens if the same user adds tracks to a different control point? At this point two control points are trying to control the flow of different URIs to the media renderer. At this point the whole system fails to operate as the user expects.<br />
<br />
When a user creates a playlist on their control point and starts playback on a UPnP AV media renderer the renderer only holds the currently playing URI. When the renderer finishes the current URI the control point provides the renderer with next URI. If the control point is turned off at the point when the renderer finishes playing the current URI the renderer will stop playback.<br />
<br />
With the control point controlling the flow of URIs to the media renderer the UPnP AV media renderer specification violates the 3 box model separation where the control point should, without any intervention, enable content to flow between the media server and media renderer.<br />
<br />
== Problem 4: No concept of a Hi-Fi system comprising of more than one product or a home comprising of more than one Hi-Fi system ==<br />
<br />
A modern home can have one or more Hi-Fi systems of which each Hi-Fi system can comprise of one or more products connected together, e.g. a media player and a pre-amp.<br />
<br />
The UPnP AV standard assumes a single box which is made up of a single source and possibly a volume control. The standard has no way of representing a system that is made up of several different boxes connected together, e.g. a media renderer connected into a pre-amp. Taking the example of a media renderer connected to a pre-amp, without the ability to represent the different boxes and how they are connected it is impossible, using the UPnP AV standard, to select the input on the pre-amp that the media renderer is connected to when the user selects the media renderer in a control point.<br />
<br />
== Problem 5: Media's URI changing when media server rebuilds its database ==<br />
<br />
The UPnP AV media server specification does not have a requirement for media servers to present a piece of media to the network with the same URI. This has resulted in media server implementations that change media URIs when a user changes their media collection. This results in unexpected behaviour for the user. For example, a user plays some media on their renderer. The user then modifies their media collection which results in the media server rebuilding its database. The user then presses play on their renderer to only hear nothing (the URI is now no longer valid) or worse some different piece of media (the URI now represents some different media).<br />
<br />
= ohMeida Solutions =<br />
The ohMedia standard has been designed to solve all the problems described above.<br />
<br />
The first three problems are solved through the ohPlaylist service specification. <<link to how it works>><br />
<br />
Problem 4 is solved through the ohProduct service specification and the ohTopology algorithm. <<link to how it works>><br />
<br />
Problem 5 is solved through the ohMedia server specification. <<link to how it works>><br />
<br />
The ohMedia standard goes further and adds the ohSongcast standard. ohSongcast provides the ability to synchronise playback between products, commonly referred to as party mode. However in general ohSongcast provides the ability for a product to stream its audio over a standard home network and for any product that supports the ohSongcast receiver specification to receive the audio and play it back. <<link to how it works>><br />
<br />
= How it works =<br />
<br />
ohMedia models media in the home through the interaction of 3 types of device, Control Points, Media Players and Media Servers.<br />
<br />
<<picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve>><br />
<br />
The Control Point first browses the Media Server to locate the desired media. The Control Point then tells the Media Player to play the selected media and finally Media Player retrieves the media from the Media Server.<br />
<br />
ohTopology<br />
<br />
ohMedia models a home as a number Hi-Fi systems, which are located in rooms.<br />
<br />
ohMedia models a Hi-Fi system as a hierarchical tree of products, where a product is defined as a single physical box that is located in a room, has a unique name within the room, has one output and any number of sources.<br />
<br />
<<diagram of a product with multi-in, one out>><br />
<br />
A product is modelled through the ohProduct service specification.<br />
<br />
When a control point wants to construct a model of a user's home they use the ohTopology algorithm. The ohTopology algorithm is as follows,<br />
<br />
1.discover all the products in the home that have an ohProduct service<br />
2.group the discovered products based on the room they are in<br />
3.create a hierarchical tree structure by matching source names to product names<br />
4.discover source functionality based on source type<br />
5.discover additional functionality based on product attributes<br />
<br />
e.g. if we had two products, a pre-amp and a media player, which were connected together then both their ohProduct services would return the same room name and one of the source names returned by the pre-amp's ohProduct service would be the same as the product name returned by the media renderer's ohProduct service.<br />
<br />
<<picture of example>><br />
<br />
Sources<br />
<br />
ohMedia defines four source types,<br />
<br />
1.Playlist – product supports on device playlists<br />
2.Radio – product supports internet radio with presets<br />
3.Receiver – product supports receiving ohSongcast broadcasts<br />
4.UpnpAv – product also implements the UPnP AV media renderer specification<br />
<br />
If a source type is not one of the types above an ohMedia control point will be able to switch to the source but will treat the source as a non controllable external input e.g. Analogue, TOS or HDMI.<br />
<br />
Attributes<br />
<br />
ohMedia defines three attributes,<br />
<br />
1.Volume – product supports volume control<br />
2.Info – product supports providing information about the currently playing media<br />
3.Time – product supports providing the current time within the currently playing media<br />
4.Sender – product supports ohSongcast broadcasting<br />
<br />
ohPlaylist<br />
<br />
The ohPlaylist specification has been designed to allow gap-less audio, playlists to proceed without the intervention of a control point and to function correctly under the manipulation of multiple control points.<br />
<br />
The ohPlaylist is a list of media associated with a unique ID. Media is defined by its URI and metadata. A control point is required to keep in memory the current list of playlist IDs. This list of IDs can then be used to list the media in the order of play, obtain the metadata and manipulate the list.<br />
<br />
The Playlist service provides the API that allow control points to manipulate, keep track of playlist changes and control playback.<br />
<br />
ohSongcast<br />
<br />
<<to do>><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
of either of these two concepts so a control point can only provide a user with a flat list of UPnP AV products in the home. Whilst this might work reasonably well for a user with a single UPnP AV product it is far from ideal when they have multiple UPnP AV products.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
In the UPnP AV system architecture the control point holds all the information about the sequence of URIs that a media renderer will play. When there are multiple control points on the network there is no way for them all to have a common understanding of what a media renderer's sequence of URIs is. This results in each control point having its own, conflicting, understanding of a media renderer's state and when the current URI stops playing it becomes a race between the control points to set what they each believe to be the next URI.<br />
<br />
<br />
<br />
<br />
<br />
<br />
Problem 4: No support for synchronised playback across products<br />
<br />
The UPnP AV standard does not provide any solution to being able to synchronise playback across products.<br />
<br />
<br />
The ohMedia standard solves this deficiency by storing the user created playlist on the media renderer. This means that an ohMedia media renderer can play a user created playlist without the need for a control point to be switched on.<br />
<br />
The ohMedia standard solves this deficiency by moving the state of a media renderer from the control point into the media renderer. This means that all control points can now share a common understanding of what a media renderer's current state is.<br />
<br />
The ohMedia standard solves this problem by storing the playlist on the media renderer. This allows the ohMedia media renderer can start playback of the next URI immediately after the current URI has finished playing.<br />
<br />
The ohMedia standard solves the deficiency with ohSongcast. ohSongcast is an open network protocol that allows audio synchronisation between products that implement the ohSongcast protocol.<br />
<br />
The ohMedia standard solves this deficiency through ohTopology. ohTopology defines how products are found on the network, how products are grouped together and how the grouped products are connected together.<br />
<br />
How It Works<br />
<br />
The ohMedia standard uses the same playback architecture as used in the UPnP AV standard. The architecture is commonly known as the 3 box model. The 3 boxes in the 3 box model are, Media Renderer, Media Server and Control Point. The three components each work together to perform the task of playing back media. The media server contains the content available to a user. The user interacts with the control point's user interface to search and select the desired content on the media server and then to select the media renderer to playback the desired content. Playback of the content is achieved by out of band communication between the media server and media renderer, the control point is no involved.</div>Joshhhttp://wiki.openhome.org/wiki/Oh:OverviewOh:Overview2011-12-15T14:56:47Z<p>Joshh: /* ohDownload */</p>
<hr />
<div>The adoption of broadband internet and the proliferation of wifi-connected devices such as smartphones, web tablets, and netbooks has resulted in the computer network becoming a standard feature of the modern home. But there are a number of ways in which the modern family is yet to realize the full benefit of this home networking revolution.<br />
<br />
OpenHome is an independent body committed to redressing this through the design, implementation, and promotion of open standards. It stimulates innovation by transforming the home network into a rich environment for applications that fit with the way families live.<br />
<br />
= [[OhOs|ohOs]] =<br />
<br />
Users of personal computers and portable computing devices are familiar with the process of installing applications according to their own personal tastes or needs. But there are a number of applications that do not fit neatly into this pattern of deployment and use.<br />
<br />
The OpenHome Operating System, [[OhOs|ohOs]], fills this gap by providing a place to deploy software that is for use not only by a single individual but by all family members. And in doing so [[OhOs|ohOs]] opens the way for applications that:<br />
<br />
* Allow the family to access and control a wide range of domestic appliances, such as lights, media players, and security cameras, organized from the perspective of the home as a whole.<br />
<br />
[Illustration of someone controlling lights using an iPad-like device]<br />
<br />
* Allow the family to view, and maintain structured information that is most meaningful in the context of the home, such as shared calendars, family address books, and photo albums.<br />
<br />
[Illustration of someone putting car servicing appointment into a family calendar using an iPad-like device]<br />
<br />
* Provide opportunities for creativity and fun for the family as a whole. <br />
<br />
[Illustration of family members each with their own iPad or iPhone jointly doing a crossword?]<br />
<br />
* Provide rich, user-friendly control over otherwise technically challenging networking facilities, such as parental control over internet access.<br />
<br />
[Illustration of a child unable to access the internet from their bedroom at night with happy care-free parents downstairs?]<br />
<br />
* Provide a trusted domain for archiving and messaging that keeps all information safely within the boundary of the domestic network.<br />
<br />
[Illustration of someone storing the code for a safe using an iPhone-like device?]<br />
<br />
[[OhOs|ohOs]] achieves this by providing lightweight, always-on, networked computing for applications that can be installed from a readily accessible app store and used by any web-browser-enabled device.<br />
<br />
= [[OhMedia|ohMedia]] =<br />
<br />
Networked audio was arguably the first popular application for the networked home. The idea of storing a digital music collection on a central server and playing it on a range of networked audio devices has begun to take hold. Add to this the idea that choosing and controlling that music should be possible from wirelessly networked mobile devices and we have the basic architecture for home audio that was first outlined in the UPnP AV specification.<br />
<br />
[Illustration of networked audio home with music being enjoyed in different rooms and being controlled by iPad-like devices]<br />
<br />
However, UPnP AV contains serious oversights and flaws that prevent it from delivering an appealing networked music experience throughout the home.<br />
<br />
OpenHome addresses this by creating a set of open extensions to UPnP AV that were designed from the ground up from a home-centered perspective. Furthermore, OpenHome goes beyond UPnP AV by developing completely new network standards, such as Songcast, which deliver additional home-centered functionality. More details are avaliable [[OhMedia|here]].<br />
<br />
= [[Oh:Downloads|ohDownload]] =<br />
<br />
OpenHome maintains that open standards are best developed in parallel with real-world implementations of those standards. This ensures that they are both fit for use and immediately available for use.<br />
<br />
[Possible illustration of person in ivory tower dreaming of ridiculous fantastical car, and person on the ground dreaming of really good car]<br />
<br />
In pursuit of this principle, OpenHome publishes an ever-growing suite of high quality, open software that is actively maintained and already proven in successful commercial products.<br />
<br />
This includes:<br />
<br />
* [[OhNet|ohNet]], the OpenHome networking stack, which facilitates the creation of service-oriented, SOAP-based networking software with inherent UPnP support.<br />
<br />
* [[OhSongcast|ohSongcast]], which implements OpenHome standards for one-to-many transmission of audio around a home network<br />
<br />
* [[OhNetworkMonitor|ohNetworkMonitor]], which provides facilities for troubleshooting home networking problems<br />
<br />
OpenHome software may be downloaded [[Oh:Downloads|here]].<br />
<br />
__NOTOC__</div>Joshhhttp://wiki.openhome.org/wiki/Oh:OverviewOh:Overview2011-12-15T14:48:38Z<p>Joshh: /* ohMedia */</p>
<hr />
<div>The adoption of broadband internet and the proliferation of wifi-connected devices such as smartphones, web tablets, and netbooks has resulted in the computer network becoming a standard feature of the modern home. But there are a number of ways in which the modern family is yet to realize the full benefit of this home networking revolution.<br />
<br />
OpenHome is an independent body committed to redressing this through the design, implementation, and promotion of open standards. It stimulates innovation by transforming the home network into a rich environment for applications that fit with the way families live.<br />
<br />
= [[OhOs|ohOs]] =<br />
<br />
Users of personal computers and portable computing devices are familiar with the process of installing applications according to their own personal tastes or needs. But there are a number of applications that do not fit neatly into this pattern of deployment and use.<br />
<br />
The OpenHome Operating System, [[OhOs|ohOs]], fills this gap by providing a place to deploy software that is for use not only by a single individual but by all family members. And in doing so [[OhOs|ohOs]] opens the way for applications that:<br />
<br />
* Allow the family to access and control a wide range of domestic appliances, such as lights, media players, and security cameras, organized from the perspective of the home as a whole.<br />
<br />
[Illustration of someone controlling lights using an iPad-like device]<br />
<br />
* Allow the family to view, and maintain structured information that is most meaningful in the context of the home, such as shared calendars, family address books, and photo albums.<br />
<br />
[Illustration of someone putting car servicing appointment into a family calendar using an iPad-like device]<br />
<br />
* Provide opportunities for creativity and fun for the family as a whole. <br />
<br />
[Illustration of family members each with their own iPad or iPhone jointly doing a crossword?]<br />
<br />
* Provide rich, user-friendly control over otherwise technically challenging networking facilities, such as parental control over internet access.<br />
<br />
[Illustration of a child unable to access the internet from their bedroom at night with happy care-free parents downstairs?]<br />
<br />
* Provide a trusted domain for archiving and messaging that keeps all information safely within the boundary of the domestic network.<br />
<br />
[Illustration of someone storing the code for a safe using an iPhone-like device?]<br />
<br />
[[OhOs|ohOs]] achieves this by providing lightweight, always-on, networked computing for applications that can be installed from a readily accessible app store and used by any web-browser-enabled device.<br />
<br />
= [[OhMedia|ohMedia]] =<br />
<br />
Networked audio was arguably the first popular application for the networked home. The idea of storing a digital music collection on a central server and playing it on a range of networked audio devices has begun to take hold. Add to this the idea that choosing and controlling that music should be possible from wirelessly networked mobile devices and we have the basic architecture for home audio that was first outlined in the UPnP AV specification.<br />
<br />
[Illustration of networked audio home with music being enjoyed in different rooms and being controlled by iPad-like devices]<br />
<br />
However, UPnP AV contains serious oversights and flaws that prevent it from delivering an appealing networked music experience throughout the home.<br />
<br />
OpenHome addresses this by creating a set of open extensions to UPnP AV that were designed from the ground up from a home-centered perspective. Furthermore, OpenHome goes beyond UPnP AV by developing completely new network standards, such as Songcast, which deliver additional home-centered functionality. More details are avaliable [[OhMedia|here]].<br />
<br />
= [[Oh:Downloads|ohDownload]] =<br />
<br />
OpenHome maintains that open standards are best developed in parallel with real-world implementations of those standards. This ensures that they are both fit for use and immediately available for use.<br />
<br />
[Possible illustration of person in ivory tower dreaming of ridiculous fantastical car, and person on the ground dreaming of really good car]<br />
<br />
In pursuit of this principle, OpenHome publishes an ever-growing suite of high quality, open software that is actively maintained and already proven in successful commercial products.<br />
<br />
This includes:<br />
<br />
* [[OhNet|ohNet]], the OpenHome networking stack, which facilitates the creation of service-oriented, SOAP-based networking software with inherent UPnP support.<br />
<br />
* ohSongcast, which implements OpenHome standards for one-to-many transmission of audio around a home network<br />
<br />
* ohNetworkMonitor, which provides facilities for troubleshooting home networking problems<br />
<br />
OpenHome software may be downloaded [[Oh:Downloads|here]].<br />
<br />
__NOTOC__</div>Joshhhttp://wiki.openhome.org/wiki/Oh:OverviewOh:Overview2011-12-15T14:45:48Z<p>Joshh: /* ohDownloads */</p>
<hr />
<div>The adoption of broadband internet and the proliferation of wifi-connected devices such as smartphones, web tablets, and netbooks has resulted in the computer network becoming a standard feature of the modern home. But there are a number of ways in which the modern family is yet to realize the full benefit of this home networking revolution.<br />
<br />
OpenHome is an independent body committed to redressing this through the design, implementation, and promotion of open standards. It stimulates innovation by transforming the home network into a rich environment for applications that fit with the way families live.<br />
<br />
= [[OhOs|ohOs]] =<br />
<br />
Users of personal computers and portable computing devices are familiar with the process of installing applications according to their own personal tastes or needs. But there are a number of applications that do not fit neatly into this pattern of deployment and use.<br />
<br />
The OpenHome Operating System, [[OhOs|ohOs]], fills this gap by providing a place to deploy software that is for use not only by a single individual but by all family members. And in doing so [[OhOs|ohOs]] opens the way for applications that:<br />
<br />
* Allow the family to access and control a wide range of domestic appliances, such as lights, media players, and security cameras, organized from the perspective of the home as a whole.<br />
<br />
[Illustration of someone controlling lights using an iPad-like device]<br />
<br />
* Allow the family to view, and maintain structured information that is most meaningful in the context of the home, such as shared calendars, family address books, and photo albums.<br />
<br />
[Illustration of someone putting car servicing appointment into a family calendar using an iPad-like device]<br />
<br />
* Provide opportunities for creativity and fun for the family as a whole. <br />
<br />
[Illustration of family members each with their own iPad or iPhone jointly doing a crossword?]<br />
<br />
* Provide rich, user-friendly control over otherwise technically challenging networking facilities, such as parental control over internet access.<br />
<br />
[Illustration of a child unable to access the internet from their bedroom at night with happy care-free parents downstairs?]<br />
<br />
* Provide a trusted domain for archiving and messaging that keeps all information safely within the boundary of the domestic network.<br />
<br />
[Illustration of someone storing the code for a safe using an iPhone-like device?]<br />
<br />
[[OhOs|ohOs]] achieves this by providing lightweight, always-on, networked computing for applications that can be installed from a readily accessible app store and used by any web-browser-enabled device.<br />
<br />
= ohMedia =<br />
<br />
Networked audio was arguably the first popular application for the networked home. The idea of storing a digital music collection on a central server and playing it on a range of networked audio devices has begun to take hold. Add to this the idea that choosing and controlling that music should be possible from wirelessly networked mobile devices and we have the basic architecture for home audio that was first outlined in the UPnP AV specification.<br />
<br />
[Illustration of networked audio home with music being enjoyed in different rooms and being controlled by iPad-like devices]<br />
<br />
However, UPnP AV contains serious oversights and flaws that prevent it from delivering an appealing networked music experience throughout the home.<br />
<br />
OpenHome addresses this by creating a set of open extensions to UPnP AV that were designed from the ground up from a home-centered perspective. Furthermore, OpenHome goes beyond UPnP AV by developing completely new network standards, such as Songcast, which deliver additional home-centered functionality. More details are avaliable here.<br />
<br />
= [[Oh:Downloads|ohDownload]] =<br />
<br />
OpenHome maintains that open standards are best developed in parallel with real-world implementations of those standards. This ensures that they are both fit for use and immediately available for use.<br />
<br />
[Possible illustration of person in ivory tower dreaming of ridiculous fantastical car, and person on the ground dreaming of really good car]<br />
<br />
In pursuit of this principle, OpenHome publishes an ever-growing suite of high quality, open software that is actively maintained and already proven in successful commercial products.<br />
<br />
This includes:<br />
<br />
* [[OhNet|ohNet]], the OpenHome networking stack, which facilitates the creation of service-oriented, SOAP-based networking software with inherent UPnP support.<br />
<br />
* ohSongcast, which implements OpenHome standards for one-to-many transmission of audio around a home network<br />
<br />
* ohNetworkMonitor, which provides facilities for troubleshooting home networking problems<br />
<br />
OpenHome software may be downloaded [[Oh:Downloads|here]].<br />
<br />
__NOTOC__</div>Joshhhttp://wiki.openhome.org/wiki/Oh:OverviewOh:Overview2011-12-15T14:45:30Z<p>Joshh: /* ohDownload */</p>
<hr />
<div>The adoption of broadband internet and the proliferation of wifi-connected devices such as smartphones, web tablets, and netbooks has resulted in the computer network becoming a standard feature of the modern home. But there are a number of ways in which the modern family is yet to realize the full benefit of this home networking revolution.<br />
<br />
OpenHome is an independent body committed to redressing this through the design, implementation, and promotion of open standards. It stimulates innovation by transforming the home network into a rich environment for applications that fit with the way families live.<br />
<br />
= [[OhOs|ohOs]] =<br />
<br />
Users of personal computers and portable computing devices are familiar with the process of installing applications according to their own personal tastes or needs. But there are a number of applications that do not fit neatly into this pattern of deployment and use.<br />
<br />
The OpenHome Operating System, [[OhOs|ohOs]], fills this gap by providing a place to deploy software that is for use not only by a single individual but by all family members. And in doing so [[OhOs|ohOs]] opens the way for applications that:<br />
<br />
* Allow the family to access and control a wide range of domestic appliances, such as lights, media players, and security cameras, organized from the perspective of the home as a whole.<br />
<br />
[Illustration of someone controlling lights using an iPad-like device]<br />
<br />
* Allow the family to view, and maintain structured information that is most meaningful in the context of the home, such as shared calendars, family address books, and photo albums.<br />
<br />
[Illustration of someone putting car servicing appointment into a family calendar using an iPad-like device]<br />
<br />
* Provide opportunities for creativity and fun for the family as a whole. <br />
<br />
[Illustration of family members each with their own iPad or iPhone jointly doing a crossword?]<br />
<br />
* Provide rich, user-friendly control over otherwise technically challenging networking facilities, such as parental control over internet access.<br />
<br />
[Illustration of a child unable to access the internet from their bedroom at night with happy care-free parents downstairs?]<br />
<br />
* Provide a trusted domain for archiving and messaging that keeps all information safely within the boundary of the domestic network.<br />
<br />
[Illustration of someone storing the code for a safe using an iPhone-like device?]<br />
<br />
[[OhOs|ohOs]] achieves this by providing lightweight, always-on, networked computing for applications that can be installed from a readily accessible app store and used by any web-browser-enabled device.<br />
<br />
= ohMedia =<br />
<br />
Networked audio was arguably the first popular application for the networked home. The idea of storing a digital music collection on a central server and playing it on a range of networked audio devices has begun to take hold. Add to this the idea that choosing and controlling that music should be possible from wirelessly networked mobile devices and we have the basic architecture for home audio that was first outlined in the UPnP AV specification.<br />
<br />
[Illustration of networked audio home with music being enjoyed in different rooms and being controlled by iPad-like devices]<br />
<br />
However, UPnP AV contains serious oversights and flaws that prevent it from delivering an appealing networked music experience throughout the home.<br />
<br />
OpenHome addresses this by creating a set of open extensions to UPnP AV that were designed from the ground up from a home-centered perspective. Furthermore, OpenHome goes beyond UPnP AV by developing completely new network standards, such as Songcast, which deliver additional home-centered functionality. More details are avaliable here.<br />
<br />
= [[Oh:Downloads|ohDownloads]] =<br />
<br />
OpenHome maintains that open standards are best developed in parallel with real-world implementations of those standards. This ensures that they are both fit for use and immediately available for use.<br />
<br />
[Possible illustration of person in ivory tower dreaming of ridiculous fantastical car, and person on the ground dreaming of really good car]<br />
<br />
In pursuit of this principle, OpenHome publishes an ever-growing suite of high quality, open software that is actively maintained and already proven in successful commercial products.<br />
<br />
This includes:<br />
<br />
* [[OhNet|ohNet]], the OpenHome networking stack, which facilitates the creation of service-oriented, SOAP-based networking software with inherent UPnP support.<br />
<br />
* ohSongcast, which implements OpenHome standards for one-to-many transmission of audio around a home network<br />
<br />
* ohNetworkMonitor, which provides facilities for troubleshooting home networking problems<br />
<br />
OpenHome software may be downloaded [[Oh:Downloads|here]].<br />
<br />
__NOTOC__</div>Joshhhttp://wiki.openhome.org/wiki/Oh:OverviewOh:Overview2011-12-15T14:44:59Z<p>Joshh: /* ohDownload */</p>
<hr />
<div>The adoption of broadband internet and the proliferation of wifi-connected devices such as smartphones, web tablets, and netbooks has resulted in the computer network becoming a standard feature of the modern home. But there are a number of ways in which the modern family is yet to realize the full benefit of this home networking revolution.<br />
<br />
OpenHome is an independent body committed to redressing this through the design, implementation, and promotion of open standards. It stimulates innovation by transforming the home network into a rich environment for applications that fit with the way families live.<br />
<br />
= [[OhOs|ohOs]] =<br />
<br />
Users of personal computers and portable computing devices are familiar with the process of installing applications according to their own personal tastes or needs. But there are a number of applications that do not fit neatly into this pattern of deployment and use.<br />
<br />
The OpenHome Operating System, [[OhOs|ohOs]], fills this gap by providing a place to deploy software that is for use not only by a single individual but by all family members. And in doing so [[OhOs|ohOs]] opens the way for applications that:<br />
<br />
* Allow the family to access and control a wide range of domestic appliances, such as lights, media players, and security cameras, organized from the perspective of the home as a whole.<br />
<br />
[Illustration of someone controlling lights using an iPad-like device]<br />
<br />
* Allow the family to view, and maintain structured information that is most meaningful in the context of the home, such as shared calendars, family address books, and photo albums.<br />
<br />
[Illustration of someone putting car servicing appointment into a family calendar using an iPad-like device]<br />
<br />
* Provide opportunities for creativity and fun for the family as a whole. <br />
<br />
[Illustration of family members each with their own iPad or iPhone jointly doing a crossword?]<br />
<br />
* Provide rich, user-friendly control over otherwise technically challenging networking facilities, such as parental control over internet access.<br />
<br />
[Illustration of a child unable to access the internet from their bedroom at night with happy care-free parents downstairs?]<br />
<br />
* Provide a trusted domain for archiving and messaging that keeps all information safely within the boundary of the domestic network.<br />
<br />
[Illustration of someone storing the code for a safe using an iPhone-like device?]<br />
<br />
[[OhOs|ohOs]] achieves this by providing lightweight, always-on, networked computing for applications that can be installed from a readily accessible app store and used by any web-browser-enabled device.<br />
<br />
= ohMedia =<br />
<br />
Networked audio was arguably the first popular application for the networked home. The idea of storing a digital music collection on a central server and playing it on a range of networked audio devices has begun to take hold. Add to this the idea that choosing and controlling that music should be possible from wirelessly networked mobile devices and we have the basic architecture for home audio that was first outlined in the UPnP AV specification.<br />
<br />
[Illustration of networked audio home with music being enjoyed in different rooms and being controlled by iPad-like devices]<br />
<br />
However, UPnP AV contains serious oversights and flaws that prevent it from delivering an appealing networked music experience throughout the home.<br />
<br />
OpenHome addresses this by creating a set of open extensions to UPnP AV that were designed from the ground up from a home-centered perspective. Furthermore, OpenHome goes beyond UPnP AV by developing completely new network standards, such as Songcast, which deliver additional home-centered functionality. More details are avaliable here.<br />
<br />
= [[Oh:Download|ohDownload]] =<br />
<br />
OpenHome maintains that open standards are best developed in parallel with real-world implementations of those standards. This ensures that they are both fit for use and immediately available for use.<br />
<br />
[Possible illustration of person in ivory tower dreaming of ridiculous fantastical car, and person on the ground dreaming of really good car]<br />
<br />
In pursuit of this principle, OpenHome publishes an ever-growing suite of high quality, open software that is actively maintained and already proven in successful commercial products.<br />
<br />
This includes:<br />
<br />
* [[OhNet|ohNet]], the OpenHome networking stack, which facilitates the creation of service-oriented, SOAP-based networking software with inherent UPnP support.<br />
<br />
* ohSongcast, which implements OpenHome standards for one-to-many transmission of audio around a home network<br />
<br />
* ohNetworkMonitor, which provides facilities for troubleshooting home networking problems<br />
<br />
OpenHome software may be downloaded [[Oh:Download|here]].<br />
<br />
__NOTOC__</div>Joshhhttp://wiki.openhome.org/wiki/OhOsOhOs2011-12-15T14:43:13Z<p>Joshh: </p>
<hr />
<div>ohOs is designed to be deployed onto a modern Operating System. Deployments are maintained for:<br />
* Windows x86/x64 desktop<br />
* Mac x64 desktop<br />
* Linux x86/x64 desktop<br />
* Linux ARM<br />
Linux ARM allows deployment on a [http://en.wikipedia.org/wiki/SheevaPlug plug computer]. The unobtrusive factor and low power requirements of these devices make them very well suited as the hosts for apps which should always be on.<br />
<br />
System architecture can be summarised as:<br />
<br />
[[File:ohOsOverviewArchDiagram.png|center]]<br />
<br />
ohOs hosts a number of applications (apps), each of which is always running. All code in ohOs is managed. This has the benefit of making applications portable across all platforms at no cost to the app developer. All code in ohOs is written in C#. Apps can be written in C# or other managed languages.<br />
<br />
Each ohOs app runs in its own process. Communication with the app’s user interface or with other apps occurs using service interface calls over the network. Service interfaces are typically presented as standard classes which internally use [[OhNet|ohNet]] to handle the invocation of a service function or notification of a change in a member variable.<br />
<br />
ohOs apps contain a web-based user interface, allowing users to access the apps on any control point without installing extra software. Each app is automatically supplied with a rudimentary web server which delivers the web UI. Apps are not required to generate complex html inside ohOs; instead they serve up JavaScript which uses the services exposed by the app to generate its UI client-side.<br />
<br />
Web UIs can use HTML5 features to provide an interface as graphically rich as native apps. While there should be no pressing need to write native control points, ohOs does allow this. In addition to C#, proxies for an app’s services can be generated in C or C++ (suitable for Apple’s iOS) or Java (suitable for Google’s Android).</div>Joshhhttp://wiki.openhome.org/wiki/Oh:OverviewOh:Overview2011-12-15T14:41:54Z<p>Joshh: /* ohDownload */</p>
<hr />
<div>The adoption of broadband internet and the proliferation of wifi-connected devices such as smartphones, web tablets, and netbooks has resulted in the computer network becoming a standard feature of the modern home. But there are a number of ways in which the modern family is yet to realize the full benefit of this home networking revolution.<br />
<br />
OpenHome is an independent body committed to redressing this through the design, implementation, and promotion of open standards. It stimulates innovation by transforming the home network into a rich environment for applications that fit with the way families live.<br />
<br />
= [[OhOs|ohOs]] =<br />
<br />
Users of personal computers and portable computing devices are familiar with the process of installing applications according to their own personal tastes or needs. But there are a number of applications that do not fit neatly into this pattern of deployment and use.<br />
<br />
The OpenHome Operating System, [[OhOs|ohOs]], fills this gap by providing a place to deploy software that is for use not only by a single individual but by all family members. And in doing so [[OhOs|ohOs]] opens the way for applications that:<br />
<br />
* Allow the family to access and control a wide range of domestic appliances, such as lights, media players, and security cameras, organized from the perspective of the home as a whole.<br />
<br />
[Illustration of someone controlling lights using an iPad-like device]<br />
<br />
* Allow the family to view, and maintain structured information that is most meaningful in the context of the home, such as shared calendars, family address books, and photo albums.<br />
<br />
[Illustration of someone putting car servicing appointment into a family calendar using an iPad-like device]<br />
<br />
* Provide opportunities for creativity and fun for the family as a whole. <br />
<br />
[Illustration of family members each with their own iPad or iPhone jointly doing a crossword?]<br />
<br />
* Provide rich, user-friendly control over otherwise technically challenging networking facilities, such as parental control over internet access.<br />
<br />
[Illustration of a child unable to access the internet from their bedroom at night with happy care-free parents downstairs?]<br />
<br />
* Provide a trusted domain for archiving and messaging that keeps all information safely within the boundary of the domestic network.<br />
<br />
[Illustration of someone storing the code for a safe using an iPhone-like device?]<br />
<br />
[[OhOs|ohOs]] achieves this by providing lightweight, always-on, networked computing for applications that can be installed from a readily accessible app store and used by any web-browser-enabled device.<br />
<br />
= ohMedia =<br />
<br />
Networked audio was arguably the first popular application for the networked home. The idea of storing a digital music collection on a central server and playing it on a range of networked audio devices has begun to take hold. Add to this the idea that choosing and controlling that music should be possible from wirelessly networked mobile devices and we have the basic architecture for home audio that was first outlined in the UPnP AV specification.<br />
<br />
[Illustration of networked audio home with music being enjoyed in different rooms and being controlled by iPad-like devices]<br />
<br />
However, UPnP AV contains serious oversights and flaws that prevent it from delivering an appealing networked music experience throughout the home.<br />
<br />
OpenHome addresses this by creating a set of open extensions to UPnP AV that were designed from the ground up from a home-centered perspective. Furthermore, OpenHome goes beyond UPnP AV by developing completely new network standards, such as Songcast, which deliver additional home-centered functionality. More details are avaliable here.<br />
<br />
= [[Oh:Downloads|ohDownload]] =<br />
<br />
OpenHome maintains that open standards are best developed in parallel with real-world implementations of those standards. This ensures that they are both fit for use and immediately available for use.<br />
<br />
[Possible illustration of person in ivory tower dreaming of ridiculous fantastical car, and person on the ground dreaming of really good car]<br />
<br />
In pursuit of this principle, OpenHome publishes an ever-growing suite of high quality, open software that is actively maintained and already proven in successful commercial products.<br />
<br />
This includes:<br />
<br />
* [[OhNet|ohNet]], the OpenHome networking stack, which facilitates the creation of service-oriented, SOAP-based networking software with inherent UPnP support.<br />
<br />
* ohSongcast, which implements OpenHome standards for one-to-many transmission of audio around a home network<br />
<br />
* ohNetworkMonitor, which provides facilities for troubleshooting home networking problems<br />
<br />
OpenHome software may be downloaded [[Oh:Downloads|here]].<br />
<br />
__NOTOC__</div>Joshhhttp://wiki.openhome.org/wiki/Oh:OverviewOh:Overview2011-12-15T14:40:08Z<p>Joshh: /* ohDownload */</p>
<hr />
<div>The adoption of broadband internet and the proliferation of wifi-connected devices such as smartphones, web tablets, and netbooks has resulted in the computer network becoming a standard feature of the modern home. But there are a number of ways in which the modern family is yet to realize the full benefit of this home networking revolution.<br />
<br />
OpenHome is an independent body committed to redressing this through the design, implementation, and promotion of open standards. It stimulates innovation by transforming the home network into a rich environment for applications that fit with the way families live.<br />
<br />
= [[OhOs|ohOs]] =<br />
<br />
Users of personal computers and portable computing devices are familiar with the process of installing applications according to their own personal tastes or needs. But there are a number of applications that do not fit neatly into this pattern of deployment and use.<br />
<br />
The OpenHome Operating System, [[OhOs|ohOs]], fills this gap by providing a place to deploy software that is for use not only by a single individual but by all family members. And in doing so [[OhOs|ohOs]] opens the way for applications that:<br />
<br />
* Allow the family to access and control a wide range of domestic appliances, such as lights, media players, and security cameras, organized from the perspective of the home as a whole.<br />
<br />
[Illustration of someone controlling lights using an iPad-like device]<br />
<br />
* Allow the family to view, and maintain structured information that is most meaningful in the context of the home, such as shared calendars, family address books, and photo albums.<br />
<br />
[Illustration of someone putting car servicing appointment into a family calendar using an iPad-like device]<br />
<br />
* Provide opportunities for creativity and fun for the family as a whole. <br />
<br />
[Illustration of family members each with their own iPad or iPhone jointly doing a crossword?]<br />
<br />
* Provide rich, user-friendly control over otherwise technically challenging networking facilities, such as parental control over internet access.<br />
<br />
[Illustration of a child unable to access the internet from their bedroom at night with happy care-free parents downstairs?]<br />
<br />
* Provide a trusted domain for archiving and messaging that keeps all information safely within the boundary of the domestic network.<br />
<br />
[Illustration of someone storing the code for a safe using an iPhone-like device?]<br />
<br />
[[OhOs|ohOs]] achieves this by providing lightweight, always-on, networked computing for applications that can be installed from a readily accessible app store and used by any web-browser-enabled device.<br />
<br />
= ohMedia =<br />
<br />
Networked audio was arguably the first popular application for the networked home. The idea of storing a digital music collection on a central server and playing it on a range of networked audio devices has begun to take hold. Add to this the idea that choosing and controlling that music should be possible from wirelessly networked mobile devices and we have the basic architecture for home audio that was first outlined in the UPnP AV specification.<br />
<br />
[Illustration of networked audio home with music being enjoyed in different rooms and being controlled by iPad-like devices]<br />
<br />
However, UPnP AV contains serious oversights and flaws that prevent it from delivering an appealing networked music experience throughout the home.<br />
<br />
OpenHome addresses this by creating a set of open extensions to UPnP AV that were designed from the ground up from a home-centered perspective. Furthermore, OpenHome goes beyond UPnP AV by developing completely new network standards, such as Songcast, which deliver additional home-centered functionality. More details are avaliable here.<br />
<br />
= ohDownload =<br />
<br />
OpenHome maintains that open standards are best developed in parallel with real-world implementations of those standards. This ensures that they are both fit for use and immediately available for use.<br />
<br />
[Possible illustration of person in ivory tower dreaming of ridiculous fantastical car, and person on the ground dreaming of really good car]<br />
<br />
In pursuit of this principle, OpenHome publishes an ever-growing suite of high quality, open software that is actively maintained and already proven in successful commercial products.<br />
<br />
This includes:<br />
<br />
* [[OhNet|ohNet]], the OpenHome networking stack, which facilitates the creation of service-oriented, SOAP-based networking software with inherent UPnP support.<br />
<br />
* ohSongcast, which implements OpenHome standards for one-to-many transmission of audio around a home network<br />
<br />
* ohNetworkMonitor, which provides facilities for troubleshooting home networking problems<br />
<br />
OpenHome software may be downloaded [http://www.openhome.org/wiki/Oh:Downloads here].<br />
<br />
__NOTOC__</div>Joshhhttp://wiki.openhome.org/wiki/Oh:OverviewOh:Overview2011-12-15T14:38:15Z<p>Joshh: /* ohOs */</p>
<hr />
<div>The adoption of broadband internet and the proliferation of wifi-connected devices such as smartphones, web tablets, and netbooks has resulted in the computer network becoming a standard feature of the modern home. But there are a number of ways in which the modern family is yet to realize the full benefit of this home networking revolution.<br />
<br />
OpenHome is an independent body committed to redressing this through the design, implementation, and promotion of open standards. It stimulates innovation by transforming the home network into a rich environment for applications that fit with the way families live.<br />
<br />
= [[OhOs|ohOs]] =<br />
<br />
Users of personal computers and portable computing devices are familiar with the process of installing applications according to their own personal tastes or needs. But there are a number of applications that do not fit neatly into this pattern of deployment and use.<br />
<br />
The OpenHome Operating System, [[OhOs|ohOs]], fills this gap by providing a place to deploy software that is for use not only by a single individual but by all family members. And in doing so [[OhOs|ohOs]] opens the way for applications that:<br />
<br />
* Allow the family to access and control a wide range of domestic appliances, such as lights, media players, and security cameras, organized from the perspective of the home as a whole.<br />
<br />
[Illustration of someone controlling lights using an iPad-like device]<br />
<br />
* Allow the family to view, and maintain structured information that is most meaningful in the context of the home, such as shared calendars, family address books, and photo albums.<br />
<br />
[Illustration of someone putting car servicing appointment into a family calendar using an iPad-like device]<br />
<br />
* Provide opportunities for creativity and fun for the family as a whole. <br />
<br />
[Illustration of family members each with their own iPad or iPhone jointly doing a crossword?]<br />
<br />
* Provide rich, user-friendly control over otherwise technically challenging networking facilities, such as parental control over internet access.<br />
<br />
[Illustration of a child unable to access the internet from their bedroom at night with happy care-free parents downstairs?]<br />
<br />
* Provide a trusted domain for archiving and messaging that keeps all information safely within the boundary of the domestic network.<br />
<br />
[Illustration of someone storing the code for a safe using an iPhone-like device?]<br />
<br />
[[OhOs|ohOs]] achieves this by providing lightweight, always-on, networked computing for applications that can be installed from a readily accessible app store and used by any web-browser-enabled device.<br />
<br />
= ohMedia =<br />
<br />
Networked audio was arguably the first popular application for the networked home. The idea of storing a digital music collection on a central server and playing it on a range of networked audio devices has begun to take hold. Add to this the idea that choosing and controlling that music should be possible from wirelessly networked mobile devices and we have the basic architecture for home audio that was first outlined in the UPnP AV specification.<br />
<br />
[Illustration of networked audio home with music being enjoyed in different rooms and being controlled by iPad-like devices]<br />
<br />
However, UPnP AV contains serious oversights and flaws that prevent it from delivering an appealing networked music experience throughout the home.<br />
<br />
OpenHome addresses this by creating a set of open extensions to UPnP AV that were designed from the ground up from a home-centered perspective. Furthermore, OpenHome goes beyond UPnP AV by developing completely new network standards, such as Songcast, which deliver additional home-centered functionality. More details are avaliable here.<br />
<br />
= ohDownload =<br />
<br />
OpenHome maintains that open standards are best developed in parallel with real-world implementations of those standards. This ensures that they are both fit for use and immediately available for use.<br />
<br />
[Possible illustration of person in ivory tower dreaming of ridiculous fantastical car, and person on the ground dreaming of really good car]<br />
<br />
In pursuit of this principle, OpenHome publishes an ever-growing suite of high quality, open software that is actively maintained and already proven in successful commercial products.<br />
<br />
This includes:<br />
<br />
* [http://www.openhome.org/wiki/OhNet ohNet], the OpenHome networking stack, which facilitates the creation of service-oriented, SOAP-based networking software with inherent UPnP support.<br />
<br />
* ohSongcast, which implements OpenHome standards for one-to-many transmission of audio around a home network<br />
<br />
* ohNetworkMonitor, which provides facilities for troubleshooting home networking problems<br />
<br />
OpenHome software may be downloaded [http://www.openhome.org/wiki/Oh:Downloads here].<br />
<br />
__NOTOC__</div>Joshhhttp://wiki.openhome.org/wiki/Oh:OverviewOh:Overview2011-12-15T14:37:50Z<p>Joshh: /* ohOs */</p>
<hr />
<div>The adoption of broadband internet and the proliferation of wifi-connected devices such as smartphones, web tablets, and netbooks has resulted in the computer network becoming a standard feature of the modern home. But there are a number of ways in which the modern family is yet to realize the full benefit of this home networking revolution.<br />
<br />
OpenHome is an independent body committed to redressing this through the design, implementation, and promotion of open standards. It stimulates innovation by transforming the home network into a rich environment for applications that fit with the way families live.<br />
<br />
= [[OhOs|ohOs]] =<br />
<br />
Users of personal computers and portable computing devices are familiar with the process of installing applications according to their own personal tastes or needs. But there are a number of applications that do not fit neatly into this pattern of deployment and use.<br />
<br />
The OpenHome Operating System, [[OhOs|ohOs]], fills this gap by providing a place to deploy software that is for use not only by a single individual but by all family members. And in doing so [[OhOs|ohOs]] opens the way for applications that:<br />
<br />
* Allow the family to access and control a wide range of domestic appliances, such as lights, media players, and security cameras, organized from the perspective of the home as a whole.<br />
<br />
[Illustration of someone controlling lights using an iPad-like device]<br />
<br />
* Allow the family to view, and maintain structured information that is most meaningful in the context of the home, such as shared calendars, family address books, and photo albums.<br />
<br />
[Illustration of someone putting car servicing appointment into a family calendar using an iPad-like device]<br />
<br />
* Provide opportunities for creativity and fun for the family as a whole. <br />
<br />
[Illustration of family members each with their own iPad or iPhone jointly doing a crossword?]<br />
<br />
* Provide rich, user-friendly control over otherwise technically challenging networking facilities, such as parental control over internet access.<br />
<br />
[Illustration of a child unable to access the internet from their bedroom at night with happy care-free parents downstairs?]<br />
<br />
* Provide a trusted domain for archiving and messaging that keeps all information safely within the boundary of the domestic network.<br />
<br />
[Illustration of someone storing the code for a safe using an iPhone-like device?]<br />
<br />
[http://www.openhome.org/wiki/OhOs ohOs] achieves this by providing lightweight, always-on, networked computing for applications that can be installed from a readily accessible app store and used by any web-browser-enabled device.<br />
<br />
= ohMedia =<br />
<br />
Networked audio was arguably the first popular application for the networked home. The idea of storing a digital music collection on a central server and playing it on a range of networked audio devices has begun to take hold. Add to this the idea that choosing and controlling that music should be possible from wirelessly networked mobile devices and we have the basic architecture for home audio that was first outlined in the UPnP AV specification.<br />
<br />
[Illustration of networked audio home with music being enjoyed in different rooms and being controlled by iPad-like devices]<br />
<br />
However, UPnP AV contains serious oversights and flaws that prevent it from delivering an appealing networked music experience throughout the home.<br />
<br />
OpenHome addresses this by creating a set of open extensions to UPnP AV that were designed from the ground up from a home-centered perspective. Furthermore, OpenHome goes beyond UPnP AV by developing completely new network standards, such as Songcast, which deliver additional home-centered functionality. More details are avaliable here.<br />
<br />
= ohDownload =<br />
<br />
OpenHome maintains that open standards are best developed in parallel with real-world implementations of those standards. This ensures that they are both fit for use and immediately available for use.<br />
<br />
[Possible illustration of person in ivory tower dreaming of ridiculous fantastical car, and person on the ground dreaming of really good car]<br />
<br />
In pursuit of this principle, OpenHome publishes an ever-growing suite of high quality, open software that is actively maintained and already proven in successful commercial products.<br />
<br />
This includes:<br />
<br />
* [http://www.openhome.org/wiki/OhNet ohNet], the OpenHome networking stack, which facilitates the creation of service-oriented, SOAP-based networking software with inherent UPnP support.<br />
<br />
* ohSongcast, which implements OpenHome standards for one-to-many transmission of audio around a home network<br />
<br />
* ohNetworkMonitor, which provides facilities for troubleshooting home networking problems<br />
<br />
OpenHome software may be downloaded [http://www.openhome.org/wiki/Oh:Downloads here].<br />
<br />
__NOTOC__</div>Joshhhttp://wiki.openhome.org/wiki/Oh:OverviewOh:Overview2011-12-15T14:36:57Z<p>Joshh: /* ohOs */</p>
<hr />
<div>The adoption of broadband internet and the proliferation of wifi-connected devices such as smartphones, web tablets, and netbooks has resulted in the computer network becoming a standard feature of the modern home. But there are a number of ways in which the modern family is yet to realize the full benefit of this home networking revolution.<br />
<br />
OpenHome is an independent body committed to redressing this through the design, implementation, and promotion of open standards. It stimulates innovation by transforming the home network into a rich environment for applications that fit with the way families live.<br />
<br />
= ohOs =<br />
<br />
Users of personal computers and portable computing devices are familiar with the process of installing applications according to their own personal tastes or needs. But there are a number of applications that do not fit neatly into this pattern of deployment and use.<br />
<br />
The OpenHome Operating System, [[OhOs|ohOs]], fills this gap by providing a place to deploy software that is for use not only by a single individual but by all family members. And in doing so [[OhOs|ohOs]] opens the way for applications that:<br />
<br />
* Allow the family to access and control a wide range of domestic appliances, such as lights, media players, and security cameras, organized from the perspective of the home as a whole.<br />
<br />
[Illustration of someone controlling lights using an iPad-like device]<br />
<br />
* Allow the family to view, and maintain structured information that is most meaningful in the context of the home, such as shared calendars, family address books, and photo albums.<br />
<br />
[Illustration of someone putting car servicing appointment into a family calendar using an iPad-like device]<br />
<br />
* Provide opportunities for creativity and fun for the family as a whole. <br />
<br />
[Illustration of family members each with their own iPad or iPhone jointly doing a crossword?]<br />
<br />
* Provide rich, user-friendly control over otherwise technically challenging networking facilities, such as parental control over internet access.<br />
<br />
[Illustration of a child unable to access the internet from their bedroom at night with happy care-free parents downstairs?]<br />
<br />
* Provide a trusted domain for archiving and messaging that keeps all information safely within the boundary of the domestic network.<br />
<br />
[Illustration of someone storing the code for a safe using an iPhone-like device?]<br />
<br />
[http://www.openhome.org/wiki/OhOs ohOs] achieves this by providing lightweight, always-on, networked computing for applications that can be installed from a readily accessible app store and used by any web-browser-enabled device.<br />
<br />
= ohMedia =<br />
<br />
Networked audio was arguably the first popular application for the networked home. The idea of storing a digital music collection on a central server and playing it on a range of networked audio devices has begun to take hold. Add to this the idea that choosing and controlling that music should be possible from wirelessly networked mobile devices and we have the basic architecture for home audio that was first outlined in the UPnP AV specification.<br />
<br />
[Illustration of networked audio home with music being enjoyed in different rooms and being controlled by iPad-like devices]<br />
<br />
However, UPnP AV contains serious oversights and flaws that prevent it from delivering an appealing networked music experience throughout the home.<br />
<br />
OpenHome addresses this by creating a set of open extensions to UPnP AV that were designed from the ground up from a home-centered perspective. Furthermore, OpenHome goes beyond UPnP AV by developing completely new network standards, such as Songcast, which deliver additional home-centered functionality. More details are avaliable here.<br />
<br />
= ohDownload =<br />
<br />
OpenHome maintains that open standards are best developed in parallel with real-world implementations of those standards. This ensures that they are both fit for use and immediately available for use.<br />
<br />
[Possible illustration of person in ivory tower dreaming of ridiculous fantastical car, and person on the ground dreaming of really good car]<br />
<br />
In pursuit of this principle, OpenHome publishes an ever-growing suite of high quality, open software that is actively maintained and already proven in successful commercial products.<br />
<br />
This includes:<br />
<br />
* [http://www.openhome.org/wiki/OhNet ohNet], the OpenHome networking stack, which facilitates the creation of service-oriented, SOAP-based networking software with inherent UPnP support.<br />
<br />
* ohSongcast, which implements OpenHome standards for one-to-many transmission of audio around a home network<br />
<br />
* ohNetworkMonitor, which provides facilities for troubleshooting home networking problems<br />
<br />
OpenHome software may be downloaded [http://www.openhome.org/wiki/Oh:Downloads here].<br />
<br />
__NOTOC__</div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:VolumeServiceAv:Developer:VolumeService2011-05-05T14:13:56Z<p>Joshh: /* Volume Service Description (XML) */</p>
<hr />
<div>= Architecture Overview =<br />
The Volume Service provides a means of controlling various settings which affect the product's volume (signal amplitude) measured at the output channels. A product may have one or more output channels. Balance or Fade settings may result in different volumes at each output. In the Mute state, all output channels are reduced to zero volume. <br />
<br />
==Volume==<br />
Volume is an adjustable setting that controls the loudness of the audio at the output channels of the product. Volume can be set to an absolute value or incremented/decremented in single steps. The maximum Volume setting is defined by the current value of '''VolumeLimit'''. The minimum Volume setting is zero. If an attempt is made to set the Volume above VolumeLimit, the Volume will be set to the '''VolumLimit'''. If an attempt is made to set the Volume above '''VolumeMax''', an error will be reported.<br />
<br />
== Volume Limit ==<br />
VolumeLimit specifies the upper limit of the Volume. Any attempt to set Volume above the VolumeLimit will reset Volume to the value of VolumeLimit. If VolumeLimit is changed, Volume is checked and automatically reduced if necessary. The maximum VolumeLimit setting is defined by the '''VolumeMax''' Characteristic.<br />
<br />
==Balance==<br />
Balance is an adjustable setting that specifies the '''bias''' in volume between the '''left and right''' output channels of the product. Balance can be set to an absolute value or incremented/decremented in single steps. The maximum Balance setting is defined by the '''BalanceMax''' Characteristic. The minimum Balance setting is defined by ('''-BalanceMax''') .<br />
<br />
==Fade==<br />
Fade is an adjustable setting that specifies the '''bias''' in volume between the '''front and rear''' output channels of the products. Fade can be set to an absolute value or incremented/decremented in single steps. The maximum Fade setting is defined by the '''FadeMax''' Characteristic. The minimum Fade setting is defined by ('''-FadeMax''') .<br />
<br />
==Mute==<br />
Mute is an adjustable state that determines if the output channels of the product are muted or not. When muted, all output channels of the product are silent.<br />
<br />
<br />
==Characterstics==<br />
Each product has '''six''' read only values that define its volume Characteristics. <br />
====VolumeMax====<br />
VolumeMax defines the absolute maximum Volume setting.<br />
<br />
====VolumeUnity====<br />
VolumeUnity defines the value of Volume that will result in unity system gain (ie ''output amplitude'' = ''input amplitude'').<br />
<br />
====VolumeSteps====<br />
VolumeSteps defines the number of step increments required to increase the Volume from zero to VolumeMax.<br />
====VolumeMilliDbPerStep====<br />
VolumeMilliDbPerStep defines the size of each volume step in '''binary milli decibels''' (bmdB). [''1024bmdB = 1dB'']<br />
<br />
====BalanceMax====<br />
BalanceMax defines the maximum Balance setting. The minimum Balance setting is (-BalanceMax)<br />
====FadeMax====<br />
FadeMax defines the maximum Fade setting. The minimum Fade setting is (-FadeMax)<br />
<br />
<br />
=Actions=<br />
<br />
=== Volume ===<br />
The Volume action reports the current Volume setting.<br />
<br />
=== SetVolume===<br />
The SetVolume action provides a means of setting the Volume to an absolute value.<br />
<br />
=== Volume Inc===<br />
The VolumeInc action provides a means of increasing the Volume by 1.<br />
=== Volume Dec ===<br />
The VolumeDec action provides a means of decreasing the Volume by 1.<br />
=== VolumeLimit ===<br />
The VolumeLimit action reports the current VolumeLimit setting.<br />
=== Balance ===<br />
The Balance action reports the current Balance setting.<br />
=== SetBalance ===<br />
The SetBalance action provides a means of setting the Balance to a specific value.<br />
<br />
=== BalanceInc===<br />
The BalanceInc action provides a means of increasing the Balance by 1.<br />
=== BalanceDec ===<br />
The BalanceDec action provides a means of decreasing the Balance by 1.<br />
=== Fade ===<br />
The Fade action reports the current Fade setting of the product.<br />
==== SetFade ====<br />
The SetFade action provides a means of setting the Fade to a specific value.<br />
=== FadeInc===<br />
The FadeInc action provides a means of increasing the Fade by 1.<br />
<br />
=== FadeDec ===<br />
The FadeDec action provides a means of decreasing the Fade by 1.<br />
=== Mute ===<br />
The Mute action reports the current Mute state of the product.<br />
=== SetMute ===<br />
The SetMute action provides a means of setting the Mute state.<br />
<br />
=== Characteristics ===<br />
The Characteristics action returns all '''six''' characteristic values of the product.<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Volume<br />
Version : 1<br />
</code><br />
<br />
== Volume Service Description (XML) ==<br />
<code><br />
<?xml version="1.0" encoding="utf-8"?><br />
<scpd xmlns="urn:schemas-upnp-org:service-1-0"><br />
<specVersion><br />
<major>1</major><br />
<minor>0</minor><br />
</specVersion><br />
<actionList><br />
<action><br />
<name>Characteristics</name><br />
<argumentList><br />
<argument><br />
<name>VolumeMax</name><br />
<direction>out</direction><br />
<relatedStateVariable>VolumeMax</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>VolumeUnity</name><br />
<direction>out</direction><br />
<relatedStateVariable>VolumeUnity</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>VolumeSteps</name><br />
<direction>out</direction><br />
<relatedStateVariable>VolumeSteps</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>VolumeMilliDbPerStep</name><br />
<direction>out</direction><br />
<relatedStateVariable>VolumeMilliDbPerStep</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>BalanceMax</name><br />
<direction>out</direction><br />
<relatedStateVariable>BalanceMax</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>FadeMax</name><br />
<direction>out</direction><br />
<relatedStateVariable>FadeMax</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SetVolume</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Volume</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>VolumeInc</name><br />
</action><br />
<action><br />
<name>VolumeDec</name><br />
</action><br />
<action><br />
<name>Volume</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Volume</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SetBalance</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Balance</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>BalanceInc</name><br />
</action><br />
<action><br />
<name>BalanceDec</name><br />
</action><br />
<action><br />
<name>Balance</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Balance</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<br />
<action><br />
<name>SetFade</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Fade</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>FadeInc</name><br />
</action><br />
<action><br />
<name>FadeDec</name><br />
</action><br />
<action><br />
<name>Fade</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Fade</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SetMute</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Mute</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Mute</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Mute</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>VolumeLimit</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>VolumeLimit</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
</actionList><br />
<serviceStateTable><br />
<stateVariable sendEvents="yes"><br />
<name>Volume</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Mute</name><br />
<dataType>boolean</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Balance</name><br />
<dataType>i4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Fade</name><br />
<dataType>i4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>VolumeLimit</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>VolumeMax</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>VolumeUnity</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>VolumeSteps</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>VolumeMilliDbPerStep</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>BalanceMax</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>FadeMax</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
</serviceStateTable><br />
</scpd><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:TimeServiceAv:Developer:TimeService2011-05-05T14:13:35Z<p>Joshh: /* Time Service Description (XML) */</p>
<hr />
<div>= Architectural Overview =<br />
The Time service reports the duration of the currently playing track and the number of seconds so far played.<br />
<br />
This service is intentionally separated from the Info service. When a track is being played, this service delivers an event every second, which can overwhelm some primitive control points. The Time service is kept separate from the Info service so that control points can decide to subscribe to it independently.<br />
<br />
= Actions =<br />
==Time==<br />
This reports TrackCount, which increments each time a new track is played; Duration, which is the duration of the current track in seconds; and Seconds, which is the number of seconds so far played.<br />
<br />
TrackCount corresponds with TrackCount reported in the Info Service, but bears no relation to a Track Id or Preset Id reported from the [[Developer:Davaar:PlaylistService|Playlist Service]] or [[Developer:Davaar:RadioService|Radio Service]].<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Time<br />
Version : 1<br />
</code><br />
<br />
== Time Service Description (XML) ==<br />
<code><br />
<?xml version="1.0" encoding="utf-8"?><br />
<scpd xmlns="urn:schemas-upnp-org:service-1-0"><br />
<specVersion><br />
<major>1</major><br />
<minor>0</minor><br />
</specVersion><br />
<actionList><br />
<action><br />
<name>Time</name><br />
<argumentList><br />
<argument><br />
<name>TrackCount</name><br />
<direction>out</direction><br />
<relatedStateVariable>TrackCount</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Duration</name><br />
<direction>out</direction><br />
<relatedStateVariable>Duration</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Seconds</name><br />
<direction>out</direction><br />
<relatedStateVariable>Seconds</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
</actionList><br />
<serviceStateTable><br />
<stateVariable sendEvents="yes"><br />
<name>TrackCount</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Duration</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Seconds</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
</serviceStateTable><br />
</scpd><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:SenderServiceAv:Developer:SenderService2011-05-05T14:13:16Z<p>Joshh: /* Sender Service Description (XML) */</p>
<hr />
<div>= Architectural Overview =<br />
<br />
The Sender service indicates the presence of an OpenHome Av sender and provides information concerning that sender.<br />
<br />
An OpenHome Av sender broadcasts music on a network in a way that is playable by an OpenHome Av [[Developer:ReceiverService|receiver]].<br />
<br />
OpenHome senders should be discovered independently of the standard algorithm for discovering OpenHome products and sources. An independent search should be made for devices bearing the Sender service.<br />
<br />
= Actions =<br />
== Attributes ==<br />
Reports a space separated list of attributes that identify additional functionality that can be found on the same device as this Sender.<br />
<br />
Currently defined attributes are:<br />
<br />
* Info - this device reports on the current media using the Info service<br />
* Time - this device reports on the current media using the Time service<br />
<br />
== Audio == <br />
Reports whether audio is currently present on this sender.<br />
<br />
== Metadata ==<br />
Provides a representation of this audio item in DIDL-Lite format.<br />
<br />
== PresentationUrl ==<br />
Reports the Url of a presentation page for further information concerning the sender, or for controlling the sender in some application-specific way.<br />
<br />
If the sender has no presentation page, the PresentationUrl should be empty.<br />
<br />
== Status ==<br />
Reports the status of the sender (normally only for debugging purposes):<br />
<br />
* Sending - currently sending audio over the network<br />
* Ready - ready to send audio but no listeners<br />
* Blocked - audio from another sender detected on the same channel (mis-configuration)<br />
* Inactive - no audio source currently assigned to this sender<br />
* Disabled - sender disabled by user configuration<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Sender<br />
Version : 1<br />
</code><br />
<br />
== Sender Service Description (XML) ==<br />
<code><br />
<?xml version="1.0"?><br />
<scpd xmlns="urn:schemas-upnp-org:service-1-0"><br />
<specVersion><br />
<major>1</major><br />
<minor>0</minor><br />
</specVersion><br />
<br />
<actionList><br />
<action><br />
<name>PresentationUrl</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>PresentationUrl</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Metadata</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Metadata</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Audio</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Audio</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Status</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Status</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Attributes</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Attributes</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
</actionList><br />
<br />
<serviceStateTable><br />
<stateVariable sendEvents="yes"><br />
<name>PresentationUrl</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Metadata</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Audio</name><br />
<dataType>boolean</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Status</name><br />
<dataType>string</dataType><br />
<allowedValueList><br />
<allowedValue>Enabled</allowedValue><br />
<allowedValue>Disabled</allowedValue><br />
<allowedValue>Blocked</allowedValue><br />
</allowedValueList><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Attributes</name><br />
<dataType>string</dataType><br />
</stateVariable> <br />
</serviceStateTable><br />
</scpd><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:ReceiverServiceAv:Developer:ReceiverService2011-05-05T14:12:59Z<p>Joshh: /* Receiver Service Description (XML) */</p>
<hr />
<div>= Architectural Overview =<br />
<br />
The Receiver service provides the means for controlling a Receiver source. If a device's [[Developer:ProductService|Product service]] reports a source of type 'Receiver', then that device is guaranteed to bear the Receiver service.<br />
<br />
A receiver plays audio broadcast from a [[Developer:SenderService|sender]].<br />
<br />
= Actions =<br />
== Sender ==<br />
Report the Uri and Metadata of the sender this receiver is currently listening to.<br />
<br />
==SetSender==<br />
Set the Uri and Metadata of the sender to listen to.<br />
<br />
The Metadata must have originated from a device bearing the [[Developer:SenderService|Sender service]].<br />
<br />
The Uri must be the result of applying this receiver's ProtocolInfo to this Metadata.<br />
<br />
==ProtocolInfo==<br />
Report the receiver's protocol info.<br />
<br />
==TransportState==<br />
<br />
Report the current transport state, which can be: 'Playing', 'Paused', 'Stopped', or 'Buffering'.<br />
<br />
==Play==<br />
Play audio from the current sender<br />
<br />
==Stop==<br />
Stop playing audio from the current sender<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Receiver<br />
Version : 1<br />
</code><br />
<br />
== Receiver Service Description (XML) ==<br />
<code><br />
<?xml version="1.0"?><br />
<scpd xmlns="urn:schemas-upnp-org:service-1-0"><br />
<specVersion><br />
<major>1</major><br />
<minor>0</minor><br />
</specVersion><br />
<actionList><br />
<action><br />
<name>Play</name><br />
</action><br />
<action><br />
<name>Stop</name><br />
</action><br />
<action><br />
<name>SetSender</name><br />
<argumentList><br />
<argument><br />
<name>Uri</name><br />
<direction>in</direction><br />
<relatedStateVariable>Uri</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Metadata</name><br />
<direction>in</direction><br />
<relatedStateVariable>Metadata</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Sender</name><br />
<argumentList><br />
<argument><br />
<name>Uri</name><br />
<direction>out</direction><br />
<relatedStateVariable>Uri</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Metadata</name><br />
<direction>out</direction><br />
<relatedStateVariable>Metadata</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>ProtocolInfo</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProtocolInfo</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>TransportState</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>TransportState</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
</actionList><br />
<br />
<serviceStateTable><br />
<stateVariable sendEvents="yes"><br />
<name>Uri</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Metadata</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>TransportState</name><br />
<dataType>string</dataType><br />
<allowedValueList><br />
<allowedValue>Stopped</allowedValue><br />
<allowedValue>Playing</allowedValue><br />
<allowedValue>Waiting</allowedValue><br />
<allowedValue>Buffering</allowedValue><br />
</allowedValueList><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProtocolInfo</name><br />
<dataType>string</dataType><br />
</stateVariable> <br />
</serviceStateTable><br />
</scpd><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:RadioServiceAv:Developer:RadioService2011-05-05T14:12:36Z<p>Joshh: /* Radio Service Description (XML) */</p>
<hr />
<div>= Architectural Overview =<br />
The Radio service provides the means for controlling a Radio source. If a product's [[Developer:ProductService|Product Service]] reports a source of type 'Radio', then the device that bears that [[Developer:ProductService|Product Service]] is guaranteed to also bear the Radio service.<br />
<br />
The heart of the Radio service is the '''SetChannel''' action. Call '''SetChannel''' with a particular Uri and Metadata, then call '''Play''' and the media at the given Uri is played. If the media is an internet radio stream, it will play forever. If it is of finite length, it will play to the end and then stop.<br />
<br />
Call the '''Channel''' action to report the Uri and Metadata of the current Channel.<br />
<br />
The Radio Source also stores a list of channel presets. These can be presented to the user as a list of numbered channels that can easily be selected and played.<br />
<br />
This array of channel presets is accessed using an id array mechanism similar to that used in the [[Developer:PlaylistService|Playlist Service]]. The only difference is that the Radio service's id array is a constant length and may contain entries that are zero, which represent empty presets.<br />
<br />
= Actions =<br />
==Channel==<br />
Report the Uri and Metadata of the current Channel.<br />
<br />
==SetChannel==<br />
Set the Uri and Metadata of the current Channel.<br />
<br />
==IdArray==<br />
Report the current id array. The id array contains 100 presets, but this may change (see ChannelsMax).<br />
<br />
The IdArray is an ordered, constant length, array of ids. The first element contains the id for channel preset 1, the second element contains the id for channel Preset 2, etc. If an element is set to zero, then the corresponding channel preset is empty. <br />
<br />
This action also reports a Token, which can be used to quickly detect if the id array has changed since it was last read (see IdArrayChanged).<br />
<br />
==IdArrayChanged==<br />
Check to see if the id array has changed since gathering the specified IdArrayToken.<br />
This Token must have been previously collected from the IdArray action.<br />
<br />
This mechanism is provided specifically for clients unable to partake in UPnP eventing.<br />
<br />
==ChannelsMax==<br />
Report the maximum number of entries in the channel preset id array.<br />
<br />
==SetId==<br />
The the current Channel using the channel preset represented by the given Id, and using the provided Uri.<br />
<br />
It is usual for a Control Point to inspect the res elements of the Channel Metadata and select the appropriate Uri by matching to the renderer's ProtocolInfo.<br />
<br />
==Id==<br />
Report the Id of the current Channel if it is in the Channel Preset list. If the current Channel is not a channel preset, the Id reported is zero.<br />
<br />
==ProtocolInfo==<br />
Report the Radio Source protocol info.<br />
<br />
==Read==<br />
Given a channel preset Id, report its associated Metadata.<br />
<br />
==ReadList==<br />
Given a space separated list of channel preset Ids, report their associated Metadata.<br />
<br />
==TransportState==<br />
<br />
Report the current transport state, which can be: 'Playing', 'Paused', 'Stopped', or 'Buffering'.<br />
<br />
==Play==<br />
Play the current channel<br />
<br />
==Pause==<br />
Pause the current channel. This will be converted to Stop if the channel cannot be paused e.g. internet radio.<br />
<br />
==Stop==<br />
Stop the current Channel<br />
<br />
==SeekSecondsAbsolute==<br />
Seek to an absolute second within the current media. This is only available if the current media has a finite length.<br />
<br />
==SeekSecondsRelative==<br />
Seek to a relative second within the current media. This is only available if the current media has a finite length.<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Radio<br />
Version : 1<br />
</code><br />
<br />
== Radio Service Description (XML) ==<br />
<code><br />
<?xml version="1.0"?><br />
<scpd xmlns="urn:schemas-upnp-org:service-1-0"><br />
<specVersion><br />
<major>1</major><br />
<minor>0</minor><br />
</specVersion><br />
<actionList><br />
<action><br />
<name>Play</name><br />
</action><br />
<action><br />
<name>Pause</name><br />
</action><br />
<action><br />
<name>Stop</name><br />
</action><br />
<action><br />
<name>SeekSecondAbsolute</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Absolute</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SeekSecondRelative</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Relative</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Channel</name><br />
<argumentList><br />
<argument><br />
<name>Uri</name><br />
<direction>out</direction><br />
<relatedStateVariable>Uri</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Metadata</name><br />
<direction>out</direction><br />
<relatedStateVariable>Metadata</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SetChannel</name><br />
<argumentList><br />
<argument><br />
<name>Uri</name><br />
<direction>in</direction><br />
<relatedStateVariable>Uri</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Metadata</name><br />
<direction>in</direction><br />
<relatedStateVariable>Metadata</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>TransportState</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>TransportState</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Id</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Id</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SetId</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Id</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Uri</name><br />
<direction>in</direction><br />
<relatedStateVariable>Uri</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Read</name><br />
<argumentList><br />
<argument><br />
<name>Id</name><br />
<direction>in</direction><br />
<relatedStateVariable>Id</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Metadata</name><br />
<direction>out</direction><br />
<relatedStateVariable>Metadata</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>ReadList</name><br />
<argumentList><br />
<argument><br />
<name>IdList</name><br />
<direction>in</direction><br />
<relatedStateVariable>IdList</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>ChannelList</name><br />
<direction>out</direction><br />
<relatedStateVariable>ChannelList</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>IdArray</name><br />
<argumentList><br />
<argument><br />
<name>Token</name><br />
<direction>out</direction><br />
<relatedStateVariable>IdArrayToken</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Array</name><br />
<direction>out</direction><br />
<relatedStateVariable>IdArray</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>IdArrayChanged</name><br />
<argumentList><br />
<argument><br />
<name>Token</name><br />
<direction>in</direction><br />
<relatedStateVariable>IdArrayToken</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>IdArrayChanged</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>ChannelsMax</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>ChannelsMax</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>ProtocolInfo</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProtocolInfo</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
</actionList><br />
<br />
<serviceStateTable><br />
<stateVariable sendEvents="yes"><br />
<name>Uri</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Metadata</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>TransportState</name><br />
<dataType>string</dataType><br />
<allowedValueList><br />
<allowedValue>Stopped</allowedValue><br />
<allowedValue>Playing</allowedValue><br />
<allowedValue>Paused</allowedValue><br />
<allowedValue>Buffering</allowedValue><br />
</allowedValueList><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Id</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>IdArray</name><br />
<dataType>bin.base64</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ChannelsMax</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProtocolInfo</name><br />
<dataType>string</dataType><br />
</stateVariable> <br />
<stateVariable sendEvents="no"><br />
<name>Relative</name><br />
<dataType>i4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>Absolute</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>IdArrayToken</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>IdArrayChanged</name><br />
<dataType>boolean</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>IdList</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>ChannelList</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
</serviceStateTable><br />
</scpd><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:ProductServiceAv:Developer:ProductService2011-05-05T14:12:15Z<p>Joshh: /* Product Service Description (XML) */</p>
<hr />
<div>= Architectural Overview =<br />
<br />
The Product service contains basic information concerning a single product. It contains information about what kind of device it is: the model, manufacturer, its name, its room, and details concerning each source within the product. Other basic functionality such as control of the product's standby state are also included.<br />
<br />
It should be possible for a control point to create a complete map of the home by subscribing to the Product service of every device.<br />
<br />
== Network Presentation ==<br />
<br />
=== Attributes ===<br />
Every product has one or more attributes indicating additional features offered by that product beyond those provided by its sources<br />
<br />
=== Manufacturer ===<br />
There are '''four''' Manufacturer parameters; '''Name''', '''Info''', '''Url''' and '''ImageUri'''. They are all text strings.<br />
<br />
==== Name ====<br />
Name contains the Manufacturer name. Name is read only.<br />
<br />
==== Info ====<br />
Info contains more Manufacturer information. Info is read only.<br />
<br />
==== Url ====<br />
Url contains the Manufacturer website address. Url is read only.<br />
<br />
==== ImageUri ====<br />
ImageUri contains a link to the Manufacturer image (i.e. logo). ImageUri is read only.<br />
<br />
=== Model ===<br />
<br />
There are '''four''' Model parameters; '''Name''', '''Info''', '''Url''' and '''ImageUri'''.<br />
<br />
==== Name ====<br />
Name contains the Model name. Name is read only.<br />
==== Info ====<br />
Info contains more Model information. Info is read only. <br />
==== Url ====<br />
Url contains the Model website address. Url is read only.<br />
==== ImageUri ====<br />
ImageUri contains a link to the Model image (i.e. icon). ImageUri is read only.<br />
<br />
=== Product ===<br />
There are '''five''' Product parameters; '''Room''', '''Name''', '''Info''', '''Url''' and '''ImageUri'''. They are all text strings.<br />
<br />
==== Room ====<br />
This is the name of the room where the Product is located. Room is used to group the Product with other Products in the same physical room. The Upnp '''''Friendly Name''''' is derived by combining Room and Name in the format {'''''Room&nbsp;: Name'''''}. Products which are '''''Linked''''' always share the same Room name. Room is set to '''''Main Room''''' by default.<br />
<br />
==== Name ====<br />
This is the Product name. The Upnp '''''Friendly Name''''' is derived by combining Room and Name in the format {'''''Room&nbsp;: Name'''''}. By default the Name is the same as the Model. <br />
<br />
==== Info ====<br />
Info contains more Product information. Info is read only.<br />
<br />
==== Url ====<br />
Url contains the Product website address (i.e. UPnP presentation page). Url is read only.<br />
<br />
==== ImageUri ====<br />
ImageUri contains a link to the Product image (i.e. icon). ImageUri is read only.<br />
<br />
== Standby Control==<br />
<br />
=== Standby===<br />
This is the Standby state of the physical product. Standby can be changed using the SetStandby function. Products which are '''''Linked''''' always share the same Standby state. <br />
<br />
<br />
== Source Control ==<br />
<br />
=== Source List===<br />
The Product service maintains a list of all sources within the Product. The size of this list is fixed for each Product and reported by the SourceCount function. Each source can then be referenced by its unique source index* in the list. Only one source, and thus one index, can be active at any given time. When a new source is selected the previous source is automatically deactivated before activating the new source. [* source index is zero based, ie 0,1,2,3,4,5..n, where n=listsize-1]<br />
<br />
=== Source Index ===<br />
<br />
The current (ie currently active) source can be changed by source index or source name. The function SetSourceIndex is used to change the current source by index. If the index is out of range an error will be reported. SetSourceIndexByName is used to change to the source whose name matches that specified. If a source of the specified name does not exist, the source will not change and no error will be reported.<br />
<br />
=== SourceCount ===<br />
<br />
SourceCount returns the number of sources that exist in the Product (ie the source list size). SourceCount is read only.<br />
<br />
<br />
=== Source Specific Parameters ===<br />
Every source has four fundamental parameters, '''SourceSystemName''', '''SourceName''', '''SourceVisible''' and '''SourceType'''.<br />
<br />
==== SourceSystemName ====<br />
<br />
SourceSystemName is a unique name string used to identify each source. SourceSystemName is read only. It can only be read via the '''Source''' action.<br />
<br />
==== SourceName ====<br />
<br />
SourceName is a unique name string assigned to each source. In the default state, for a given source index, SourceName matches SourceSystemName. It can be read via the '''Source''' action, or the '''SourceXml''' action.<br />
<br />
==== SourceType ====<br />
<br />
SourceType is a unique type string assigned to each source. SourceType is read only. It can be read via the '''Source''' action, or the '''SourceXml''' action.<br />
<br />
==== SourceVisible ====<br />
<br />
SourceVisible is a unique flag assigned to each source. This flag is used to indicate whether the source is to be displayed (front panel, GUI etc) when browsing through the source list. It can be read via the '''Source''' action, or the '''SourceXml''' action.<br />
<br />
Note - ''a source's "visibility" does not affect its ability to be selected/activated via the functions SetSourceIndex and SetCurrentSourceByName.''<br />
<br />
= Actions=<br />
<br />
== Network Presentation Actions==<br />
=== Attributes Action ===<br />
The Attributes action reports a string containing a space separated list of all attributes.<br />
<br />
=== Manufacturer Action ===<br />
The Manufacturer action returns all four Manufacturer parameters.<br />
<br />
=== Model Action ===<br />
The Model action returns all four Model parameters.<br />
<br />
=== Product Action ===<br />
The Product action returns all five Product parameters.<br />
<br />
== Standby Actions==<br />
=== Standby===<br />
The Standby action reports the current standby state of the product.<br />
<br />
=== SetStandby===<br />
The SetStandby action provides a means of setting the current standby state of the product.<br />
<br />
==Source Actions==<br />
===SourceXml Action===<br />
The SourceXml action returns a list of all source specific parameters, for every source, in XML format.<br />
<br />
===SourceXmlChangeCount Action===<br />
The SourceXmlChangeCount action returns a count indicating the number of times SourceXml has been updated since power on. This is useful for control points that do not support eventing.<br />
<br />
===Source Action===<br />
The Source action returns all source specific parameters for a given source index.<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Product<br />
Version : 1<br />
</code><br />
<br />
== Product Service Description (XML) ==<br />
<code><br />
<?xml version="1.0" encoding="utf-8"?><br />
<scpd xmlns="urn:schemas-upnp-org:service-1-0"><br />
<specVersion><br />
<major>1</major><br />
<minor>0</minor><br />
</specVersion><br />
<actionList><br />
<action><br />
<name>Manufacturer</name><br />
<argumentList><br />
<argument><br />
<name>Name</name><br />
<direction>out</direction><br />
<relatedStateVariable>ManufacturerName</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Info</name><br />
<direction>out</direction><br />
<relatedStateVariable>ManufacturerInfo</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Url</name><br />
<direction>out</direction><br />
<relatedStateVariable>ManufacturerUrl</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>ImageUri</name><br />
<direction>out</direction><br />
<relatedStateVariable>ManufacturerImageUri</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Model</name><br />
<argumentList><br />
<argument><br />
<name>Name</name><br />
<direction>out</direction><br />
<relatedStateVariable>ModelName</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Info</name><br />
<direction>out</direction><br />
<relatedStateVariable>ModelInfo</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Url</name><br />
<direction>out</direction><br />
<relatedStateVariable>ModelUrl</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>ImageUri</name><br />
<direction>out</direction><br />
<relatedStateVariable>ModelImageUri</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Product</name><br />
<argumentList><br />
<argument><br />
<name>Room</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProductRoom</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Name</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProductName</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Info</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProductInfo</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Url</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProductUrl</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>ImageUri</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProductImageUri</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Standby</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Standby</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SetStandby</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Standby</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SourceCount</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceCount</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SourceXml</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceXml</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SourceIndex</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceIndex</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SetSourceIndex</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>SourceIndex</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SetSourceIndexByName</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>SourceName</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Source</name><br />
<argumentList><br />
<argument><br />
<name>Index</name><br />
<direction>in</direction><br />
<relatedStateVariable>SourceIndex</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>SystemName</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceName</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Type</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceType</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Name</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceName</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Visible</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceVisible</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Attributes</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Attributes</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SourceXmlChangeCount</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>SourceXmlChangeCount</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
</actionList><br />
<serviceStateTable><br />
<stateVariable sendEvents="yes"><br />
<name>ManufacturerName</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ManufacturerInfo</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ManufacturerUrl</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ManufacturerImageUri</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ModelName</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ModelInfo</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ModelUrl</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ModelImageUri</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProductRoom</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProductName</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProductInfo</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProductUrl</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProductImageUri</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Standby</name><br />
<dataType>boolean</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>SourceIndex</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>SourceCount</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>SourceXml</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Attributes</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>SourceXmlChangeCount</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>SourceType</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>SourceName</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>SourceVisible</name><br />
<dataType>boolean</dataType><br />
</stateVariable><br />
</serviceStateTable><br />
</scpd><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:InfoServiceAv:Developer:InfoService2011-05-05T14:09:32Z<p>Joshh: /* Info Service Description (XML) */</p>
<hr />
<div>= Architectural Overview =<br />
<br />
The Info service provides information concerning the currently playing media. The information provided is based on the concept of a track, which has a uri and metadata in DIDL-Lite format. Some time after the track changes further information becomes available such as the bit-rate, sample-rate, bit-depth, etc. Optionally a track may contain dynamic textual information (known as metatext) that is updated as the track is played. Metatext is typically used to convey broadcast information from internet radio stations.<br />
<br />
= Actions =<br />
==Counters==<br />
Counters are used to manage the changing of the Track, Details, and Metatext information.<br />
<br />
When a track changes, the Track Count is incremented, the Uri and Metadata are set, the Details Count is set to zero, the Details are defaulted to blank and zero values, the Metatext Count is set to zero, and the Metatext is set to blank.<br />
<br />
Subsequent updates to the Details and Metatext are accompanied by increments in their respective Counters.<br />
<br />
The Counters action can be used by clients that are unable to partake in UPnP eventing in order to establish changes in the information provided by the Info Service.<br />
<br />
==Track==<br />
Reports current track information concerning the current media:<br />
*Uri<br />
*Metadata<br />
<br />
==Details==<br />
Reports details concerning the current media:<br />
*Duration<br />
*Bit Rate<br />
*Bit Depth<br />
*Sample Rate<br />
*Lossless<br />
*Codec Name<br />
<br />
==Metatext==<br />
Reports dynamic textual information concerning the current media.<br />
<br />
This currently amounts to broadcast information from internet radio stations, but the same mechanism could be used for other purposes in the future.<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Info<br />
Version : 1<br />
</code><br />
<br />
== Info Service Description (XML) ==<br />
<code><br />
<?xml version="1.0" encoding="utf-8"?><br />
<scpd xmlns="urn:schemas-upnp-org:service-1-0"><br />
<specVersion><br />
<major>1</major><br />
<minor>0</minor><br />
</specVersion><br />
<actionList><br />
<action><br />
<name>Counters</name><br />
<argumentList><br />
<argument><br />
<name>TrackCount</name><br />
<direction>out</direction><br />
<relatedStateVariable>TrackCount</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>DetailsCount</name><br />
<direction>out</direction><br />
<relatedStateVariable>DetailsCount</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>MetatextCount</name><br />
<direction>out</direction><br />
<relatedStateVariable>MetatextCount</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Track</name><br />
<argumentList><br />
<argument><br />
<name>Uri</name><br />
<direction>out</direction><br />
<relatedStateVariable>Uri</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Metadata</name><br />
<direction>out</direction><br />
<relatedStateVariable>Metadata</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Details</name><br />
<argumentList><br />
<argument><br />
<name>Duration</name><br />
<direction>out</direction><br />
<relatedStateVariable>Duration</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>BitRate</name><br />
<direction>out</direction><br />
<relatedStateVariable>BitRate</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>BitDepth</name><br />
<direction>out</direction><br />
<relatedStateVariable>BitDepth</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>SampleRate</name><br />
<direction>out</direction><br />
<relatedStateVariable>SampleRate</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Lossless</name><br />
<direction>out</direction><br />
<relatedStateVariable>Lossless</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>CodecName</name><br />
<direction>out</direction><br />
<relatedStateVariable>CodecName</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Metatext</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Metatext</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
</actionList><br />
<serviceStateTable><br />
<stateVariable sendEvents="yes"><br />
<name>TrackCount</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>DetailsCount</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>MetatextCount</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Uri</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Metadata</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Duration</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>BitRate</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>BitDepth</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>SampleRate</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Lossless</name><br />
<dataType>boolean</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>CodecName</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Metatext</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
</serviceStateTable><br />
</scpd><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:PlaylistServiceAv:Developer:PlaylistService2011-05-05T14:09:06Z<p>Joshh: /* Playlist Service Description (XML) */</p>
<hr />
<div>= Architectural Overview =<br />
<br />
The Playlist service provides the means for controlling a Playlist source. If a device's [[Developer:ProductService|Product service]] reports a source of type 'Playlist', then that device is guaranteed to bear the Playlist service.<br />
<br />
The Playlist service provides access to a list of tracks, which can be played starting at any point. Unless repeat mode has been engaged, the playlist will play to the end. Shuffle mode causes playback to skip randomly through the playlist. It is possible for Shuffle and Repeat modes to be engaged simultaneously.<br />
<br />
Using the Playlist service you can read, insert, and delete entries in the playlist. Each entry in the playlist is given unique id. This unique id is completely unrelated to the play order of the playlist.<br />
<br />
To insert, provide the id you wish to insert 'after' and the associated uri and metadata. The track is inserted into the correct position and the id of the new track is returned. To insert in the first position in the playlist, insert after the special id of 0.<br />
<br />
There are two read actions. One to read a single entry and the other to read a list of entries.<br />
<br />
In the first, the uri and metadata of the requested id are returned. This operation can fail if the requested id does not exist in the playlist.<br />
<br />
In the second, ReadList, a list of space separated decimal id's is provided and information concerning each of these tracks is returned in xml. ReadList does not fail. Requests for ids that are not in the playlist are silently ignored.<br />
<br />
There are two variants of delete allowing the deletion of a single track or the deletion of the entire playlist. The former requires the id of the entry to delete. The latter takes no parameters. Both variants always succeed.<br />
<br />
== IdArray ==<br />
<br />
The Playlist service has a state variable called IdArray. This IdArray is a [http://en.wikipedia.org/wiki/Base64 base64] encoded array of 32 bit, big endian unsigned integers. Each Id represents a track in the playlist. An empty IdArray indicates an empty playlist.<br />
<br />
For example the IdArray of:<br />
<br />
<pre>0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x14 0x00 0x00 0x00 0x13</pre> <br />
<br />
indicates a playlist of 3 tracks with the id's of 2, 20, and 19 in that order.<br />
<br />
Control point authors are interested in both: <br />
<br />
* the order of tracks in the playlist, and<br />
* the metadata of those tracks<br />
<br />
Whether you acquire the IdArray via [[Developer:PlaylistService#Events|events]] or [[Developer:PlaylistService#Polling|polling]], you immediately know the order of the ids in the playlist. What you don't necessarily know is the metadata for those ids. <br />
<br />
As the metadata for a large playlist can easily be several megabytes of xml, blindly fetching all the metadata every time the playlist changes is inefficient and will give a poor user experience. In order to quickly display playlist updates and ensure interoperability with other control points on the network, it is strongly recommended that you maintain the following two data structures:<br />
<br />
* A copy of the latest IdArray<br />
* A cache mapping id's to their associated metadata.<br />
<br />
With this decoupled approach, you only need to fetch the metadata for the ids added to the playlist. Changes to the order of ids in the playlist require no action.<br />
<br />
As a further enhancement, when an insert completes successfully, you know both the metadata (as you supplied it), and the new id (returned by the DS on completion of the insert action). This information can be directly inserted into the cache, saving subsequent unnecessary retrieval.<br />
<br />
== Events ==<br />
<br />
A short while (approx 300ms) after any change to the playlist, the DS will event all subscribers the current IdArray. The eventing of this state variable is moderated to prevent excessive updates.<br />
<br />
== Polling ==<br />
<br />
For control points that can't subscribe to events, two additional actions are provided. The first, IdArray, reads the id array directly. This action also returns an IdArrayToken, which should be saved and periodically passed to a second action, IdArrayChanged, which reports whether or not your copy of the IdArray is out of date. If it is, calling IdArray again will ensure you have an up to date version.<br />
<br />
= Actions =<br />
<br />
== IdArray ==<br />
Report the current id array.<br />
<br />
The IdArray is an ordered array of ids that represent each track in the playlist. <br />
<br />
This action also reports a Token, which can be used to quickly detect if the id array has changed since it was last read (see IdArrayChanged).<br />
<br />
== IdArrayChanged ==<br />
Check to see if the id array has changed since gathering the specified Token.<br />
This Token must have been previously collected from the IdArray action.<br />
<br />
This mechanism is provided specifically for clients unable to partake in UPnP eventing.<br />
<br />
== TracksMax ==<br />
Report the maximum number of tracks in the id array. This remains constant while a particular OpenHome device remains registerted on the network, but may vary between different models of OpenHome device from different manufacturers.<br />
<br />
==Id==<br />
Report the Id of the current track. If the reported id is zero, the playlist is empty.<br />
<br />
==ProtocolInfo==<br />
Report the Playlist source protocol info.<br />
<br />
==Read==<br />
Given a track Id, report its associated Uri and Metadata.<br />
<br />
==ReadList==<br />
Given a space separated list of track Id's, report their associated Uri and Metadata in the following xml form:<br />
<br />
<code><br />
<br />
<TrackList><br />
<Entry><br />
<Id></Id><br />
<Uri></Uri><br />
<Metadata></Metadata><br />
</Entry><br />
</TrackList><br />
<br />
</code><br />
<br />
== TransportState ==<br />
<br />
Report the current transport state, which can be: 'Playing', 'Paused', 'Stopped', or 'Buffering'.<br />
<br />
== Play ==<br />
Begin playback from the current position.<br />
<br />
== Pause ==<br />
Pause the current track. This will be converted to Stop if the track cannot be paused e.g. internet radio.<br />
<br />
== Stop ==<br />
Stop playback and move the current position to the start of the current track.<br />
<br />
== Next ==<br />
Move the current position to the start of the next track in the playlist.<br />
<br />
== Previous ==<br />
Move the current position to the start of the next track in the playlist.<br />
<br />
== SeekId ==<br />
Move the current position to the start of the track represented by the given Id.<br />
<br />
== SeekIndex ==<br />
Move the current position to the start of the track with the given Index into the playlist.<br />
<br />
This action should only be used by primitive control points that do not have a rich way of representing the playlist to the user.<br />
<br />
== SeekSecondAbsolute ==<br />
Seek to an absolute second within the current track. This is only available if the current track has a finite length.<br />
<br />
== SeekSecondRelative ==<br />
Seek to a relative second within the current track. This is only available if the current track has a finite length.<br />
<br />
== Repeat ==<br />
Report the state of repeat mode.<br />
<br />
== SetRepeat ==<br />
Set the state of repeat mode.<br />
<br />
== Shuffle ==<br />
Report the state of shuffle mode.<br />
<br />
== SetShuffle ==<br />
Set the state of shuffle mode.<br />
<br />
== DeleteId ==<br />
Delete from the playlist the track with the speciofied Id.<br />
<br />
== DeleteAll ==<br />
Clear the playlist.<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Playlist<br />
Version : 1<br />
</code><br />
<br />
== Playlist Service Description (XML) ==<br />
<code><br />
<?xml version="1.0" encoding="utf-8"?><br />
<br />
<scpd xmlns="urn:schemas-upnp-org:service-1-0"><br />
<br />
<specVersion><br />
<major>1</major><br />
<minor>0</minor><br />
</specVersion><br />
<br />
<actionList><br />
<action><br />
<name>Play</name><br />
</action><br />
<action><br />
<name>Pause</name><br />
</action><br />
<action><br />
<name>Stop</name><br />
</action><br />
<action><br />
<name>Next</name><br />
</action><br />
<action><br />
<name>Previous</name><br />
</action><br />
<action><br />
<name>SetRepeat</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Repeat</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Repeat</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Repeat</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SetShuffle</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Shuffle</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Shuffle</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Shuffle</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SeekSecondAbsolute</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Absolute</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SeekSecondRelative</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Relative</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SeekId</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Id</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>SeekIndex</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Index</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>TransportState</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>TransportState</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Id</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Id</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Read</name><br />
<argumentList><br />
<argument><br />
<name>Id</name><br />
<direction>in</direction><br />
<relatedStateVariable>Id</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Uri</name><br />
<direction>out</direction><br />
<relatedStateVariable>Uri</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Metadata</name><br />
<direction>out</direction><br />
<relatedStateVariable>Metadata</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>ReadList</name><br />
<argumentList><br />
<argument><br />
<name>IdList</name><br />
<direction>in</direction><br />
<relatedStateVariable>IdList</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>TrackList</name><br />
<direction>out</direction><br />
<relatedStateVariable>TrackList</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Insert</name><br />
<argumentList><br />
<argument><br />
<name>AfterId</name><br />
<direction>in</direction><br />
<relatedStateVariable>Id</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Uri</name><br />
<direction>in</direction><br />
<relatedStateVariable>Uri</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Metadata</name><br />
<direction>in</direction><br />
<relatedStateVariable>Metadata</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>NewId</name><br />
<direction>out</direction><br />
<relatedStateVariable>Id</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>DeleteId</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>in</direction><br />
<relatedStateVariable>Id</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>DeleteAll</name><br />
</action><br />
<action><br />
<name>TracksMax</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>TracksMax</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>IdArray</name><br />
<argumentList><br />
<argument><br />
<name>Token</name><br />
<direction>out</direction><br />
<relatedStateVariable>IdArrayToken</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Array</name><br />
<direction>out</direction><br />
<relatedStateVariable>IdArray</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>IdArrayChanged</name><br />
<argumentList><br />
<argument><br />
<name>Token</name><br />
<direction>in</direction><br />
<relatedStateVariable>IdArrayToken</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>IdArrayChanged</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>ProtocolInfo</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>ProtocolInfo</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
</actionList><br />
<br />
<serviceStateTable><br />
<stateVariable sendEvents="yes"><br />
<name>TransportState</name><br />
<dataType>string</dataType><br />
<allowedValueList><br />
<allowedValue>Playing</allowedValue><br />
<allowedValue>Paused</allowedValue><br />
<allowedValue>Stopped</allowedValue><br />
<allowedValue>Buffering</allowedValue><br />
</allowedValueList><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Repeat</name><br />
<dataType>boolean</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Shuffle</name><br />
<dataType>boolean</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Id</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>IdArray</name><br />
<dataType>bin.base64</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>TracksMax</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>ProtocolInfo</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>Index</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>Relative</name><br />
<dataType>i4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>Absolute</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>IdList</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>TrackList</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>Uri</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>Metadata</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>IdArrayToken</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="no"><br />
<name>IdArrayChanged</name><br />
<dataType>boolean</dataType><br />
</stateVariable><br />
</serviceStateTable><br />
</scpd><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:InfoServiceAv:Developer:InfoService2011-05-05T14:07:56Z<p>Joshh: /* Info Service Description (XML) */</p>
<hr />
<div>= Architectural Overview =<br />
<br />
The Info service provides information concerning the currently playing media. The information provided is based on the concept of a track, which has a uri and metadata in DIDL-Lite format. Some time after the track changes further information becomes available such as the bit-rate, sample-rate, bit-depth, etc. Optionally a track may contain dynamic textual information (known as metatext) that is updated as the track is played. Metatext is typically used to convey broadcast information from internet radio stations.<br />
<br />
= Actions =<br />
==Counters==<br />
Counters are used to manage the changing of the Track, Details, and Metatext information.<br />
<br />
When a track changes, the Track Count is incremented, the Uri and Metadata are set, the Details Count is set to zero, the Details are defaulted to blank and zero values, the Metatext Count is set to zero, and the Metatext is set to blank.<br />
<br />
Subsequent updates to the Details and Metatext are accompanied by increments in their respective Counters.<br />
<br />
The Counters action can be used by clients that are unable to partake in UPnP eventing in order to establish changes in the information provided by the Info Service.<br />
<br />
==Track==<br />
Reports current track information concerning the current media:<br />
*Uri<br />
*Metadata<br />
<br />
==Details==<br />
Reports details concerning the current media:<br />
*Duration<br />
*Bit Rate<br />
*Bit Depth<br />
*Sample Rate<br />
*Lossless<br />
*Codec Name<br />
<br />
==Metatext==<br />
Reports dynamic textual information concerning the current media.<br />
<br />
This currently amounts to broadcast information from internet radio stations, but the same mechanism could be used for other purposes in the future.<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Info<br />
Version : 1<br />
</code><br />
<br />
== Info Service Description (XML) ==<br />
<code><br />
<?xml version="1.0" encoding="utf-8"?><br />
<scpd xmlns="urn:schemas-upnp-org:service-1-0"><br />
<specVersion><br />
<major>1</major><br />
<minor>0</minor><br />
</specVersion><br />
<actionList><br />
<action><br />
<name>Counters</name><br />
<argumentList><br />
<argument><br />
<name>TrackCount</name><br />
<direction>out</direction><br />
<relatedStateVariable>TrackCount</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>DetailsCount</name><br />
<direction>out</direction><br />
<relatedStateVariable>DetailsCount</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>MetatextCount</name><br />
<direction>out</direction><br />
<relatedStateVariable>MetatextCount</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Track</name><br />
<argumentList><br />
<argument><br />
<name>Uri</name><br />
<direction>out</direction><br />
<relatedStateVariable>Uri</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Metadata</name><br />
<direction>out</direction><br />
<relatedStateVariable>Metadata</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Details</name><br />
<argumentList><br />
<argument><br />
<name>Duration</name><br />
<direction>out</direction><br />
<relatedStateVariable>Duration</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>BitRate</name><br />
<direction>out</direction><br />
<relatedStateVariable>BitRate</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>BitDepth</name><br />
<direction>out</direction><br />
<relatedStateVariable>BitDepth</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>SampleRate</name><br />
<direction>out</direction><br />
<relatedStateVariable>SampleRate</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>Lossless</name><br />
<direction>out</direction><br />
<relatedStateVariable>Lossless</relatedStateVariable><br />
</argument><br />
<argument><br />
<name>CodecName</name><br />
<direction>out</direction><br />
<relatedStateVariable>CodecName</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
<action><br />
<name>Metatext</name><br />
<argumentList><br />
<argument><br />
<name>Value</name><br />
<direction>out</direction><br />
<relatedStateVariable>Metatext</relatedStateVariable><br />
</argument><br />
</argumentList><br />
</action><br />
</actionList><br />
<serviceStateTable><br />
<stateVariable sendEvents="yes"><br />
<name>TrackCount</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>DetailsCount</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>MetatextCount</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Uri</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Metadata</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Duration</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>BitRate</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>BitDepth</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>SampleRate</name><br />
<dataType>ui4</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Lossless</name><br />
<dataType>boolean</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>CodecName</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
<stateVariable sendEvents="yes"><br />
<name>Metatext</name><br />
<dataType>string</dataType><br />
</stateVariable><br />
</serviceStateTable><br />
</scpd><br />
<br />
<br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:ReceiverServiceAv:Developer:ReceiverService2011-05-05T14:07:30Z<p>Joshh: /* Technical Details */</p>
<hr />
<div>= Architectural Overview =<br />
<br />
The Receiver service provides the means for controlling a Receiver source. If a device's [[Developer:ProductService|Product service]] reports a source of type 'Receiver', then that device is guaranteed to bear the Receiver service.<br />
<br />
A receiver plays audio broadcast from a [[Developer:SenderService|sender]].<br />
<br />
= Actions =<br />
== Sender ==<br />
Report the Uri and Metadata of the sender this receiver is currently listening to.<br />
<br />
==SetSender==<br />
Set the Uri and Metadata of the sender to listen to.<br />
<br />
The Metadata must have originated from a device bearing the [[Developer:SenderService|Sender service]].<br />
<br />
The Uri must be the result of applying this receiver's ProtocolInfo to this Metadata.<br />
<br />
==ProtocolInfo==<br />
Report the receiver's protocol info.<br />
<br />
==TransportState==<br />
<br />
Report the current transport state, which can be: 'Playing', 'Paused', 'Stopped', or 'Buffering'.<br />
<br />
==Play==<br />
Play audio from the current sender<br />
<br />
==Stop==<br />
Stop playing audio from the current sender<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Receiver<br />
Version : 1<br />
</code><br />
<br />
== Receiver Service Description (XML) ==<br />
<code><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:SenderServiceAv:Developer:SenderService2011-05-05T14:07:09Z<p>Joshh: /* Technical Details */</p>
<hr />
<div>= Architectural Overview =<br />
<br />
The Sender service indicates the presence of an OpenHome Av sender and provides information concerning that sender.<br />
<br />
An OpenHome Av sender broadcasts music on a network in a way that is playable by an OpenHome Av [[Developer:ReceiverService|receiver]].<br />
<br />
OpenHome senders should be discovered independently of the standard algorithm for discovering OpenHome products and sources. An independent search should be made for devices bearing the Sender service.<br />
<br />
= Actions =<br />
== Attributes ==<br />
Reports a space separated list of attributes that identify additional functionality that can be found on the same device as this Sender.<br />
<br />
Currently defined attributes are:<br />
<br />
* Info - this device reports on the current media using the Info service<br />
* Time - this device reports on the current media using the Time service<br />
<br />
== Audio == <br />
Reports whether audio is currently present on this sender.<br />
<br />
== Metadata ==<br />
Provides a representation of this audio item in DIDL-Lite format.<br />
<br />
== PresentationUrl ==<br />
Reports the Url of a presentation page for further information concerning the sender, or for controlling the sender in some application-specific way.<br />
<br />
If the sender has no presentation page, the PresentationUrl should be empty.<br />
<br />
== Status ==<br />
Reports the status of the sender (normally only for debugging purposes):<br />
<br />
* Sending - currently sending audio over the network<br />
* Ready - ready to send audio but no listeners<br />
* Blocked - audio from another sender detected on the same channel (mis-configuration)<br />
* Inactive - no audio source currently assigned to this sender<br />
* Disabled - sender disabled by user configuration<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Sender<br />
Version : 1<br />
</code><br />
<br />
== Sender Service Description (XML) ==<br />
<code><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:VolumeServiceAv:Developer:VolumeService2011-05-05T14:06:48Z<p>Joshh: /* Technical Details */</p>
<hr />
<div>= Architecture Overview =<br />
The Volume Service provides a means of controlling various settings which affect the product's volume (signal amplitude) measured at the output channels. A product may have one or more output channels. Balance or Fade settings may result in different volumes at each output. In the Mute state, all output channels are reduced to zero volume. <br />
<br />
==Volume==<br />
Volume is an adjustable setting that controls the loudness of the audio at the output channels of the product. Volume can be set to an absolute value or incremented/decremented in single steps. The maximum Volume setting is defined by the current value of '''VolumeLimit'''. The minimum Volume setting is zero. If an attempt is made to set the Volume above VolumeLimit, the Volume will be set to the '''VolumLimit'''. If an attempt is made to set the Volume above '''VolumeMax''', an error will be reported.<br />
<br />
== Volume Limit ==<br />
VolumeLimit specifies the upper limit of the Volume. Any attempt to set Volume above the VolumeLimit will reset Volume to the value of VolumeLimit. If VolumeLimit is changed, Volume is checked and automatically reduced if necessary. The maximum VolumeLimit setting is defined by the '''VolumeMax''' Characteristic.<br />
<br />
==Balance==<br />
Balance is an adjustable setting that specifies the '''bias''' in volume between the '''left and right''' output channels of the product. Balance can be set to an absolute value or incremented/decremented in single steps. The maximum Balance setting is defined by the '''BalanceMax''' Characteristic. The minimum Balance setting is defined by ('''-BalanceMax''') .<br />
<br />
==Fade==<br />
Fade is an adjustable setting that specifies the '''bias''' in volume between the '''front and rear''' output channels of the products. Fade can be set to an absolute value or incremented/decremented in single steps. The maximum Fade setting is defined by the '''FadeMax''' Characteristic. The minimum Fade setting is defined by ('''-FadeMax''') .<br />
<br />
==Mute==<br />
Mute is an adjustable state that determines if the output channels of the product are muted or not. When muted, all output channels of the product are silent.<br />
<br />
<br />
==Characterstics==<br />
Each product has '''six''' read only values that define its volume Characteristics. <br />
====VolumeMax====<br />
VolumeMax defines the absolute maximum Volume setting.<br />
<br />
====VolumeUnity====<br />
VolumeUnity defines the value of Volume that will result in unity system gain (ie ''output amplitude'' = ''input amplitude'').<br />
<br />
====VolumeSteps====<br />
VolumeSteps defines the number of step increments required to increase the Volume from zero to VolumeMax.<br />
====VolumeMilliDbPerStep====<br />
VolumeMilliDbPerStep defines the size of each volume step in '''binary milli decibels''' (bmdB). [''1024bmdB = 1dB'']<br />
<br />
====BalanceMax====<br />
BalanceMax defines the maximum Balance setting. The minimum Balance setting is (-BalanceMax)<br />
====FadeMax====<br />
FadeMax defines the maximum Fade setting. The minimum Fade setting is (-FadeMax)<br />
<br />
<br />
=Actions=<br />
<br />
=== Volume ===<br />
The Volume action reports the current Volume setting.<br />
<br />
=== SetVolume===<br />
The SetVolume action provides a means of setting the Volume to an absolute value.<br />
<br />
=== Volume Inc===<br />
The VolumeInc action provides a means of increasing the Volume by 1.<br />
=== Volume Dec ===<br />
The VolumeDec action provides a means of decreasing the Volume by 1.<br />
=== VolumeLimit ===<br />
The VolumeLimit action reports the current VolumeLimit setting.<br />
=== Balance ===<br />
The Balance action reports the current Balance setting.<br />
=== SetBalance ===<br />
The SetBalance action provides a means of setting the Balance to a specific value.<br />
<br />
=== BalanceInc===<br />
The BalanceInc action provides a means of increasing the Balance by 1.<br />
=== BalanceDec ===<br />
The BalanceDec action provides a means of decreasing the Balance by 1.<br />
=== Fade ===<br />
The Fade action reports the current Fade setting of the product.<br />
==== SetFade ====<br />
The SetFade action provides a means of setting the Fade to a specific value.<br />
=== FadeInc===<br />
The FadeInc action provides a means of increasing the Fade by 1.<br />
<br />
=== FadeDec ===<br />
The FadeDec action provides a means of decreasing the Fade by 1.<br />
=== Mute ===<br />
The Mute action reports the current Mute state of the product.<br />
=== SetMute ===<br />
The SetMute action provides a means of setting the Mute state.<br />
<br />
=== Characteristics ===<br />
The Characteristics action returns all '''six''' characteristic values of the product.<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Volume<br />
Version : 1<br />
</code><br />
<br />
== Volume Service Description (XML) ==<br />
<code><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:TimeServiceAv:Developer:TimeService2011-05-05T14:05:25Z<p>Joshh: /* Technical Details */</p>
<hr />
<div>= Architectural Overview =<br />
The Time service reports the duration of the currently playing track and the number of seconds so far played.<br />
<br />
This service is intentionally separated from the Info service. When a track is being played, this service delivers an event every second, which can overwhelm some primitive control points. The Time service is kept separate from the Info service so that control points can decide to subscribe to it independently.<br />
<br />
= Actions =<br />
==Time==<br />
This reports TrackCount, which increments each time a new track is played; Duration, which is the duration of the current track in seconds; and Seconds, which is the number of seconds so far played.<br />
<br />
TrackCount corresponds with TrackCount reported in the Info Service, but bears no relation to a Track Id or Preset Id reported from the [[Developer:Davaar:PlaylistService|Playlist Service]] or [[Developer:Davaar:RadioService|Radio Service]].<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Time<br />
Version : 1<br />
</code><br />
<br />
== Time Service Description (XML) ==<br />
<code><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:InfoServiceAv:Developer:InfoService2011-05-05T14:04:57Z<p>Joshh: /* Technical Details */</p>
<hr />
<div>= Architectural Overview =<br />
<br />
The Info service provides information concerning the currently playing media. The information provided is based on the concept of a track, which has a uri and metadata in DIDL-Lite format. Some time after the track changes further information becomes available such as the bit-rate, sample-rate, bit-depth, etc. Optionally a track may contain dynamic textual information (known as metatext) that is updated as the track is played. Metatext is typically used to convey broadcast information from internet radio stations.<br />
<br />
= Actions =<br />
==Counters==<br />
Counters are used to manage the changing of the Track, Details, and Metatext information.<br />
<br />
When a track changes, the Track Count is incremented, the Uri and Metadata are set, the Details Count is set to zero, the Details are defaulted to blank and zero values, the Metatext Count is set to zero, and the Metatext is set to blank.<br />
<br />
Subsequent updates to the Details and Metatext are accompanied by increments in their respective Counters.<br />
<br />
The Counters action can be used by clients that are unable to partake in UPnP eventing in order to establish changes in the information provided by the Info Service.<br />
<br />
==Track==<br />
Reports current track information concerning the current media:<br />
*Uri<br />
*Metadata<br />
<br />
==Details==<br />
Reports details concerning the current media:<br />
*Duration<br />
*Bit Rate<br />
*Bit Depth<br />
*Sample Rate<br />
*Lossless<br />
*Codec Name<br />
<br />
==Metatext==<br />
Reports dynamic textual information concerning the current media.<br />
<br />
This currently amounts to broadcast information from internet radio stations, but the same mechanism could be used for other purposes in the future.<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Info<br />
Version : 1<br />
</code><br />
<br />
== Info Service Description (XML) ==<br />
<code><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:RadioServiceAv:Developer:RadioService2011-05-05T14:04:33Z<p>Joshh: /* Technical Details */</p>
<hr />
<div>= Architectural Overview =<br />
The Radio service provides the means for controlling a Radio source. If a product's [[Developer:ProductService|Product Service]] reports a source of type 'Radio', then the device that bears that [[Developer:ProductService|Product Service]] is guaranteed to also bear the Radio service.<br />
<br />
The heart of the Radio service is the '''SetChannel''' action. Call '''SetChannel''' with a particular Uri and Metadata, then call '''Play''' and the media at the given Uri is played. If the media is an internet radio stream, it will play forever. If it is of finite length, it will play to the end and then stop.<br />
<br />
Call the '''Channel''' action to report the Uri and Metadata of the current Channel.<br />
<br />
The Radio Source also stores a list of channel presets. These can be presented to the user as a list of numbered channels that can easily be selected and played.<br />
<br />
This array of channel presets is accessed using an id array mechanism similar to that used in the [[Developer:PlaylistService|Playlist Service]]. The only difference is that the Radio service's id array is a constant length and may contain entries that are zero, which represent empty presets.<br />
<br />
= Actions =<br />
==Channel==<br />
Report the Uri and Metadata of the current Channel.<br />
<br />
==SetChannel==<br />
Set the Uri and Metadata of the current Channel.<br />
<br />
==IdArray==<br />
Report the current id array. The id array contains 100 presets, but this may change (see ChannelsMax).<br />
<br />
The IdArray is an ordered, constant length, array of ids. The first element contains the id for channel preset 1, the second element contains the id for channel Preset 2, etc. If an element is set to zero, then the corresponding channel preset is empty. <br />
<br />
This action also reports a Token, which can be used to quickly detect if the id array has changed since it was last read (see IdArrayChanged).<br />
<br />
==IdArrayChanged==<br />
Check to see if the id array has changed since gathering the specified IdArrayToken.<br />
This Token must have been previously collected from the IdArray action.<br />
<br />
This mechanism is provided specifically for clients unable to partake in UPnP eventing.<br />
<br />
==ChannelsMax==<br />
Report the maximum number of entries in the channel preset id array.<br />
<br />
==SetId==<br />
The the current Channel using the channel preset represented by the given Id, and using the provided Uri.<br />
<br />
It is usual for a Control Point to inspect the res elements of the Channel Metadata and select the appropriate Uri by matching to the renderer's ProtocolInfo.<br />
<br />
==Id==<br />
Report the Id of the current Channel if it is in the Channel Preset list. If the current Channel is not a channel preset, the Id reported is zero.<br />
<br />
==ProtocolInfo==<br />
Report the Radio Source protocol info.<br />
<br />
==Read==<br />
Given a channel preset Id, report its associated Metadata.<br />
<br />
==ReadList==<br />
Given a space separated list of channel preset Ids, report their associated Metadata.<br />
<br />
==TransportState==<br />
<br />
Report the current transport state, which can be: 'Playing', 'Paused', 'Stopped', or 'Buffering'.<br />
<br />
==Play==<br />
Play the current channel<br />
<br />
==Pause==<br />
Pause the current channel. This will be converted to Stop if the channel cannot be paused e.g. internet radio.<br />
<br />
==Stop==<br />
Stop the current Channel<br />
<br />
==SeekSecondsAbsolute==<br />
Seek to an absolute second within the current media. This is only available if the current media has a finite length.<br />
<br />
==SeekSecondsRelative==<br />
Seek to a relative second within the current media. This is only available if the current media has a finite length.<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Radio<br />
Version : 1<br />
</code><br />
<br />
== Radio Service Description (XML) ==<br />
<code><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:PlaylistServiceAv:Developer:PlaylistService2011-05-05T14:04:03Z<p>Joshh: /* Technical Details */</p>
<hr />
<div>= Architectural Overview =<br />
<br />
The Playlist service provides the means for controlling a Playlist source. If a device's [[Developer:ProductService|Product service]] reports a source of type 'Playlist', then that device is guaranteed to bear the Playlist service.<br />
<br />
The Playlist service provides access to a list of tracks, which can be played starting at any point. Unless repeat mode has been engaged, the playlist will play to the end. Shuffle mode causes playback to skip randomly through the playlist. It is possible for Shuffle and Repeat modes to be engaged simultaneously.<br />
<br />
Using the Playlist service you can read, insert, and delete entries in the playlist. Each entry in the playlist is given unique id. This unique id is completely unrelated to the play order of the playlist.<br />
<br />
To insert, provide the id you wish to insert 'after' and the associated uri and metadata. The track is inserted into the correct position and the id of the new track is returned. To insert in the first position in the playlist, insert after the special id of 0.<br />
<br />
There are two read actions. One to read a single entry and the other to read a list of entries.<br />
<br />
In the first, the uri and metadata of the requested id are returned. This operation can fail if the requested id does not exist in the playlist.<br />
<br />
In the second, ReadList, a list of space separated decimal id's is provided and information concerning each of these tracks is returned in xml. ReadList does not fail. Requests for ids that are not in the playlist are silently ignored.<br />
<br />
There are two variants of delete allowing the deletion of a single track or the deletion of the entire playlist. The former requires the id of the entry to delete. The latter takes no parameters. Both variants always succeed.<br />
<br />
== IdArray ==<br />
<br />
The Playlist service has a state variable called IdArray. This IdArray is a [http://en.wikipedia.org/wiki/Base64 base64] encoded array of 32 bit, big endian unsigned integers. Each Id represents a track in the playlist. An empty IdArray indicates an empty playlist.<br />
<br />
For example the IdArray of:<br />
<br />
<pre>0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x14 0x00 0x00 0x00 0x13</pre> <br />
<br />
indicates a playlist of 3 tracks with the id's of 2, 20, and 19 in that order.<br />
<br />
Control point authors are interested in both: <br />
<br />
* the order of tracks in the playlist, and<br />
* the metadata of those tracks<br />
<br />
Whether you acquire the IdArray via [[Developer:PlaylistService#Events|events]] or [[Developer:PlaylistService#Polling|polling]], you immediately know the order of the ids in the playlist. What you don't necessarily know is the metadata for those ids. <br />
<br />
As the metadata for a large playlist can easily be several megabytes of xml, blindly fetching all the metadata every time the playlist changes is inefficient and will give a poor user experience. In order to quickly display playlist updates and ensure interoperability with other control points on the network, it is strongly recommended that you maintain the following two data structures:<br />
<br />
* A copy of the latest IdArray<br />
* A cache mapping id's to their associated metadata.<br />
<br />
With this decoupled approach, you only need to fetch the metadata for the ids added to the playlist. Changes to the order of ids in the playlist require no action.<br />
<br />
As a further enhancement, when an insert completes successfully, you know both the metadata (as you supplied it), and the new id (returned by the DS on completion of the insert action). This information can be directly inserted into the cache, saving subsequent unnecessary retrieval.<br />
<br />
== Events ==<br />
<br />
A short while (approx 300ms) after any change to the playlist, the DS will event all subscribers the current IdArray. The eventing of this state variable is moderated to prevent excessive updates.<br />
<br />
== Polling ==<br />
<br />
For control points that can't subscribe to events, two additional actions are provided. The first, IdArray, reads the id array directly. This action also returns an IdArrayToken, which should be saved and periodically passed to a second action, IdArrayChanged, which reports whether or not your copy of the IdArray is out of date. If it is, calling IdArray again will ensure you have an up to date version.<br />
<br />
= Actions =<br />
<br />
== IdArray ==<br />
Report the current id array.<br />
<br />
The IdArray is an ordered array of ids that represent each track in the playlist. <br />
<br />
This action also reports a Token, which can be used to quickly detect if the id array has changed since it was last read (see IdArrayChanged).<br />
<br />
== IdArrayChanged ==<br />
Check to see if the id array has changed since gathering the specified Token.<br />
This Token must have been previously collected from the IdArray action.<br />
<br />
This mechanism is provided specifically for clients unable to partake in UPnP eventing.<br />
<br />
== TracksMax ==<br />
Report the maximum number of tracks in the id array. This remains constant while a particular OpenHome device remains registerted on the network, but may vary between different models of OpenHome device from different manufacturers.<br />
<br />
==Id==<br />
Report the Id of the current track. If the reported id is zero, the playlist is empty.<br />
<br />
==ProtocolInfo==<br />
Report the Playlist source protocol info.<br />
<br />
==Read==<br />
Given a track Id, report its associated Uri and Metadata.<br />
<br />
==ReadList==<br />
Given a space separated list of track Id's, report their associated Uri and Metadata in the following xml form:<br />
<br />
<code><br />
<br />
<TrackList><br />
<Entry><br />
<Id></Id><br />
<Uri></Uri><br />
<Metadata></Metadata><br />
</Entry><br />
</TrackList><br />
<br />
</code><br />
<br />
== TransportState ==<br />
<br />
Report the current transport state, which can be: 'Playing', 'Paused', 'Stopped', or 'Buffering'.<br />
<br />
== Play ==<br />
Begin playback from the current position.<br />
<br />
== Pause ==<br />
Pause the current track. This will be converted to Stop if the track cannot be paused e.g. internet radio.<br />
<br />
== Stop ==<br />
Stop playback and move the current position to the start of the current track.<br />
<br />
== Next ==<br />
Move the current position to the start of the next track in the playlist.<br />
<br />
== Previous ==<br />
Move the current position to the start of the next track in the playlist.<br />
<br />
== SeekId ==<br />
Move the current position to the start of the track represented by the given Id.<br />
<br />
== SeekIndex ==<br />
Move the current position to the start of the track with the given Index into the playlist.<br />
<br />
This action should only be used by primitive control points that do not have a rich way of representing the playlist to the user.<br />
<br />
== SeekSecondAbsolute ==<br />
Seek to an absolute second within the current track. This is only available if the current track has a finite length.<br />
<br />
== SeekSecondRelative ==<br />
Seek to a relative second within the current track. This is only available if the current track has a finite length.<br />
<br />
== Repeat ==<br />
Report the state of repeat mode.<br />
<br />
== SetRepeat ==<br />
Set the state of repeat mode.<br />
<br />
== Shuffle ==<br />
Report the state of shuffle mode.<br />
<br />
== SetShuffle ==<br />
Set the state of shuffle mode.<br />
<br />
== DeleteId ==<br />
Delete from the playlist the track with the speciofied Id.<br />
<br />
== DeleteAll ==<br />
Clear the playlist.<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Playlist<br />
Version : 1<br />
</code><br />
<br />
== Playlist Service Description (XML) ==<br />
<code><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:ProductServiceAv:Developer:ProductService2011-05-05T14:03:25Z<p>Joshh: </p>
<hr />
<div>= Architectural Overview =<br />
<br />
The Product service contains basic information concerning a single product. It contains information about what kind of device it is: the model, manufacturer, its name, its room, and details concerning each source within the product. Other basic functionality such as control of the product's standby state are also included.<br />
<br />
It should be possible for a control point to create a complete map of the home by subscribing to the Product service of every device.<br />
<br />
== Network Presentation ==<br />
<br />
=== Attributes ===<br />
Every product has one or more attributes indicating additional features offered by that product beyond those provided by its sources<br />
<br />
=== Manufacturer ===<br />
There are '''four''' Manufacturer parameters; '''Name''', '''Info''', '''Url''' and '''ImageUri'''. They are all text strings.<br />
<br />
==== Name ====<br />
Name contains the Manufacturer name. Name is read only.<br />
<br />
==== Info ====<br />
Info contains more Manufacturer information. Info is read only.<br />
<br />
==== Url ====<br />
Url contains the Manufacturer website address. Url is read only.<br />
<br />
==== ImageUri ====<br />
ImageUri contains a link to the Manufacturer image (i.e. logo). ImageUri is read only.<br />
<br />
=== Model ===<br />
<br />
There are '''four''' Model parameters; '''Name''', '''Info''', '''Url''' and '''ImageUri'''.<br />
<br />
==== Name ====<br />
Name contains the Model name. Name is read only.<br />
==== Info ====<br />
Info contains more Model information. Info is read only. <br />
==== Url ====<br />
Url contains the Model website address. Url is read only.<br />
==== ImageUri ====<br />
ImageUri contains a link to the Model image (i.e. icon). ImageUri is read only.<br />
<br />
=== Product ===<br />
There are '''five''' Product parameters; '''Room''', '''Name''', '''Info''', '''Url''' and '''ImageUri'''. They are all text strings.<br />
<br />
==== Room ====<br />
This is the name of the room where the Product is located. Room is used to group the Product with other Products in the same physical room. The Upnp '''''Friendly Name''''' is derived by combining Room and Name in the format {'''''Room&nbsp;: Name'''''}. Products which are '''''Linked''''' always share the same Room name. Room is set to '''''Main Room''''' by default.<br />
<br />
==== Name ====<br />
This is the Product name. The Upnp '''''Friendly Name''''' is derived by combining Room and Name in the format {'''''Room&nbsp;: Name'''''}. By default the Name is the same as the Model. <br />
<br />
==== Info ====<br />
Info contains more Product information. Info is read only.<br />
<br />
==== Url ====<br />
Url contains the Product website address (i.e. UPnP presentation page). Url is read only.<br />
<br />
==== ImageUri ====<br />
ImageUri contains a link to the Product image (i.e. icon). ImageUri is read only.<br />
<br />
== Standby Control==<br />
<br />
=== Standby===<br />
This is the Standby state of the physical product. Standby can be changed using the SetStandby function. Products which are '''''Linked''''' always share the same Standby state. <br />
<br />
<br />
== Source Control ==<br />
<br />
=== Source List===<br />
The Product service maintains a list of all sources within the Product. The size of this list is fixed for each Product and reported by the SourceCount function. Each source can then be referenced by its unique source index* in the list. Only one source, and thus one index, can be active at any given time. When a new source is selected the previous source is automatically deactivated before activating the new source. [* source index is zero based, ie 0,1,2,3,4,5..n, where n=listsize-1]<br />
<br />
=== Source Index ===<br />
<br />
The current (ie currently active) source can be changed by source index or source name. The function SetSourceIndex is used to change the current source by index. If the index is out of range an error will be reported. SetSourceIndexByName is used to change to the source whose name matches that specified. If a source of the specified name does not exist, the source will not change and no error will be reported.<br />
<br />
=== SourceCount ===<br />
<br />
SourceCount returns the number of sources that exist in the Product (ie the source list size). SourceCount is read only.<br />
<br />
<br />
=== Source Specific Parameters ===<br />
Every source has four fundamental parameters, '''SourceSystemName''', '''SourceName''', '''SourceVisible''' and '''SourceType'''.<br />
<br />
==== SourceSystemName ====<br />
<br />
SourceSystemName is a unique name string used to identify each source. SourceSystemName is read only. It can only be read via the '''Source''' action.<br />
<br />
==== SourceName ====<br />
<br />
SourceName is a unique name string assigned to each source. In the default state, for a given source index, SourceName matches SourceSystemName. It can be read via the '''Source''' action, or the '''SourceXml''' action.<br />
<br />
==== SourceType ====<br />
<br />
SourceType is a unique type string assigned to each source. SourceType is read only. It can be read via the '''Source''' action, or the '''SourceXml''' action.<br />
<br />
==== SourceVisible ====<br />
<br />
SourceVisible is a unique flag assigned to each source. This flag is used to indicate whether the source is to be displayed (front panel, GUI etc) when browsing through the source list. It can be read via the '''Source''' action, or the '''SourceXml''' action.<br />
<br />
Note - ''a source's "visibility" does not affect its ability to be selected/activated via the functions SetSourceIndex and SetCurrentSourceByName.''<br />
<br />
= Actions=<br />
<br />
== Network Presentation Actions==<br />
=== Attributes Action ===<br />
The Attributes action reports a string containing a space separated list of all attributes.<br />
<br />
=== Manufacturer Action ===<br />
The Manufacturer action returns all four Manufacturer parameters.<br />
<br />
=== Model Action ===<br />
The Model action returns all four Model parameters.<br />
<br />
=== Product Action ===<br />
The Product action returns all five Product parameters.<br />
<br />
== Standby Actions==<br />
=== Standby===<br />
The Standby action reports the current standby state of the product.<br />
<br />
=== SetStandby===<br />
The SetStandby action provides a means of setting the current standby state of the product.<br />
<br />
==Source Actions==<br />
===SourceXml Action===<br />
The SourceXml action returns a list of all source specific parameters, for every source, in XML format.<br />
<br />
===SourceXmlChangeCount Action===<br />
The SourceXmlChangeCount action returns a count indicating the number of times SourceXml has been updated since power on. This is useful for control points that do not support eventing.<br />
<br />
===Source Action===<br />
The Source action returns all source specific parameters for a given source index.<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Product<br />
Version : 1<br />
</code><br />
<br />
== Product Service Description (XML) ==<br />
<code><br />
</code></div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:ProductServiceAv:Developer:ProductService2011-05-05T13:56:01Z<p>Joshh: </p>
<hr />
<div>= Architectural Overview =<br />
<br />
The Product service contains basic information concerning a single product. It contains information about what kind of device it is: the model, manufacturer, its name, its room, and details concerning each source within the product. Other basic functionality such as control of the product's standby state are also included.<br />
<br />
It should be possible for a control point to create a complete map of the home by subscribing to the Product service of every device.<br />
<br />
== Network Presentation ==<br />
<br />
=== Attributes ===<br />
Every product has one or more attributes indicating additional features offered by that product beyond those provided by its sources<br />
<br />
=== Manufacturer ===<br />
There are '''four''' Manufacturer parameters; '''Name''', '''Info''', '''Url''' and '''ImageUri'''. They are all text strings.<br />
<br />
==== Name ====<br />
Name contains the Manufacturer name. Name is read only.<br />
<br />
==== Info ====<br />
Info contains more Manufacturer information. Info is read only.<br />
<br />
==== Url ====<br />
Url contains the Manufacturer website address. Url is read only.<br />
<br />
==== ImageUri ====<br />
ImageUri contains a link to the Manufacturer image (i.e. logo). ImageUri is read only.<br />
<br />
=== Model ===<br />
<br />
There are '''four''' Model parameters; '''Name''', '''Info''', '''Url''' and '''ImageUri'''.<br />
<br />
==== Name ====<br />
Name contains the Model name. Name is read only.<br />
==== Info ====<br />
Info contains more Model information. Info is read only. <br />
==== Url ====<br />
Url contains the Model website address. Url is read only.<br />
==== ImageUri ====<br />
ImageUri contains a link to the Model image (i.e. icon). ImageUri is read only.<br />
<br />
=== Product ===<br />
There are '''five''' Product parameters; '''Room''', '''Name''', '''Info''', '''Url''' and '''ImageUri'''. They are all text strings.<br />
<br />
==== Room ====<br />
This is the name of the room where the Product is located. Room is used to group the Product with other Products in the same physical room. The Upnp '''''Friendly Name''''' is derived by combining Room and Name in the format {'''''Room&nbsp;: Name'''''}. Products which are '''''Linked''''' always share the same Room name. Room is set to '''''Main Room''''' by default.<br />
<br />
==== Name ====<br />
This is the Product name. The Upnp '''''Friendly Name''''' is derived by combining Room and Name in the format {'''''Room&nbsp;: Name'''''}. By default the Name is the same as the Model. <br />
<br />
==== Info ====<br />
Info contains more Product information. Info is read only.<br />
<br />
==== Url ====<br />
Url contains the Product website address (i.e. UPnP presentation page). Url is read only.<br />
<br />
==== ImageUri ====<br />
ImageUri contains a link to the Product image (i.e. icon). ImageUri is read only.<br />
<br />
== Standby Control==<br />
<br />
=== Standby===<br />
This is the Standby state of the physical product. Standby can be changed using the SetStandby function. Products which are '''''Linked''''' always share the same Standby state. <br />
<br />
<br />
== Source Control ==<br />
<br />
=== Source List===<br />
The Product service maintains a list of all sources within the Product. The size of this list is fixed for each Product and reported by the SourceCount function. Each source can then be referenced by its unique source index* in the list. Only one source, and thus one index, can be active at any given time. When a new source is selected the previous source is automatically deactivated before activating the new source. [* source index is zero based, ie 0,1,2,3,4,5..n, where n=listsize-1]<br />
<br />
=== Source Index ===<br />
<br />
The current (ie currently active) source can be changed by source index or source name. The function SetSourceIndex is used to change the current source by index. If the index is out of range an error will be reported. SetSourceIndexByName is used to change to the source whose name matches that specified. If a source of the specified name does not exist, the source will not change and no error will be reported.<br />
<br />
=== SourceCount ===<br />
<br />
SourceCount returns the number of sources that exist in the Product (ie the source list size). SourceCount is read only.<br />
<br />
<br />
=== Source Specific Parameters ===<br />
Every source has four fundamental parameters, '''SourceSystemName''', '''SourceName''', '''SourceVisible''' and '''SourceType'''.<br />
<br />
==== SourceSystemName ====<br />
<br />
SourceSystemName is a unique name string used to identify each source. SourceSystemName is read only. It can only be read via the '''Source''' action.<br />
<br />
==== SourceName ====<br />
<br />
SourceName is a unique name string assigned to each source. In the default state, for a given source index, SourceName matches SourceSystemName. It can be read via the '''Source''' action, or the '''SourceXml''' action.<br />
<br />
==== SourceType ====<br />
<br />
SourceType is a unique type string assigned to each source. SourceType is read only. It can be read via the '''Source''' action, or the '''SourceXml''' action.<br />
<br />
==== SourceVisible ====<br />
<br />
SourceVisible is a unique flag assigned to each source. This flag is used to indicate whether the source is to be displayed (front panel, GUI etc) when browsing through the source list. It can be read via the '''Source''' action, or the '''SourceXml''' action.<br />
<br />
Note - ''a source's "visibility" does not affect its ability to be selected/activated via the functions SetSourceIndex and SetCurrentSourceByName.''<br />
<br />
= Actions=<br />
<br />
== Network Presentation Actions==<br />
=== Attributes Action ===<br />
The Attributes action reports a string containing a space separated list of all attributes.<br />
<br />
=== Manufacturer Action ===<br />
The Manufacturer action returns all four Manufacturer parameters.<br />
<br />
=== Model Action ===<br />
The Model action returns all four Model parameters.<br />
<br />
=== Product Action ===<br />
The Product action returns all five Product parameters.<br />
<br />
== Standby Actions==<br />
=== Standby===<br />
The Standby action reports the current standby state of the product.<br />
<br />
=== SetStandby===<br />
The SetStandby action provides a means of setting the current standby state of the product.<br />
<br />
==Source Actions==<br />
===SourceXml Action===<br />
The SourceXml action returns a list of all source specific parameters, for every source, in XML format.<br />
<br />
===SourceXmlChangeCount Action===<br />
The SourceXmlChangeCount action returns a count indicating the number of times SourceXml has been updated since power on. This is useful for control points that do not support eventing.<br />
<br />
===Source Action===<br />
The Source action returns all source specific parameters for a given source index.<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Product<br />
Version : 1<br />
</code><br />
[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Product1.xml Product Service Description (XML)]</div>Joshhhttp://wiki.openhome.org/wiki/Av:Developer:ProductServiceAv:Developer:ProductService2011-05-05T13:53:09Z<p>Joshh: </p>
<hr />
<div>= Architectural Overview =<br />
<br />
The Product service contains basic information concerning a single product. It contains information about what kind of device it is: the model, manufacturer, its name, its room, and details concerning each source within the product. Other basic functionality such as control of the product's standby state are also included.<br />
<br />
It should be possible for a control point to create a complete map of the home by subscribing to the Product service of every device.<br />
<br />
== Network Presentation ==<br />
<br />
=== Attributes ===<br />
Every product has one or more attributes indicating additional features offered by that product beyond those provided by its sources<br />
<br />
=== Manufacturer ===<br />
There are '''four''' Manufacturer parameters; '''Name''', '''Info''', '''Url''' and '''ImageUri'''. They are all text strings.<br />
<br />
==== Name ====<br />
Name contains the Manufacturer name. Name is read only.<br />
<br />
==== Info ====<br />
Info contains more Manufacturer information. Info is read only.<br />
<br />
==== Url ====<br />
Url contains the Manufacturer website address. Url is read only.<br />
<br />
==== ImageUri ====<br />
ImageUri contains a link to the Manufacturer image (i.e. logo). ImageUri is read only.<br />
<br />
=== Model ===<br />
<br />
There are '''four''' Model parameters; '''Name''', '''Info''', '''Url''' and '''ImageUri'''.<br />
<br />
==== Name ====<br />
Name contains the Model name. Name is read only.<br />
==== Info ====<br />
Info contains more Model information. Info is read only. <br />
==== Url ====<br />
Url contains the Model website address. Url is read only.<br />
==== ImageUri ====<br />
ImageUri contains a link to the Model image (i.e. icon). ImageUri is read only.<br />
<br />
=== Product ===<br />
There are '''five''' Product parameters; '''Room''', '''Name''', '''Info''', '''Url''' and '''ImageUri'''. They are all text strings.<br />
<br />
==== Room ====<br />
This is the name of the room where the Product is located. Room is used to group the Product with other Products in the same physical room. The Upnp '''''Friendly Name''''' is derived by combining Room and Name in the format {'''''Room&nbsp;: Name'''''}. Products which are '''''Linked''''' always share the same Room name. Room is set to '''''Main Room''''' by default.<br />
<br />
==== Name ====<br />
This is the Product name. The Upnp '''''Friendly Name''''' is derived by combining Room and Name in the format {'''''Room&nbsp;: Name'''''}. By default the Name is the same as the Model. <br />
<br />
==== Info ====<br />
Info contains more Product information. Info is read only.<br />
<br />
==== Url ====<br />
Url contains... Url is read only.<br />
<br />
==== ImageUri ====<br />
ImageUri contains... ImageUri is read only.<br />
<br />
== Standby Control==<br />
<br />
=== Standby===<br />
This is the Standby state of the physical product. Standby can be changed using the SetStandby function. Products which are '''''Linked''''' always share the same Standby state. <br />
<br />
<br />
== Source Control ==<br />
<br />
=== Source List===<br />
The Product service maintains a list of all sources within the Product. The size of this list is fixed for each Product and reported by the SourceCount function. Each source can then be referenced by its unique source index* in the list. Only one source, and thus one index, can be active at any given time. When a new source is selected the previous source is automatically deactivated before activating the new source. [* source index is zero based, ie 0,1,2,3,4,5..n, where n=listsize-1]<br />
<br />
=== Source Index ===<br />
<br />
The current (ie currently active) source can be changed by source index or source name. The function SetSourceIndex is used to change the current source by index. If the index is out of range an error will be reported. SetSourceIndexByName is used to change to the source whose name matches that specified. If a source of the specified name does not exist, the source will not change and no error will be reported.<br />
<br />
=== SourceCount ===<br />
<br />
SourceCount returns the number of sources that exist in the Product (ie the source list size). SourceCount is read only.<br />
<br />
<br />
=== Source Specific Parameters ===<br />
Every source has four fundamental parameters, '''SourceSystemName''', '''SourceName''', '''SourceVisible''' and '''SourceType'''.<br />
<br />
==== SourceSystemName ====<br />
<br />
SourceSystemName is a unique name string used to identify each source. SourceSystemName is read only. It can only be read via the '''Source''' action.<br />
<br />
==== SourceName ====<br />
<br />
SourceName is a unique name string assigned to each source. In the default state, for a given source index, SourceName matches SourceSystemName. It can be read via the '''Source''' action, or the '''SourceXml''' action.<br />
<br />
==== SourceType ====<br />
<br />
SourceType is a unique type string assigned to each source. SourceType is read only. It can be read via the '''Source''' action, or the '''SourceXml''' action.<br />
<br />
==== SourceVisible ====<br />
<br />
SourceVisible is a unique flag assigned to each source. This flag is used to indicate whether the source is to be displayed (front panel, GUI etc) when browsing through the source list. It can be read via the '''Source''' action, or the '''SourceXml''' action.<br />
<br />
Note - ''a source's "visibility" does not affect its ability to be selected/activated via the functions SetSourceIndex and SetCurrentSourceByName.''<br />
<br />
= Actions=<br />
<br />
== Network Presentation Actions==<br />
=== Attributes Action ===<br />
The Attributes action reports a string containing a space separated list of all attributes.<br />
<br />
=== Manufacturer Action ===<br />
The Manufacturer action returns all four Manufacturer parameters.<br />
<br />
=== Model Action ===<br />
The Model action returns all four Model parameters.<br />
<br />
=== Product Action ===<br />
The Product action returns all five Product parameters.<br />
<br />
== Standby Actions==<br />
=== Standby===<br />
The Standby action reports the current standby state of the product.<br />
<br />
=== SetStandby===<br />
The SetStandby action provides a means of setting the current standby state of the product.<br />
<br />
==Source Actions==<br />
===SourceXml Action===<br />
The SourceXml action returns a list of all source specific parameters, for every source, in XML format.<br />
<br />
===SourceXmlChangeCount Action===<br />
The SourceXmlChangeCount action returns a count indicating the number of times SourceXml has been updated since power on. This is useful for control points that do not support eventing.<br />
<br />
===Source Action===<br />
The Source action returns all source specific parameters for a given source index.<br />
<br />
= Technical Details =<br />
<code><br />
Domain : av.openhome.org<br />
Name : Product<br />
Version : 1<br />
</code><br />
[http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Product1.xml Product Service Description (XML)]</div>Joshhhttp://wiki.openhome.org/wiki/OhMedia:DeveloperOhMedia:Developer2011-05-05T09:10:33Z<p>Joshh: /* Multiroom Functionality */</p>
<hr />
<div>= Introduction =<br />
<br />
OpenHome Av is an independent standard for networked audio visual devices. OpenHome Av products all have a standard way of presenting themselves to the network. This makes it possible to write generic Control Point software that is able to control those products independent of manufacturer or specific features.<br />
<br />
The technologies associated with making this possible are grouped under the term OpenHome Av Topology.<br />
<br />
If a developer wishes to write generic software that participates in the aims described above, then they should write that software in a way that conforms to the strategies and algorithms of OpenHome Av Topology, which is described below<br />
<br />
= Topology =<br />
<br />
== Products ==<br />
<br />
An OpenHome installation consists of products from a variety of manufacturers each bearing the [[Developer:ProductService|Product service]].<br />
<br />
Amongst other information, each product has:<br />
<br />
* Room (user configurable, defaults to 'Main Room')<br />
<br />
* Name (user configurable, defaults to the model name)<br />
<br />
* Source Count (fixed according to the capabilities of the product)<br />
<br />
* List of Sources, each with its own Type, Name, and Visibility<br />
<br />
* Attributes, identifying additional functionality offered by the product<br />
<br />
== Proper Configuration ==<br />
<br />
The name of each product represents its audio output.<br />
<br />
The name of each source represents an audio input (either internal or external).<br />
<br />
In a properly configured system, if one product is connected to another using an audio cable, then the name of the product sending the audio should match the name of the source receiving the audio. It is by matching these names that a Control Point is able to select the correct input on, for instance, a preamp when a particular source is selected.<br />
<br />
== Discovering An OpenHome Av System ==<br />
<br />
The correct way to discover an OpenHome Av system is to:<br />
<br />
* search for all units bearing the Product service<br />
<br />
* subscribe to each Product service<br />
<br />
* group these products according to their Room.<br />
<br />
* collect the name of all the sources in each product<br />
<br />
* match the names of the sources to the names of the products to create a set of tree structures in each room.<br />
<br />
== Source Functionality ==<br />
<br />
To determine the kind of functionality available on each source, inspect its type.<br />
<br />
If it has type Playlist, it additionally contains the [[Av:Developer:PlaylistService|Playlist service]]<br />
<br />
If it has type Radio, it additionally contains the [[Av:Developer:RadioService|Radio service]]<br />
<br />
If it has type Receiver, it additionally contains the [[Av:Developer:ReceiverService|Receiver service]]<br />
<br />
== Volume Control ==<br />
<br />
Products that offer volume control include the Volume attribute and the [[Av:Developer:VolumeService|Volume service]]<br />
<br />
The primary volume control offered by a control point should be the one situated nearest the root in the tree structure that contains the current source.<br />
<br />
Control points may optionally provide the user with control of the volume of each product within the tree.<br />
<br />
== Now Playing Information ==<br />
Products that provide information concerning the currently playing media include the [[Av:Developer:InfoService|Info service]]<br />
<br />
Products that report the duration of the currently playing track include the [[Av:Developer:TimeService|Time service]]<br />
<br />
== Multiroom Functionality ==<br />
<br />
The [[Av:Developer:SenderService|Sender service]] indicates the presence of an OpenHome Av sender and provides information concerning that sender.<br />
<br />
An OpenHome Av sender broadcasts music on a network in a way that is playable by an OpenHome Av receiver.<br />
<br />
The [[Av:Developer:ReceiverService|Receiver service]] provides the means for controlling a Receiver source. If a device's [[Developer:ProductService|Product service]] reports a source of type 'Receiver', then that device is guaranteed to bear the [[Av:Developer:ReceiverService|Receiver service]].<br />
<br />
= Services =<br />
<br />
==== Product ====<br />
[[Av:Developer:ProductService|Product service]]<br />
<br />
==== Playlist ====<br />
[[Av:Developer:PlaylistService|Playlist service]]<br />
==== Radio ====<br />
[[Av:Developer:RadioService|Radio service]]<br />
==== Info ====<br />
[[Av:Developer:InfoService|Info service]]<br />
==== Time ====<br />
[[Av:Developer:TimeService|Time service]]<br />
==== Volume ====<br />
[[Av:Developer:VolumeService|Volume service]]<br />
==== Sender ====<br />
[[Av:Developer:SenderService|Sender service]]<br />
==== Receiver ====<br />
[[Av:Developer:ReceiverService|Receiver service]]</div>Joshhhttp://wiki.openhome.org/wiki/OhMedia:DeveloperOhMedia:Developer2011-05-05T09:08:36Z<p>Joshh: /* Multiroom Functionality */</p>
<hr />
<div>= Introduction =<br />
<br />
OpenHome Av is an independent standard for networked audio visual devices. OpenHome Av products all have a standard way of presenting themselves to the network. This makes it possible to write generic Control Point software that is able to control those products independent of manufacturer or specific features.<br />
<br />
The technologies associated with making this possible are grouped under the term OpenHome Av Topology.<br />
<br />
If a developer wishes to write generic software that participates in the aims described above, then they should write that software in a way that conforms to the strategies and algorithms of OpenHome Av Topology, which is described below<br />
<br />
= Topology =<br />
<br />
== Products ==<br />
<br />
An OpenHome installation consists of products from a variety of manufacturers each bearing the [[Developer:ProductService|Product service]].<br />
<br />
Amongst other information, each product has:<br />
<br />
* Room (user configurable, defaults to 'Main Room')<br />
<br />
* Name (user configurable, defaults to the model name)<br />
<br />
* Source Count (fixed according to the capabilities of the product)<br />
<br />
* List of Sources, each with its own Type, Name, and Visibility<br />
<br />
* Attributes, identifying additional functionality offered by the product<br />
<br />
== Proper Configuration ==<br />
<br />
The name of each product represents its audio output.<br />
<br />
The name of each source represents an audio input (either internal or external).<br />
<br />
In a properly configured system, if one product is connected to another using an audio cable, then the name of the product sending the audio should match the name of the source receiving the audio. It is by matching these names that a Control Point is able to select the correct input on, for instance, a preamp when a particular source is selected.<br />
<br />
== Discovering An OpenHome Av System ==<br />
<br />
The correct way to discover an OpenHome Av system is to:<br />
<br />
* search for all units bearing the Product service<br />
<br />
* subscribe to each Product service<br />
<br />
* group these products according to their Room.<br />
<br />
* collect the name of all the sources in each product<br />
<br />
* match the names of the sources to the names of the products to create a set of tree structures in each room.<br />
<br />
== Source Functionality ==<br />
<br />
To determine the kind of functionality available on each source, inspect its type.<br />
<br />
If it has type Playlist, it additionally contains the [[Av:Developer:PlaylistService|Playlist service]]<br />
<br />
If it has type Radio, it additionally contains the [[Av:Developer:RadioService|Radio service]]<br />
<br />
If it has type Receiver, it additionally contains the [[Av:Developer:ReceiverService|Receiver service]]<br />
<br />
== Volume Control ==<br />
<br />
Products that offer volume control include the Volume attribute and the [[Av:Developer:VolumeService|Volume service]]<br />
<br />
The primary volume control offered by a control point should be the one situated nearest the root in the tree structure that contains the current source.<br />
<br />
Control points may optionally provide the user with control of the volume of each product within the tree.<br />
<br />
== Now Playing Information ==<br />
Products that provide information concerning the currently playing media include the [[Av:Developer:InfoService|Info service]]<br />
<br />
Products that report the duration of the currently playing track include the [[Av:Developer:TimeService|Time service]]<br />
<br />
== Multiroom Functionality ==<br />
<br />
The [[Av:Developer:SenderService|Sender service]] indicates the presence of an OpenHome Av sender and provides information concerning that sender.<br />
<br />
An OpenHome Av sender broadcasts music on a network in a way that is playable by an OpenHome Av receiver.<br />
<br />
The [[Av:Developer:ReceiverService|Receiver service]] provides the means for controlling a Receiver source. If a device's [[Developer:ProductService|Product service]] reports a source of type 'Receiver', then that device is guaranteed to bear the Receiver service.<br />
<br />
= Services =<br />
<br />
==== Product ====<br />
[[Av:Developer:ProductService|Product service]]<br />
<br />
==== Playlist ====<br />
[[Av:Developer:PlaylistService|Playlist service]]<br />
==== Radio ====<br />
[[Av:Developer:RadioService|Radio service]]<br />
==== Info ====<br />
[[Av:Developer:InfoService|Info service]]<br />
==== Time ====<br />
[[Av:Developer:TimeService|Time service]]<br />
==== Volume ====<br />
[[Av:Developer:VolumeService|Volume service]]<br />
==== Sender ====<br />
[[Av:Developer:SenderService|Sender service]]<br />
==== Receiver ====<br />
[[Av:Developer:ReceiverService|Receiver service]]</div>Joshhhttp://wiki.openhome.org/wiki/OhMedia:DeveloperOhMedia:Developer2011-05-05T09:06:17Z<p>Joshh: /* Multiroom Functionality */</p>
<hr />
<div>= Introduction =<br />
<br />
OpenHome Av is an independent standard for networked audio visual devices. OpenHome Av products all have a standard way of presenting themselves to the network. This makes it possible to write generic Control Point software that is able to control those products independent of manufacturer or specific features.<br />
<br />
The technologies associated with making this possible are grouped under the term OpenHome Av Topology.<br />
<br />
If a developer wishes to write generic software that participates in the aims described above, then they should write that software in a way that conforms to the strategies and algorithms of OpenHome Av Topology, which is described below<br />
<br />
= Topology =<br />
<br />
== Products ==<br />
<br />
An OpenHome installation consists of products from a variety of manufacturers each bearing the [[Developer:ProductService|Product service]].<br />
<br />
Amongst other information, each product has:<br />
<br />
* Room (user configurable, defaults to 'Main Room')<br />
<br />
* Name (user configurable, defaults to the model name)<br />
<br />
* Source Count (fixed according to the capabilities of the product)<br />
<br />
* List of Sources, each with its own Type, Name, and Visibility<br />
<br />
* Attributes, identifying additional functionality offered by the product<br />
<br />
== Proper Configuration ==<br />
<br />
The name of each product represents its audio output.<br />
<br />
The name of each source represents an audio input (either internal or external).<br />
<br />
In a properly configured system, if one product is connected to another using an audio cable, then the name of the product sending the audio should match the name of the source receiving the audio. It is by matching these names that a Control Point is able to select the correct input on, for instance, a preamp when a particular source is selected.<br />
<br />
== Discovering An OpenHome Av System ==<br />
<br />
The correct way to discover an OpenHome Av system is to:<br />
<br />
* search for all units bearing the Product service<br />
<br />
* subscribe to each Product service<br />
<br />
* group these products according to their Room.<br />
<br />
* collect the name of all the sources in each product<br />
<br />
* match the names of the sources to the names of the products to create a set of tree structures in each room.<br />
<br />
== Source Functionality ==<br />
<br />
To determine the kind of functionality available on each source, inspect its type.<br />
<br />
If it has type Playlist, it additionally contains the [[Av:Developer:PlaylistService|Playlist service]]<br />
<br />
If it has type Radio, it additionally contains the [[Av:Developer:RadioService|Radio service]]<br />
<br />
If it has type Receiver, it additionally contains the [[Av:Developer:ReceiverService|Receiver service]]<br />
<br />
== Volume Control ==<br />
<br />
Products that offer volume control include the Volume attribute and the [[Av:Developer:VolumeService|Volume service]]<br />
<br />
The primary volume control offered by a control point should be the one situated nearest the root in the tree structure that contains the current source.<br />
<br />
Control points may optionally provide the user with control of the volume of each product within the tree.<br />
<br />
== Now Playing Information ==<br />
Products that provide information concerning the currently playing media include the [[Av:Developer:InfoService|Info service]]<br />
<br />
Products that report the duration of the currently playing track include the [[Av:Developer:TimeService|Time service]]<br />
<br />
== Multiroom Functionality ==<br />
<br />
The [[Av:Developer:SenderService|Sender service]] indicates the presence of an OpenHome Av sender and provides information concerning that sender.<br />
<br />
An OpenHome Av sender broadcasts music on a network in a way that is playable by an OpenHome Av [[Developer:ReceiverService|receiver]].<br />
<br />
The [[Av:Developer:ReceiverService|Receiver service]] provides the means for controlling a Receiver source. If a device's [[Developer:ProductService|Product service]] reports a source of type 'Receiver', then that device is guaranteed to bear the Receiver service.<br />
<br />
= Services =<br />
<br />
==== Product ====<br />
[[Av:Developer:ProductService|Product service]]<br />
<br />
==== Playlist ====<br />
[[Av:Developer:PlaylistService|Playlist service]]<br />
==== Radio ====<br />
[[Av:Developer:RadioService|Radio service]]<br />
==== Info ====<br />
[[Av:Developer:InfoService|Info service]]<br />
==== Time ====<br />
[[Av:Developer:TimeService|Time service]]<br />
==== Volume ====<br />
[[Av:Developer:VolumeService|Volume service]]<br />
==== Sender ====<br />
[[Av:Developer:SenderService|Sender service]]<br />
==== Receiver ====<br />
[[Av:Developer:ReceiverService|Receiver service]]</div>Joshh