ohMedia defines the following network services:
- Product. The core of a renderer and the only mandatory service. The state of this service allows control points to infer which other services are present on a device. In more complex installations it allows devices to mapped into a multi-room hi-fi system
- Playlist. An ordered list of tracks to be played.
- Radio. Browse and select from a list of favourite internet radio, podcast and listen again presets.
- Info. Report information about currently playing track.
- Time. Report information about progress through a track.
- Volume. Control volume on a renderer or a connected pre-amp.
- Transport. Source-independent transport controls.
- Sender. Indicate presence and state of a Songcast sender.
- Receiver. Control a Songcast receiver.
- Credentials. Securely manage login details for external services supported by a device.
- NetworkMonitor. Measures network performance.
- PlaylistManager. Included in media servers. Allows playlists to be shared between renderers and saved for future reuse.
The Eriskay family of services will later replace these. Feedback on Eriskay is welcomed.
All ohMedia products publish and/or consume network services using UPnP. This is enabled by ohNet - a cross-platform UPnP stack suitable for use in control points and devices. ohNet is open source, liberally licensed and intended for use in external products.
The Songcast brand encompasses a range of products and protocols.
Virtual audio drivers that send all audio from a Windows or Mac device to a songcast receiver. Linn provide a full implementation of these. The bulk of the code required is also available in the ohSongcast repo.
The Songcast protocol enables synchronised playing of audio from an unbounded number of ohMedia renderers.
The ohSongcast repo provides a cross-platform C++ library offering much of the code needed to write a stand-alone songcast sender. The ohPipeline repo contains a reference sender and receiver fully integrated to the OpenHome reference audio pipeline.
The Songcast protocols are also documented:
A specialised protocol used when there is a single receiver and the sender has control over the rate of streaming (this often means that the sender is responsible for audio decode). More information, including protocol spec and sample code is available here.
ohMedia models a home as a number of hi-fi systems, which are located in rooms.
A hi-fi system is modelled 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 at least one output and any number of inputs.
A product is modelled through the Product service specification.
When a control point wants to construct a model of a user's home they use the Topology algorithm:
- discover all the products in the home that have a Product service
- group the discovered products based on the room they are in
- create a hierarchical tree structure by matching source names to product names *
- discover source functionality based on source type
- discover additional functionality based on product attributes
Example implementations of the Topology algorithm are available in C# and C++ from the ohTopology github repo.
A more detailed description of the ohTopology software can be found here.
Both Linn's DS and ohMediaPlayer include reference implementations for the following streaming services: