Developer:Davaar:SenderService
Contents
Architectural Overview
The Sender service indicates the presence of an Openhome sender and provides information concerning that sender.
An Openhome sender broadcasts music on a network in a way that is playable by an Openhome receiver.
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.
Actions
Attributes
Reports a space separated list of attributes that identify additional functionality that can be found on the same device as this Sender.
Currently defined attributes are:
- Info - this device reports on the current media using the Info service
- Time - this device reports on the current media using the Time service
Audio
Reports whether audio is currently present on this sender.
Metadata
Provides a representation of this audio item in DIDL-Lite format.
PresentationUrl
Reports the Url of a presentation page for further information concerning the sender, or for controlling the sender in some application-specific way.
If the sender has no presentation page, the PresentationUrl should be empty.
Status
Reports the status of the sender (normally only for debugging purposes):
- Sending - currently sending audio over the network
- Ready - ready to send audio but no listeners
- Blocked - audio from another sender detected on the same channel (mis-configuration)
- Inactive - no audio source currently assigned to this sender
- Disabled - sender disabled by user configuration
Technical Details
Domain : av.openhome.org
Name : Sender
Version : 1
Sender Service Description (XML)
Programming
In the openhome multicast protocol, receivers must be connected to senders in order to receive streaming audio.
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.
Both of these approaches, of course, first require maintaining an up-to-date list of senders and receivers from Topology:
The receivers list is maintained by using Topology to watch sources being added/removed and checking whether the source has Type equal to "Receiver".
The senders list is maintained via SSDP discovery of any sender services which do not have a status of disabled. An implementation of this can be found in the class Linn.Topology.Senders.
