http://wiki.openhome.org/mediawiki/index.php?feed=atom&target=Keith&title=Special%3AContributions%2FKeith 2026-05-22T03:36:41Z From OpenHome MediaWiki 1.16.2 http://wiki.openhome.org/wiki/OhNet 2013-12-12T19:16:58Z

<p>Keith: /* How do I get it? */</p> <hr /> <div>=ohNet=<br /> <br /> == What is it? ==<br /> OpenHome Networking (ohNet) is a modern, cross platform UPnP stack. ohNet includes both a control point and a device stack that can be used together or independently. It runs on Linux, Windows, Mac, iOS and Android. The public APIs are available for the device and control point stacks in C++, C#, Java and C. JavaScript APIs are also provided for the control point stack.<br /> <br /> UPnP services are presented as classes with actions appearing as functions and state variables appearing as member variables. These classes are referred to as proxies for users of the control point stack and providers for users of the device stack.<br /> <br /> Proxies and Providers are included for all OpenHome and UPnP AV services. If your application uses other services, ohNet includes a tool (ohNetGen) to generate proxies and/or providers from the service XML in any of the supported languages.<br /> <br /> == How do I get it? ==<br /> [http://www.openhome.org/releases/artifacts/ohNet Binaries are available] for certain popular platforms/architectures.<br /> <br /> == Documentation ==<br /> === Overview docs ===<br /> * [http://www.openhome.org/releases/ohNet_ControlPointStack.pdf Control Point stack (PDF)]<br /> * [http://www.openhome.org/releases/ohNet_DeviceStack.pdf Device stack (PDF)]<br /> <br /> === API docs ===<br /> * [http://www.openhome.org/build/nightly/docs/CppStd/ C++]<br /> * [http://www.openhome.org/build/nightly/docs/Cs/ C#]<br /> * [http://www.openhome.org/build/nightly/docs/Java/ Java]<br /> * [http://www.openhome.org/build/nightly/docs/Js/ JavaScript]<br /> * [http://www.openhome.org/build/nightly/docs/C/ C]<br /> <br /> === Discussion ===<br /> [http://forums.openhome.org/forumdisplay.php?fid=5 Developer forum]<br /> <br /> <br /> <br /> ohNet is written using C++ with std::string replaced by special buffer classes. These buffer classes allow for more efficient use of memory at the cost of a steeper learning curve. Memory use benefits can be especially pronounced for the Device stack. [http://www.openhome.org/build/nightly/docs/CppCore/ API docs] for this version of the stack are available but the buffer classes are intended for internal use of the library and are as such currently undocumented.</div>

Keith http://wiki.openhome.org/wiki/OhNet 2013-12-12T19:15:50Z

<p>Keith: /* What is it? */</p> <hr /> <div>=ohNet=<br /> <br /> == What is it? ==<br /> OpenHome Networking (ohNet) is a modern, cross platform UPnP stack. ohNet includes both a control point and a device stack that can be used together or independently. It runs on Linux, Windows, Mac, iOS and Android. The public APIs are available for the device and control point stacks in C++, C#, Java and C. JavaScript APIs are also provided for the control point stack.<br /> <br /> UPnP services are presented as classes with actions appearing as functions and state variables appearing as member variables. These classes are referred to as proxies for users of the control point stack and providers for users of the device stack.<br /> <br /> Proxies and Providers are included for all OpenHome and UPnP AV services. If your application uses other services, ohNet includes a tool (ohNetGen) to generate proxies and/or providers from the service XML in any of the supported languages.<br /> <br /> == How do I get it? ==<br /> ohNet is available as [https://github.com/openhome/ohNet source code]. Setup a (free) github account then<br /> git clone git@github.com:openhome/ohNet.git ohnet<br /> build using<br /> cd ohnet<br /> make<br /> <br /> There are also [http://www.openhome.org/releases/artifacts/ohNet binaries available] for certain popular platforms/architectures.<br /> <br /> == Documentation ==<br /> === Overview docs ===<br /> * [http://www.openhome.org/releases/ohNet_ControlPointStack.pdf Control Point stack (PDF)]<br /> * [http://www.openhome.org/releases/ohNet_DeviceStack.pdf Device stack (PDF)]<br /> <br /> === API docs ===<br /> * [http://www.openhome.org/build/nightly/docs/CppStd/ C++]<br /> * [http://www.openhome.org/build/nightly/docs/Cs/ C#]<br /> * [http://www.openhome.org/build/nightly/docs/Java/ Java]<br /> * [http://www.openhome.org/build/nightly/docs/Js/ JavaScript]<br /> * [http://www.openhome.org/build/nightly/docs/C/ C]<br /> <br /> === Discussion ===<br /> [http://forums.openhome.org/forumdisplay.php?fid=5 Developer forum]<br /> <br /> <br /> <br /> ohNet is written using C++ with std::string replaced by special buffer classes. These buffer classes allow for more efficient use of memory at the cost of a steeper learning curve. Memory use benefits can be especially pronounced for the Device stack. [http://www.openhome.org/build/nightly/docs/CppCore/ API docs] for this version of the stack are available but the buffer classes are intended for internal use of the library and are as such currently undocumented.</div>

Keith http://wiki.openhome.org/wiki/OhMedia 2013-07-10T15:43:13Z

<p>Keith: /* What is ohMedia? */</p> <hr /> <div>=What is ohMedia?=<br /> <br /> OpenHome Media (ohMedia) is an open standard for networked audio devices in the home. Devices can implement ohMedia in place of, or alongside of, the UPnP Forum’s AV standards. It offers a number of advantages over the UPnP Forum's AV standards.<br /> <br /> * Playlists are stored on the renderer, allowing playback to continue when the control point leaves the network (e.g. the control point application closes or its host device powers down).<br /> * Storing playlists on the renderer also allows for gapless playback, avoiding gaps between tracks that were intended to merge seamlessly. This is particularly important for live albums and classical music. <br /> * Multiple control points are better supported. Storing a playlist on the renderer allows multiple control points to edit the order of tracks and display metadata (including track name and album art) for the entire playlist. <br /> * Share music between renderers. The Songcast protocol allows an ohMedia renderer to share its content with any other ohMedia device or listen to content from another device. Synchronised audio can be played between any number of devices. Desktop songcast applications plus mobile support (Songcast app for Android; Airplay receiver for iOS) allows content from many other devices to be shared. <br /> * Internet radio and a receiver for Apple's AirPlay are also natively supported. <br /> * Playlists can be more easily &amp; reliably saved and reused. Many popular UPnP media servers change track URIs whenever they rebuild their database (e.g. every time new content is added to the database). ohMedia’s reference server - Songbox - guarantees to retain track URIs across rebuilds, allowing saving and repeated reuse of playlists. <br /> * Support for multi-product hi-fi systems. E.g. a media renderer with a separate pre-amp. ohMedia topology algorithms allow a control point to select the volume control on the pre-amp.<br /> <br /> = Reference Implementations =<br /> <br /> * [http://core.linn.co.uk/network/wiki/ohMediaPlayer-Integrator ohMediaPlayer] – cross-platform software renderer including both !OpenHome and UPnP forum network services. Capable of being deployed to desktop or embedded platforms.<br /> * [http://www.linn.co.uk/software#songbox Songbox] – media server including both OpenHome and UPnP forum network services. Capable of being deployed to desktop and some NAS platforms.<br /> * [http://www.linn.co.uk/software#songcast Songcast] – application that sends local audio to an ohMedia renderer. Available for Windows &amp; Mac.<br /> * [http://www.linn.co.uk/software#kinsky Kinsky] – control point for ohMedia renderer. Available for all major desktop and mobile platforms.<br /> Some of these products are released with Linn Products branding. All are based on generic OpenHome technology. We’d be happy to hear from anyone who wants to work with us to simplify skinning of these products.<br /> <br /> = Developers =<br /> If you are interested in ohMedia development, [[Media:Developers|further information is available]]</div>

Keith http://wiki.openhome.org/wiki/OhNet 2013-07-10T15:42:47Z

<p>Keith: /* What is it? */</p> <hr /> <div>=ohNet=<br /> <br /> == What is it? ==<br /> OpenHome Networking (ohNet) is a modern, cross platform UPnP stack. ohNet includes both a control point and a device stack that can be used together or independently. It runs on Linux, Windows, Mac, iOS and Android. The public APIs are available for the device and control point stacks in C++, C#, Java and C. JavaScript APIs are also provided for the control point stack.<br /> <br /> UPnP services are presented as classes with actions appearing as functions and state variables appearing as member variables. These classes are referred to as proxies for users of the control point stack and providers for users of the device stack.<br /> <br /> Proxies and Providers are included for all OpenHome and UPnP AV services. If your application uses other services, ohNet includes a tool (ohNetGen) to generate proxies and/or providers from the service XML in any of the supported languages.<br /> <br /> Source code is available under a [http://www.opensource.org/licenses/bsd-license.php Simplified BSD license].<br /> <br /> == How do I get it? ==<br /> ohNet is available as [https://github.com/openhome/ohNet source code]. Setup a (free) github account then<br /> git clone git@github.com:openhome/ohNet.git ohnet<br /> build using<br /> cd ohnet<br /> make<br /> <br /> There are also [http://www.openhome.org/releases/artifacts/ohNet binaries available] for certain popular platforms/architectures.<br /> <br /> == Documentation ==<br /> === Overview docs ===<br /> * [http://www.openhome.org/releases/ohNet_ControlPointStack.pdf Control Point stack (PDF)]<br /> * [http://www.openhome.org/releases/ohNet_DeviceStack.pdf Device stack (PDF)]<br /> <br /> === API docs ===<br /> * [http://www.openhome.org/build/nightly/docs/CppStd/ C++]<br /> * [http://www.openhome.org/build/nightly/docs/Cs/ C#]<br /> * [http://www.openhome.org/build/nightly/docs/Java/ Java]<br /> * [http://www.openhome.org/build/nightly/docs/Js/ JavaScript]<br /> * [http://www.openhome.org/build/nightly/docs/C/ C]<br /> <br /> === Discussion ===<br /> [http://forums.openhome.org/forumdisplay.php?fid=5 Developer forum]<br /> <br /> <br /> <br /> ohNet is written using C++ with std::string replaced by special buffer classes. These buffer classes allow for more efficient use of memory at the cost of a steeper learning curve. Memory use benefits can be especially pronounced for the Device stack. [http://www.openhome.org/build/nightly/docs/CppCore/ API docs] for this version of the stack are available but the buffer classes are intended for internal use of the library and are as such currently undocumented.</div>

Keith http://wiki.openhome.org/wiki/OhMedia 2013-07-10T15:42:07Z

<p>Keith: /* What is ohMedia? */</p> <hr /> <div>=What is ohMedia?=<br /> <br /> OpenHome Media (ohMedia) is an open standard for networked audio devices in the home. Devices can implement ohMedia in place of, or alongside of, the UPnP Forum’s AV standards. It offers a number of significant advantages over the UPnP Forum's AV standards.<br /> <br /> * Playlists are stored on the renderer, allowing playback to continue when the control point leaves the network (e.g. the control point application closes or its host device powers down).<br /> * Storing playlists on the renderer also allows for gapless playback, avoiding gaps between tracks that were intended to merge seamlessly. This is particularly important for live albums and classical music. <br /> * Multiple control points are better supported. Storing a playlist on the renderer allows multiple control points to edit the order of tracks and display metadata (including track name and album art) for the entire playlist. <br /> * Share music between renderers. The Songcast protocol allows an ohMedia renderer to share its content with any other ohMedia device or listen to content from another device. Synchronised audio can be played between any number of devices. Desktop songcast applications plus mobile support (Songcast app for Android; Airplay receiver for iOS) allows content from many other devices to be shared. <br /> * Internet radio and a receiver for Apple's AirPlay are also natively supported. <br /> * Playlists can be more easily &amp; reliably saved and reused. Many popular UPnP media servers change track URIs whenever they rebuild their database (e.g. every time new content is added to the database). ohMedia’s reference server - Songbox - guarantees to retain track URIs across rebuilds, allowing saving and repeated reuse of playlists. <br /> * Support for multi-product hi-fi systems. E.g. a media renderer with a separate pre-amp. ohMedia topology algorithms allow a control point to select the volume control on the pre-amp.<br /> <br /> = Reference Implementations =<br /> <br /> * [http://core.linn.co.uk/network/wiki/ohMediaPlayer-Integrator ohMediaPlayer] – cross-platform software renderer including both !OpenHome and UPnP forum network services. Capable of being deployed to desktop or embedded platforms.<br /> * [http://www.linn.co.uk/software#songbox Songbox] – media server including both OpenHome and UPnP forum network services. Capable of being deployed to desktop and some NAS platforms.<br /> * [http://www.linn.co.uk/software#songcast Songcast] – application that sends local audio to an ohMedia renderer. Available for Windows &amp; Mac.<br /> * [http://www.linn.co.uk/software#kinsky Kinsky] – control point for ohMedia renderer. Available for all major desktop and mobile platforms.<br /> Some of these products are released with Linn Products branding. All are based on generic OpenHome technology. We’d be happy to hear from anyone who wants to work with us to simplify skinning of these products.<br /> <br /> = Developers =<br /> If you are interested in ohMedia development, [[Media:Developers|further information is available]]</div>

Keith http://wiki.openhome.org/wiki/Oh:Overview 2013-07-10T15:38:54Z

<p>Keith: </p> <hr /> <div>= OPENHOME =<br /> <br /> <br /> <br /> == ohMedia ==<br /> <br /> [[ohMedia|ohMedia]] is an open standard that allows the seamless interaction of media within your home.<br /> <br /> == ohNet ==<br /> <br /> [[ohNet|ohNet]] is a modern cross platform networking stack.<br /> <br /> <br /> __NOTOC__</div>

Keith http://wiki.openhome.org/wiki/Oh:Overview 2013-07-10T15:38:31Z

<p>Keith: </p> <hr /> <div>= OPENHOME =<br /> <br /> <br /> <br /> == [[ohMedia|ohMedia]] ==<br /> <br /> [[ohMedia|ohMedia]] is an open standard that allows the seamless interaction of media within your home.<br /> <br /> == [[ohNet|ohNet]] ==<br /> <br /> [[ohNet|ohNet]] is a modern cross platform networking stack.<br /> <br /> <br /> __NOTOC__</div>

Keith http://wiki.openhome.org/wiki/OhMedia 2013-07-04T13:16:51Z

<p>Keith: /* Developers */</p> <hr /> <div>=What is ohMedia?=<br /> <br /> ohMedia is an open standard for networked audio devices. Devices can implement it in place of or in addition to the UPnP Forum’s AV standards. It offers a number of advantages over basic UPnP:<br /> <br /> * Playlists are stored on the renderer, allowing playback to continue when the control point leaves the network (e.g. the control point application closes or its host device powers down).<br /> * Storing playlists on the renderer also allows for gapless playback, avoiding gaps between tracks that were intended to merge seamlessly. This is particularly important for live albums and classical music. <br /> * Multiple control points are better supported. Storing a playlist on the renderer allows multiple control points to edit the order of tracks and display metadata (including track name and album art) for the entire playlist. <br /> * Share music between renderers. The Songcast protocol allows an ohMedia renderer to share its content with any other ohMedia device or listen to content from another device. Synchronised audio can be played between any number of devices. Desktop songcast applications plus mobile support (Songcast app for Android; Airplay receiver for iOS) allows content from many other devices to be shared. <br /> * Internet radio and a receiver for Apple's AirPlay are also natively supported. <br /> * Playlists can be more easily &amp; reliably saved and reused. Many popular UPnP media servers change track URIs whenever they rebuild their database (e.g. every time new content is added to the database). ohMedia’s reference server - Songbox - guarantees to retain track URIs across rebuilds, allowing saving and repeated reuse of playlists. <br /> * Support for multi-product hi-fi systems. E.g. a media renderer with a separate pre-amp. ohMedia topology algorithms allow a control point to select the volume control on the pre-amp. <br /> <br /> = Reference Implementations =<br /> <br /> * [http://core.linn.co.uk/network/wiki/ohMediaPlayer-Integrator ohMediaPlayer] – cross-platform software renderer including both !OpenHome and UPnP forum network services. Capable of being deployed to desktop or embedded platforms.<br /> * [http://www.linn.co.uk/software#songbox Songbox] – media server including both OpenHome and UPnP forum network services. Capable of being deployed to desktop and some NAS platforms.<br /> * [http://www.linn.co.uk/software#songcast Songcast] – application that sends local audio to an ohMedia renderer. Available for Windows &amp; Mac.<br /> * [http://www.linn.co.uk/software#kinsky Kinsky] – control point for ohMedia renderer. Available for all major desktop and mobile platforms.<br /> Some of these products are released with Linn Products branding. All are based on generic OpenHome technology. We’d be happy to hear from anyone who wants to work with us to simplify skinning of these products.<br /> <br /> = Developers =<br /> If you are interested in ohMedia development, [[Media:Developers|further information is available]]</div>

Keith http://wiki.openhome.org/wiki/OhMedia 2013-07-04T13:15:10Z

<p>Keith: /* Reference Implementations */</p> <hr /> <div>=What is ohMedia?=<br /> <br /> ohMedia is an open standard for networked audio devices. Devices can implement it in place of or in addition to the UPnP Forum’s AV standards. It offers a number of advantages over basic UPnP:<br /> <br /> * Playlists are stored on the renderer, allowing playback to continue when the control point leaves the network (e.g. the control point application closes or its host device powers down).<br /> * Storing playlists on the renderer also allows for gapless playback, avoiding gaps between tracks that were intended to merge seamlessly. This is particularly important for live albums and classical music. <br /> * Multiple control points are better supported. Storing a playlist on the renderer allows multiple control points to edit the order of tracks and display metadata (including track name and album art) for the entire playlist. <br /> * Share music between renderers. The Songcast protocol allows an ohMedia renderer to share its content with any other ohMedia device or listen to content from another device. Synchronised audio can be played between any number of devices. Desktop songcast applications plus mobile support (Songcast app for Android; Airplay receiver for iOS) allows content from many other devices to be shared. <br /> * Internet radio and a receiver for Apple's AirPlay are also natively supported. <br /> * Playlists can be more easily &amp; reliably saved and reused. Many popular UPnP media servers change track URIs whenever they rebuild their database (e.g. every time new content is added to the database). ohMedia’s reference server - Songbox - guarantees to retain track URIs across rebuilds, allowing saving and repeated reuse of playlists. <br /> * Support for multi-product hi-fi systems. E.g. a media renderer with a separate pre-amp. ohMedia topology algorithms allow a control point to select the volume control on the pre-amp. <br /> <br /> = Reference Implementations =<br /> <br /> * [http://core.linn.co.uk/network/wiki/ohMediaPlayer-Integrator ohMediaPlayer] – cross-platform software renderer including both !OpenHome and UPnP forum network services. Capable of being deployed to desktop or embedded platforms.<br /> * [http://www.linn.co.uk/software#songbox Songbox] – media server including both OpenHome and UPnP forum network services. Capable of being deployed to desktop and some NAS platforms.<br /> * [http://www.linn.co.uk/software#songcast Songcast] – application that sends local audio to an ohMedia renderer. Available for Windows &amp; Mac.<br /> * [http://www.linn.co.uk/software#kinsky Kinsky] – control point for ohMedia renderer. Available for all major desktop and mobile platforms.<br /> Some of these products are released with Linn Products branding. All are based on generic OpenHome technology. We’d be happy to hear from anyone who wants to work with us to simplify skinning of these products.<br /> <br /> = Developers =<br /> If you are interested in ohMedia development, [[ohMedia-Developers|further information is available]]</div>

Keith http://wiki.openhome.org/wiki/OhMedia 2013-07-04T13:14:41Z

<p>Keith: /* Reference Implementations */</p> <hr /> <div>=What is ohMedia?=<br /> <br /> ohMedia is an open standard for networked audio devices. Devices can implement it in place of or in addition to the UPnP Forum’s AV standards. It offers a number of advantages over basic UPnP:<br /> <br /> * Playlists are stored on the renderer, allowing playback to continue when the control point leaves the network (e.g. the control point application closes or its host device powers down).<br /> * Storing playlists on the renderer also allows for gapless playback, avoiding gaps between tracks that were intended to merge seamlessly. This is particularly important for live albums and classical music. <br /> * Multiple control points are better supported. Storing a playlist on the renderer allows multiple control points to edit the order of tracks and display metadata (including track name and album art) for the entire playlist. <br /> * Share music between renderers. The Songcast protocol allows an ohMedia renderer to share its content with any other ohMedia device or listen to content from another device. Synchronised audio can be played between any number of devices. Desktop songcast applications plus mobile support (Songcast app for Android; Airplay receiver for iOS) allows content from many other devices to be shared. <br /> * Internet radio and a receiver for Apple's AirPlay are also natively supported. <br /> * Playlists can be more easily &amp; reliably saved and reused. Many popular UPnP media servers change track URIs whenever they rebuild their database (e.g. every time new content is added to the database). ohMedia’s reference server - Songbox - guarantees to retain track URIs across rebuilds, allowing saving and repeated reuse of playlists. <br /> * Support for multi-product hi-fi systems. E.g. a media renderer with a separate pre-amp. ohMedia topology algorithms allow a control point to select the volume control on the pre-amp. <br /> <br /> = Reference Implementations =<br /> <br /> * [http://core.linn.co.uk/network/wiki/ohMediaPlayer-Integrator ohMediaPlayer] – cross-platform software renderer including both !OpenHome and UPnP forum network services. Capable of being deployed to desktop or embedded platforms.<br /> * [http://www.linn.co.uk/software#songbox Songbox] – media server including both !OpenHome and UPnP forum network services. Capable of being deployed to desktop and some NAS platforms.<br /> * [http://www.linn.co.uk/software#songcast Songcast] – application that sends local audio to an ohMedia renderer. Available for Windows &amp; Mac.<br /> * [http://www.linn.co.uk/software#kinsky Kinsky] – control point for ohMedia renderer. Available for all major desktop and mobile platforms.<br /> Some of these products are released with Linn Products branding. All are based on generic !OpenHome technology. We’d be happy to hear from anyone who wants to work with us to simplify skinning of these products.<br /> <br /> = Developers =<br /> If you are interested in ohMedia development, [[ohMedia-Developers|further information is available]]</div>

Keith http://wiki.openhome.org/wiki/OhMedia 2013-07-04T12:53:25Z

<p>Keith: </p> <hr /> <div>=What is ohMedia?=<br /> <br /> ohMedia is an open standard for networked audio devices. Devices can implement it in place of or in addition to the UPnP Forum’s AV standards. It offers a number of advantages over basic UPnP:<br /> <br /> * Playlists are stored on the renderer, allowing playback to continue when the control point leaves the network (e.g. the control point application closes or its host device powers down).<br /> * Storing playlists on the renderer also allows for gapless playback, avoiding gaps between tracks that were intended to merge seamlessly. This is particularly important for live albums and classical music. <br /> * Multiple control points are better supported. Storing a playlist on the renderer allows multiple control points to edit the order of tracks and display metadata (including track name and album art) for the entire playlist. <br /> * Share music between renderers. The Songcast protocol allows an ohMedia renderer to share its content with any other ohMedia device or listen to content from another device. Synchronised audio can be played between any number of devices. Desktop songcast applications plus mobile support (Songcast app for Android; Airplay receiver for iOS) allows content from many other devices to be shared. <br /> * Internet radio and a receiver for Apple's AirPlay are also natively supported. <br /> * Playlists can be more easily &amp; reliably saved and reused. Many popular UPnP media servers change track URIs whenever they rebuild their database (e.g. every time new content is added to the database). ohMedia’s reference server - Songbox - guarantees to retain track URIs across rebuilds, allowing saving and repeated reuse of playlists. <br /> * Support for multi-product hi-fi systems. E.g. a media renderer with a separate pre-amp. ohMedia topology algorithms allow a control point to select the volume control on the pre-amp. <br /> <br /> = Reference Implementations =</div>

Keith http://wiki.openhome.org/wiki/OhMedia 2013-07-04T12:46:50Z

<p>Keith: </p> <hr /> <div>=What is ohMedia?=<br /> <br /> ohMedia is an open standard for networked audio devices. Devices can implement it in place of or in addition to the UPnP Forum’s AV standards. It offers a number of advantages over basic UPnP:<br /> <br /> * Playlists are stored on the renderer, allowing playback to continue when the control point leaves the network (e.g. the control point application closes or its host device powers down).</div>

Keith http://wiki.openhome.org/wiki/OhMedia 2013-07-04T12:45:45Z

<p>Keith: Replaced content with &quot;=What is ohMedia?= ohMedia is an open standard for networked audio devices. Devices can implement it in place of or in addition to the UPnP Forum’s AV standards. It offers...&quot;</p> <hr /> <div>=What is ohMedia?=<br /> <br /> ohMedia is an open standard for networked audio devices. Devices can implement it in place of or in addition to the UPnP Forum’s AV standards. It offers a number of advantages over basic UPnP:</div>

Keith http://wiki.openhome.org/wiki/OhMedia 2012-10-26T16:59:58Z

<p>Keith: /* 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 /> &lt;!-- &lt;picture&gt;--&gt;<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 /> Developer information is also available [[Av:Developer | here]]<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 /> = ohMedia 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 /> &lt;!-- &lt;picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve&gt;--&gt;<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 /> &lt;!--&lt;diagram of a product with multi-in, one out&gt;--&gt;<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 /> &lt;!--&lt;picture of example&gt;--&gt;<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 /> = Developers =<br /> <br /> If you are interested in ohMedia development, more information can be found [[Av:Developer|here]]<br /> <br /> <br /> __NOTOC__</div>

Keith http://wiki.openhome.org/wiki/OhMedia 2012-10-26T16:59:51Z

<p>Keith: /* 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 /> &lt;!-- &lt;picture&gt;--&gt;<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 /> Developer information is also available [[Av:Developer | here]]<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 /> = ohMedia 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 /> &lt;!-- &lt;picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve&gt;--&gt;<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 /> &lt;!--&lt;diagram of a product with multi-in, one out&gt;--&gt;<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 /> &lt;!--&lt;picture of example&gt;--&gt;<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 /> == Server ==<br /> <br /> &lt;&lt;to do&gt;&gt;<br /> <br /> = Developers =<br /> <br /> If you are interested in ohMedia development, more information can be found [[Av:Developer|here]]<br /> <br /> <br /> __NOTOC__</div>

Keith http://wiki.openhome.org/wiki/OhMedia 2012-07-30T16:32:14Z

<p>Keith: /* 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 /> &lt;!-- &lt;picture&gt;--&gt;<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 /> Developer information is also available [[Av:Developer | here]]<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 /> = ohMedia 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 /> &lt;!-- &lt;picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve&gt;--&gt;<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 /> &lt;!--&lt;diagram of a product with multi-in, one out&gt;--&gt;<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 /> &lt;!--&lt;picture of example&gt;--&gt;<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 /> &lt;&lt;to do&gt;&gt;<br /> <br /> == Server ==<br /> <br /> &lt;&lt;to do&gt;&gt;<br /> <br /> = Developers =<br /> <br /> If you are interested in ohMedia development, more information can be found [[Av:Developer|here]]<br /> <br /> <br /> __NOTOC__</div>

Keith http://wiki.openhome.org/wiki/OhMedia 2012-07-30T16:31:59Z

<p>Keith: /* 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 /> &lt;!-- &lt;picture&gt;--&gt;<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 /> Developer information is also available [[Av:Developer | here]]<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 /> = ohMedia 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 /> &lt;!-- &lt;picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve&gt;--&gt;<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 /> &lt;!--&lt;diagram of a product with multi-in, one out&gt;--&gt;<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 /> &lt;!-&lt;picture of example&gt;--&gt;<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 /> &lt;&lt;to do&gt;&gt;<br /> <br /> == Server ==<br /> <br /> &lt;&lt;to do&gt;&gt;<br /> <br /> = Developers =<br /> <br /> If you are interested in ohMedia development, more information can be found [[Av:Developer|here]]<br /> <br /> <br /> __NOTOC__</div>

Keith http://wiki.openhome.org/wiki/OhMedia 2012-07-30T16:31:18Z

<p>Keith: /* ohMedia 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 /> &lt;!-- &lt;picture&gt;--&gt;<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 /> Developer information is also available [[Av:Developer | here]]<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 /> = ohMedia 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 /> &lt;&lt;picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve&gt;&gt;<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 /> &lt;&lt;diagram of a product with multi-in, one out&gt;&gt;<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 /> &lt;&lt;picture of example&gt;&gt;<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 /> &lt;&lt;to do&gt;&gt;<br /> <br /> == Server ==<br /> <br /> &lt;&lt;to do&gt;&gt;<br /> <br /> = Developers =<br /> <br /> If you are interested in ohMedia development, more information can be found [[Av:Developer|here]]<br /> <br /> <br /> __NOTOC__</div>

Keith http://wiki.openhome.org/wiki/OhMedia 2012-07-30T16:30:09Z

<p>Keith: /* ohMedia 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 /> &lt;&lt;picture&gt;&gt;<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 /> Developer information is also available [[Av:Developer | here]]<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 /> = ohMedia 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 /> &lt;&lt;picture of 3 devices as before, but with arrows labelled with 1. Browse, 2. Tell, 3. Retrieve&gt;&gt;<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 /> &lt;&lt;diagram of a product with multi-in, one out&gt;&gt;<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 /> &lt;&lt;picture of example&gt;&gt;<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 /> &lt;&lt;to do&gt;&gt;<br /> <br /> == Server ==<br /> <br /> &lt;&lt;to do&gt;&gt;<br /> <br /> = Developers =<br /> <br /> If you are interested in ohMedia development, more information can be found [[Av:Developer|here]]<br /> <br /> <br /> __NOTOC__</div>

Keith http://wiki.openhome.org/wiki/Oh:Overview 2012-07-30T16:27:41Z

<p>Keith: /* Utilities */</p> <hr /> <div>= OPENHOME DEVELOPMENT =<br /> <br /> <br /> [[File:Jigsaw.png|300px|center]]<br /> <br /> &lt;center&gt; OpenHome currently sponsors two major programmes, ohOs and ohMedia. &lt;/center&gt;<br /> <br /> == Programmes ==<br /> <br /> === [[ohOs|ohOs]] ===<br /> <br /> The OpenHome Operating System provides an OS layer for the deployment and hosting of apps. The [[ohOs|ohOs]] sits on top of all popular base operating systems such as Windows, Linux and Mac.<br /> <br /> === [[ohMedia|ohMedia]] ===<br /> <br /> [[ohMedia|ohMedia]] is an open standard that allows the seamless interaction of media within your home.<br /> <br /> == Libraries ==<br /> <br /> In addition to these programmes, OpenHome also makes available ohNet.<br /> <br /> === [[ohNet|ohNet]] ===<br /> [[ohNet|ohNet]] is a modern cross platform networking stack.<br /> <br /> <br /> __NOTOC__</div>

Keith http://wiki.openhome.org/wiki/OhNet:What 2011-10-10T11:21:34Z

<p>Keith: </p> <hr /> <div>{{nav_openhome_ohnet|ohNet - What is it?}}<br /> ohNet is a modern, cross platform UPnP stack. ohNet includes both a control point and a device stack that can be used together or independently. It runs on Linux, Windows, Mac, iOS and Android. The public APIs are available for the device and control point stacks in C++, C#, Java, C. There is an JavaScript api for the control point stack.<br /> <br /> UPnP services are presented as classes with actions appearing as functions and state variables appearing as member variables. These classes are referred to as proxies for users of the control point stack and providers for users of the device stack.<br /> <br /> Proxies and Providers are included for all OpenHome and UPnP AV services. If your application uses other services, ohNet includes a tool (ohNetGen) to generate proxies and/or providers from the service XML in any of the supported languages.<br /> <br /> Source code is available under a Simplified BSD license.</div>

Keith http://wiki.openhome.org/wiki/OhNet:What 2011-10-10T11:19:57Z

<p>Keith: </p> <hr /> <div>{{nav_openhome_ohnet|ohNet - What is it?}}<br /> ohNet is a modern, thoughtfully architected, cross platform, UPnP stack. ohNet includes both full control point and device stacks that can be used together or independently. It runs on Linux, Windows, Mac, iOS and Android. The public APIs are available for the device and control point stacks in C++, C#, Java, C. There is an JavaScript api for the control point stack.<br /> <br /> UPnP services are presented as classes with actions appearing as functions and state variables appearing as member variables. These classes are referred to as proxies for users of the control point stack and providers for users of the device stack.<br /> <br /> Proxies and Providers are included for all OpenHome and UPnP AV services. If your application uses other services, ohNet includes a tool (ohNetGen) to generate proxies and/or providers from the service XML in any of the supported languages.<br /> <br /> Source code is available under a Simplified BSD license.</div>

Keith http://wiki.openhome.org/wiki/OhMedia:How 2011-10-10T11:04:16Z

<p>Keith: /* Player Implementations */</p> <hr /> <div>{{nav_openhome_av|OpenHome Media - How do I get it?}}<br /> <br /> == Control Point Implementations ==<br /> <br /> [http://web.me.com/sean.harding/ChorusDS/Overview.html Chorus]<br /> <br /> [http://oss.linn.co.uk Kinsky]<br /> <br /> [http://leia.sommerfeldt.f-m.fm/ Leia]<br /> <br /> [http://bookshelfapps.com/songbook-ds.php Songbook]<br /> <br /> == Player Implementations ==<br /> <br /> [http://www.linn.co.uk/digital_stream_players Linn]<br /> <br /> [[ohMediaPlayer:What | OpenHome Media Player]]<br /> <br /> == Media Server Implementations ==<br /> <br /> [http://www.dbpoweramp.com/asset-upnp-dlna.htm Asset Server]<br /> <br /> [http://www.twonky.com/products/twonkyserver/default.aspx Twonky Server]</div>

Keith http://wiki.openhome.org/wiki/Oh:What 2011-10-10T11:02:14Z

<p>Keith: </p> <hr /> <div>{{nav_openhome|OpenHome - What is it?}}<br /> <br /> OpenHome is an independent body dedicated to the design, implementation, and promotion of free and open standards for home networked devices.<br /> <br /> As more networked devices are deployed in the home it is important for the services a device offers to the network to allow<br /> <br /> * control of the device with a networked control point,<br /> * cooperation with other devices from other vendors<br /> * use of the device in ways the manufacturer may not have envisaged when the device was designed</div>

Keith http://wiki.openhome.org/wiki/OhMedia:What 2011-10-10T11:01:35Z

<p>Keith: Replaced content with &quot;{{nav_openhome_av|OpenHome Media - What is it?}}&quot;</p> <hr /> <div>{{nav_openhome_av|OpenHome Media - What is it?}}</div>

Keith http://wiki.openhome.org/wiki/OhNet:Developer 2011-07-06T14:21:26Z

<p>Keith: </p> <hr /> <div>{{nav_openhome_ohnet|ohNet - Developers}}<br /> === Overview docs ===<br /> * Control Point stack (PDF) [http://www.openhome.org/releases/ohNet_ControlPointStack.pdf]<br /> * Device stack [coming soon]<br /> <br /> === API docs ===<br /> * C++ [http://www.openhome.org/build/nightly/docs/CppStd/]<br /> * C# [http://www.openhome.org/build/nightly/docs/Cs/]<br /> * JavaScript [http://www.openhome.org/build/nightly/docs/Js/]<br /> * C [http://www.openhome.org/build/nightly/docs/C/]<br /> <br /> ohNet is written using C++ with std::string replaced by special buffer classes. These buffer classes allow for more efficient use of memory at the cost of a steeper learning curve. Memory use benefits can be especially pronounced for the Device stack. API docs [http://www.openhome.org/build/nightly/docs/CppCore/] for this version of the stack are available but the buffer classes are intended for internal use of the library and are as such currently undocumented.</div>

Keith http://wiki.openhome.org/wiki/OhNet:What 2011-07-06T14:20:28Z

<p>Keith: </p> <hr /> <div>{{nav_openhome_ohnet|ohNet - What is it?}}<br /> ohNet is a full UPnP stack. Ports exist for Linux and Windows (Mac is in progress). The public APIs are protocol independent and offered in C++, C#, C and JavaScript (Control Point only).<br /> <br /> UPnP services are presented as classes with actions appearing as functions and state variables appearing as member variables. These classes are referred to as proxies for users of the Control Point stack and providers for users of the Device stack.<br /> <br /> Proxies and Providers are included for all OpenHome and UPnP AV services. If your application uses other services, ohNet includes a tool (ohNetGen) to generate proxies and/or providers from the service XML in any of the supported languages.</div>

Keith http://wiki.openhome.org/wiki/OhNet:What 2011-07-06T14:20:20Z

<p>Keith: </p> <hr /> <div>{{nav_openhome_ohnet|ohNet - What is it?}}<br /> ohNet is a full UPnP stack. Ports exist for Linux and Windows (Mac is in progress). The public APIs are protocol independent and offered in C++, C#, C and JavaScript (Control Point only).<br /> <br /> UPnP services are presented as classes with actions appearing as functions and state variables appearing as member variables. These classes are referred to as proxies for users of the Control Point stack and providers for users of the Device stack.<br /> <br /> Proxies and Providers are included for all OpenHome Media and UPnP AV services. If your application uses other services, ohNet includes a tool (ohNetGen) to generate proxies and/or providers from the service XML in any of the supported languages.</div>

Keith http://wiki.openhome.org/wiki/OhMedia:Developer 2011-07-06T14:17:24Z

<p>Keith: </p> <hr /> <div>{{nav_openhome_av|OpenHome Media - Developers}}<br /> <br /> = Introduction =<br /> <br /> OpenHome Media is an independent standard for networked audio visual devices. OpenHome Media 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 Media 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 Media 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 Media System ==<br /> <br /> The correct way to discover an OpenHome Media 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 /> == 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 current time within the currently playing track include the [[Av:Developer:TimeService|Time service]]<br /> <br /> == Multiroom Functionality ==<br /> <br /> An OpenHome Media Sender broadcasts music onto a network in a way that is playable by an OpenHome Media Receiver.<br /> <br /> An OpenHome Media Sender includes the [[Av:Developer:SenderService|Sender service]].<br /> <br /> An OpenHome Media Receiver includes a Receiver source (as part of of its topology) and an associated [[Av:Developer:ReceiverService|Receiver service]].<br /> <br /> = Services =<br /> <br /> * [[Av:Developer:ProductService|Product service]]<br /> * [[Av:Developer:PlaylistService|Playlist service]]<br /> * [[Av:Developer:RadioService|Radio service]]<br /> * [[Av:Developer:InfoService|Info service]]<br /> * [[Av:Developer:TimeService|Time service]]<br /> * [[Av:Developer:VolumeService|Volume service]]<br /> * [[Av:Developer:SenderService|Sender service]]<br /> * [[Av:Developer:ReceiverService|Receiver service]]<br /> <br /> = Songcast Specifications =<br /> <br /> * [[Av:Developer:Songcast:Ohm|Songcast OHM/OHU Protocol Specification]]<br /> * [[Av:Developer:Songcast:Ohz|Songcast OHZ Protocol Specification]]</div>

Keith http://wiki.openhome.org/wiki/OhMedia:How 2011-07-06T14:16:09Z

<p>Keith: </p> <hr /> <div>{{nav_openhome_av|OpenHome Media - How do I get it?}}<br /> <br /> == Control Point Implementations ==<br /> <br /> [http://web.me.com/sean.harding/ChorusDS/Overview.html Chorus]<br /> <br /> [http://oss.linn.co.uk Kinsky]<br /> <br /> [http://leia.sommerfeldt.f-m.fm/ Leia]<br /> <br /> [http://bookshelfapps.com/songbook-ds.php Songbook]<br /> <br /> == Player Implementations ==<br /> <br /> [http://www.linn.co.uk/digital_stream_players Linn]<br /> <br /> OpenHome Media Player (under development)<br /> <br /> == Media Server Implementations ==<br /> <br /> [http://www.dbpoweramp.com/asset-upnp-dlna.htm Asset Server]<br /> <br /> [http://www.twonky.com/products/twonkyserver/default.aspx Twonky Server]</div>

Keith http://wiki.openhome.org/wiki/Av 2011-07-06T14:15:55Z

<p>Keith: </p> <hr /> <div>The OpenHome Media standard provides an open and freely useable specification allowing the interoperable control and playback of audio and video files. Version 1.0 of the standard is available and multiple implementations of the standard [[How|exist]].</div>

Keith http://wiki.openhome.org/wiki/OhMedia:What 2011-07-06T14:15:44Z

<p>Keith: </p> <hr /> <div>{{nav_openhome_av|OpenHome Media - What is it?}}<br /> <br /> OpenHome is an independent body dedicated to the design, implementation, and promotion of free and open standards for home networked devices.<br /> <br /> As more networked devices are deployed in the home it is important for the services a device offers to the network to allow<br /> <br /> * control of the device with a networked control point,<br /> * cooperation with other devices from other vendors<br /> * use of the device in ways the manufacturer may not have envisaged when the device was designed<br /> <br /> OpenHome's first area of work is the [[Av|OpenHome Media standard]].</div>

Keith http://wiki.openhome.org/wiki/OhMedia:How 2011-07-06T14:14:14Z

<p>Keith: /* Player Implementations */</p> <hr /> <div>{{nav_openhome_av|OpenHome Av - How do I get it?}}<br /> <br /> == Control Point Implementations ==<br /> <br /> [http://web.me.com/sean.harding/ChorusDS/Overview.html Chorus]<br /> <br /> [http://oss.linn.co.uk Kinsky]<br /> <br /> [http://leia.sommerfeldt.f-m.fm/ Leia]<br /> <br /> [http://bookshelfapps.com/songbook-ds.php Songbook]<br /> <br /> == Player Implementations ==<br /> <br /> [http://www.linn.co.uk/digital_stream_players Linn]<br /> <br /> OpenHome Media Player (under development)<br /> <br /> == Media Server Implementations ==<br /> <br /> [http://www.dbpoweramp.com/asset-upnp-dlna.htm Asset Server]<br /> <br /> [http://www.twonky.com/products/twonkyserver/default.aspx Twonky Server]</div>

Keith http://wiki.openhome.org/wiki/OhNet:Developer 2011-06-27T14:34:07Z

<p>Keith: /* API docs */</p> <hr /> <div>{{nav_openhome_ohnet|ohNet - Developers}}<br /> === Overview docs ===<br /> * Control Point (PDF) [http://www.openhome.org/releases/ohNet_ControlPointStack.pdf]<br /> * Device [coming soon]<br /> <br /> === API docs ===<br /> * C++ [http://www.openhome.org/build/nightly/docs/CppStd/]<br /> * C# [http://www.openhome.org/build/nightly/docs/Cs/]<br /> * JavaScript [http://www.openhome.org/build/nightly/docs/Js/]<br /> * C [http://www.openhome.org/build/nightly/docs/C/]<br /> <br /> ohNet is written using C++ with std::string replaced by special buffer classes. These buffer classes allow for more efficient use of memory at the cost of a steeper learning curve. Memory use benefits can be especially pronounced for the Device stack. API docs [http://www.openhome.org/build/nightly/docs/CppCore/] for this version of the stack are available but the buffer classes are currently undocumented.</div>

Keith http://wiki.openhome.org/wiki/OhMedia:Developer 2011-06-02T13:31:57Z

<p>Keith: /* Songcast */</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 /> * [[Av:Developer:ProductService|Product service]]<br /> * [[Av:Developer:PlaylistService|Playlist service]]<br /> * [[Av:Developer:RadioService|Radio service]]<br /> * [[Av:Developer:InfoService|Info service]]<br /> * [[Av:Developer:TimeService|Time service]]<br /> * [[Av:Developer:VolumeService|Volume service]]<br /> * [[Av:Developer:SenderService|Sender service]]<br /> * [[Av:Developer:ReceiverService|Receiver service]]<br /> <br /> = Songcast Specifications =<br /> <br /> * [[Av:Developer:Songcast:Ohm|Songcast OHM/OHU Protocol Specification]]<br /> * [[Av:Developer:Songcast:Ohz|Songcast OHZ Protocol Specification]]</div>

Keith http://wiki.openhome.org/wiki/OhMedia:Developer 2011-06-02T13:31:39Z

<p>Keith: /* Network Protocols */</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 /> * [[Av:Developer:ProductService|Product service]]<br /> * [[Av:Developer:PlaylistService|Playlist service]]<br /> * [[Av:Developer:RadioService|Radio service]]<br /> * [[Av:Developer:InfoService|Info service]]<br /> * [[Av:Developer:TimeService|Time service]]<br /> * [[Av:Developer:VolumeService|Volume service]]<br /> * [[Av:Developer:SenderService|Sender service]]<br /> * [[Av:Developer:ReceiverService|Receiver service]]<br /> <br /> = Songcast =<br /> <br /> * [[Av:Developer:Songcast:Ohm|Songcast OHM/OHU Protocol Specification]]<br /> * [[Av:Developer:Songcast:Ohz|Songcast OHZ Protocol Specification]]</div>

Keith http://wiki.openhome.org/wiki/OhMedia:What 2011-05-05T15:37:55Z

<p>Keith: </p> <hr /> <div>OpenHome is an independent body dedicated to the design, implementation, and promotion of free and open standards for the interoperability of networked devices in the home.<br /> <br /> More and more devices are exposing their functionality to the network. If done correctly, the services a device provides to the network allows you to:<br /> <br /> * control the device with a 3rd party control point,<br /> * use the device in conjunction with another vendor's devices, <br /> * use the device in ways the manufacturer may never have even dreamt of. <br /> <br /> OpenHome's first area of work is the [[Av|OpenHome Audio Visual (AV) standard]].</div>

Keith http://wiki.openhome.org/wiki/OhMedia:How 2011-05-05T15:35:47Z

<p>Keith: /* Player Implementations */</p> <hr /> <div>== Control Point Implementations ==<br /> <br /> [http://web.me.com/sean.harding/ChorusDS/Overview.html Chorus]<br /> <br /> [http://oss.linn.co.uk Kinsky]<br /> <br /> [http://leia.sommerfeldt.f-m.fm/ Leia]<br /> <br /> [http://bookshelfapps.com/songbook-ds.php Songbook]<br /> <br /> == Player Implementations ==<br /> <br /> [http://www.linn.co.uk/digital_stream_players Linn]<br /> <br /> OpenHome Av SoftPlayer (under development)<br /> <br /> == Media Server Implementations ==<br /> <br /> [http://www.dbpoweramp.com/asset-upnp-dlna.htm Asset Server]<br /> <br /> [http://www.twonky.com/products/twonkyserver/default.aspx Twonky Server]</div>

Keith http://wiki.openhome.org/wiki/OhMedia:How 2011-05-05T15:35:37Z

<p>Keith: /* Player Implementations */</p> <hr /> <div>== Control Point Implementations ==<br /> <br /> [http://web.me.com/sean.harding/ChorusDS/Overview.html Chorus]<br /> <br /> [http://oss.linn.co.uk Kinsky]<br /> <br /> [http://leia.sommerfeldt.f-m.fm/ Leia]<br /> <br /> [http://bookshelfapps.com/songbook-ds.php Songbook]<br /> <br /> == Player Implementations ==<br /> <br /> [http://www.linn.co.uk/digital_stream_players Linn]<br /> <br /> OpenHome Av SoftPlayer (coming soon)<br /> <br /> == Media Server Implementations ==<br /> <br /> [http://www.dbpoweramp.com/asset-upnp-dlna.htm Asset Server]<br /> <br /> [http://www.twonky.com/products/twonkyserver/default.aspx Twonky Server]</div>

Keith http://wiki.openhome.org/wiki/OhMedia:How 2011-05-05T15:35:26Z

<p>Keith: /* Control Point Implementations */</p> <hr /> <div>== Control Point Implementations ==<br /> <br /> [http://web.me.com/sean.harding/ChorusDS/Overview.html Chorus]<br /> <br /> [http://oss.linn.co.uk Kinsky]<br /> <br /> [http://leia.sommerfeldt.f-m.fm/ Leia]<br /> <br /> [http://bookshelfapps.com/songbook-ds.php Songbook]<br /> <br /> == Player Implementations ==<br /> <br /> [http://www.linn.co.uk/digital_stream_players Linn]<br /> <br /> OpenHome Av SoftPlayer<br /> <br /> == Media Server Implementations ==<br /> <br /> [http://www.dbpoweramp.com/asset-upnp-dlna.htm Asset Server]<br /> <br /> [http://www.twonky.com/products/twonkyserver/default.aspx Twonky Server]</div>

Keith http://wiki.openhome.org/wiki/OhMedia:How 2011-05-05T14:34:09Z

<p>Keith: Created page with &quot;== Control Point Implementations == [http://web.me.com/sean.harding/ChorusDS/Overview.html Chorus] [http://oss.linn.co.uk Kinsky] [http://leia.sommerfeldt.f-m.fm/ Leia] [http...&quot;</p> <hr /> <div>== Control Point Implementations ==<br /> <br /> [http://web.me.com/sean.harding/ChorusDS/Overview.html Chorus]<br /> <br /> [http://oss.linn.co.uk Kinsky]<br /> <br /> [http://leia.sommerfeldt.f-m.fm/ Leia]<br /> <br /> [http://bookshelfapps.com/songbook-ds.php Songbook]</div>

Keith http://wiki.openhome.org/wiki/Av 2011-05-05T14:29:15Z

<p>Keith: Created page with &quot;The OpenHome Av standard provides an open and freely useable specification allowing the interoperable control and playback of audio and video files. Version 1.0 of the standard ...&quot;</p> <hr /> <div>The OpenHome Av standard provides an open and freely useable specification allowing the interoperable control and playback of audio and video files. Version 1.0 of the standard is available and multiple implementations of the standard [[How|exist]].</div>

Keith http://wiki.openhome.org/wiki/OhMedia:What 2011-05-05T14:05:28Z

<p>Keith: </p> <hr /> <div>OpenHome is an independent body dedicated to the design, implementation, and promotion of free and open standards for the interoperability of networked devices in the home.<br /> <br /> It is becoming more common for devices to expose their functionality to the network. If done correctly, the services a device provides to the network allows them:<br /> <br /> * to be controlled by 3rd party control points, <br /> * to be used in conjunction with other vendor's devices, <br /> * and to be used in ways that the original manufacturer may never have dreamt of. <br /> <br /> OpenHome's first area of work is the [[Av|OpenHome Audio Visual (AV) standard]].</div>

Keith http://wiki.openhome.org/wiki/Help:Editing 2011-05-05T14:03:48Z

<p>Keith: Created page with &quot;http://www.mediawiki.org/wiki/Help:Editing_pages&quot;</p> <hr /> <div>http://www.mediawiki.org/wiki/Help:Editing_pages</div>

Keith http://wiki.openhome.org/wiki/MediaWiki:Mainpage 2011-05-05T14:00:46Z

<p>Keith: </p> <hr /> <div>What</div>

Keith http://wiki.openhome.org/wiki/OhMedia:What 2011-05-05T13:34:38Z

<p>Keith: </p> <hr /> <div>OpenHome is an independent body dedicated to the design, implementation, and promotion of free and open standards for the interoperability of networked devices in the home.<br /> <br /> It is becoming more common for devices to expose their functionality to the network. If done correctly, the services a device provides to the network allows them:<br /> <br /> * to be controlled by 3rd party control points, <br /> * to be used in conjunction with other vendor's devices, <br /> * and to be used in ways that the original manufacturer may never have dreamt of. <br /> <br /> OpenHome's first area of work is the OpenHome Audio Visual (AV) standard.</div>

Keith http://wiki.openhome.org/wiki/OhMedia:What 2011-05-05T12:47:54Z

<p>Keith: Created page with &quot;OpenHome is an independent body dedicated to the design, implementation, and promotion of free and open standards for the interoperability of networked devices in the home. It h...&quot;</p> <hr /> <div>OpenHome is an independent body dedicated to the design, implementation, and promotion of free and open standards for the interoperability of networked devices in the home.<br /> <br /> It has become common for devices to expose their functionality to the network. If done correctly, it allows those devices to be controlled by other vendor's control points, to be integrated with other vendor's devices, and to be used in ways that the original manufacturer may never have dreamt of. <br /> <br /> OpenHome's first area of work is the OpenHome Audio Visual (AV) standard.</div>

Keith http://wiki.openhome.org/wiki/Av:Developer:SenderService 2011-04-28T14:13:05Z

<p>Keith: /* Connecting */</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 /> &lt;code&gt;<br /> Domain : av.openhome.org<br /> Name : Sender<br /> Version : 1<br /> &lt;/code&gt;<br /> [http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Sender1.xml Sender Service Description (XML)]</div>

Keith http://wiki.openhome.org/wiki/Av:Developer:SenderService 2011-04-28T14:12:00Z

<p>Keith: /* Architectural Overview */</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 /> &lt;code&gt;<br /> Domain : av.openhome.org<br /> Name : Sender<br /> Version : 1<br /> &lt;/code&gt;<br /> [http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Sender1.xml Sender Service Description (XML)]<br /> <br /> == Connecting ==<br /> <br /> In the OpenHome multicast protocol, receivers must be connected to senders in order to receive streaming audio. <br /> <br /> In order to connect and disconnect senders from receivers, there are two conceptual approaches you could take. You can either order a particular receiver to play a particular sender, or you can order a sender to start sending to one or more receivers. From a user perspective, these are very different approaches, however from an implementation standpoint, both of these are equivalent and are carried out by invoking the SetSender action on the receiver service, passing the Uri and Metadata of the sender (which can be obtained from the sender service metadata state variable). This will bring the receiver to a state where it is ready to listen to the sender, and can be started/stopped by invoking the Play and Stop actions. The Play action will automatically switch source on the receiving DS if this source is not currently selected.<br /> <br /> Both of these approaches, of course, first require maintaining an up-to-date list of senders and receivers from [[Developer#Topology|Topology]]:<br /> <br /> The receivers list is maintained by using [[Developer#Topology|Topology]] to watch sources being added/removed and checking whether the source has Type equal to &quot;Receiver&quot;.<br /> <br /> The senders list is maintained via SSDP discovery of any sender services which do not have a status of disabled.</div>

Keith http://wiki.openhome.org/wiki/Av:Developer:SenderService 2011-04-28T14:11:40Z

<p>Keith: /* Architectural Overview */</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 [[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 /> &lt;code&gt;<br /> Domain : av.openhome.org<br /> Name : Sender<br /> Version : 1<br /> &lt;/code&gt;<br /> [http://oss.linn.co.uk/trac/browser/Main/LibUpnpCil/Services/Openhome/Sender1.xml Sender Service Description (XML)]<br /> <br /> == Connecting ==<br /> <br /> In the OpenHome multicast protocol, receivers must be connected to senders in order to receive streaming audio. <br /> <br /> In order to connect and disconnect senders from receivers, there are two conceptual approaches you could take. You can either order a particular receiver to play a particular sender, or you can order a sender to start sending to one or more receivers. From a user perspective, these are very different approaches, however from an implementation standpoint, both of these are equivalent and are carried out by invoking the SetSender action on the receiver service, passing the Uri and Metadata of the sender (which can be obtained from the sender service metadata state variable). This will bring the receiver to a state where it is ready to listen to the sender, and can be started/stopped by invoking the Play and Stop actions. The Play action will automatically switch source on the receiving DS if this source is not currently selected.<br /> <br /> Both of these approaches, of course, first require maintaining an up-to-date list of senders and receivers from [[Developer#Topology|Topology]]:<br /> <br /> The receivers list is maintained by using [[Developer#Topology|Topology]] to watch sources being added/removed and checking whether the source has Type equal to &quot;Receiver&quot;.<br /> <br /> The senders list is maintained via SSDP discovery of any sender services which do not have a status of disabled.</div>

Keith http://wiki.openhome.org/wiki/OhMedia:Developer 2011-04-28T14:11:10Z

<p>Keith: /* Discovering An OpenHome System */</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 /> <br /> Some mention of the [[Av:Developer:InfoService|Info service]]<br /> <br /> Some mention of the [[Av:Developer:TimeService|Time service]]<br /> <br /> == Multiroom Functionality ==<br /> <br /> Some mention of the [[Av:Developer:SenderService|Sender service]]<br /> <br /> Some mention of 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>

Keith