You think that UPnP is not perfect. Probably right, nothing is. But why do you suppose that 400 manufacturers (including all majors except Apple) are supporting it? And why do you suppose Apple is not supporting it. (Be honest). And what makes you think those people will drop everything that they have invested in that, and jump on your horse instead?
Hi again...
I've installed NTP services on all my MC20 machines which was extremely simple.
It would appear though that MC20 linked zones doesn't take advantage of some of the clock sync features in the spec. I could be wrong...
Whether NTP is on or off though it makes no difference to sync of linked zones.
I looked on the UpNP database and I cant see these features in the supported features list for JRiver server or renderer. (though it's probably out of date - last update for JRiver was 2011)
http://www.upnp-database.info/device.jsp?deviceId=344From what I've seen no one is using this spec but other synchronised playback systems are using RTSP/RTP/NTP.
AirPlay uses all three plus Multicast DNS and HTTP.
We can probably get sync working over zones if the CLOCKSYNC feature is enabled in MC20 for linked zone playback? Is it possible without too much work?
I have the relevant section from the spec below and a list of the required features.
Requires:
NTP Service installed and running on all clients and servers.
upnp:resExt::clockSync@deviceClockInfoID
upnp:resExt::clockSync@supportedTimestampsID
ContentDirectory::GetFeatureList() action for MediaServers
ConnectionManager::GetFeatureList() action for MediaServers
ConnectionManager::GetFeatureList() action for MediaRenderers.
5.1. Synchronized playback
It is possible to instruct one or more MediaRenderers to start playing back of a Content Item at a specific time.
The same can be done for operations such as pausing and stopping.
These operations are possible using the AVTransport::SyncPlay(), AVTransport::SyncPause() and AVTransport::SyncStop() actions.
The pre-condition is that the different MediaServers and MediaRenderers in the home are synchronized to the same master clock and support the appropriate clock synchronization protocol (such as NTP, IEEE 802.1AS).
Information about the clock synchronization of the different devices can be obtained by the control point using the ContentDirectory::GetFeatureList() action and the ConnectionManager::GetFeatureList() action for MediaServers and the ConnectionManager::GetFeatureList() action for MediaRenderers.
In order to determine if the MediaServer is capable of streaming synchronized content, the control point uses the content’s upnp:resExt::clockSync@deviceClockInfoID and upnp:resExt::clockSync@supportedTimestampsID properties to locate the specific details about the synchronization protocol that will be used.
The control point does this via the MediaServer’s ConnectionManager service <Feature> element containing the CLOCKSYNC feature within the MediaServer’s feature list.
Specifically, the control point finds the <DeviceClockInfo> and <supportedTimestamps> elements whose @id values match the content’s upnp:resExt::clockSync@deviceClockInfoID and upnp:resExt::clockSync@supportedTimestampsID property values, respectively. Consequently, the control point identifies the clock sync protocol (e.g. 802.1AS), timestamp mechanism (e.g. ‘RTP-1733’) and the ID of the master clock to whom the MediaServer’s internal clock is synchronized.
Then, by examining the MediaRenderer’s <DeviceClockInfo> element within the <Feature> element containing the CLOCKSYNC feature from the MediaRenderer’s ConnectionManager service feature list, the control point determines that the MediaRenderer supports CLOCKSYNC feature, and identifies the clock sync protocol (802.1AS), timestamp mechanism (e.g.‘RTP-1733’) and the ID of the master clock to whom the MediaRenderer’s internal clock is synchronized.
Based on the comparison of information from the MediaRenderer and the MediaServer, the control point derives the conclusion whether the selected content can be played on the specified MediaRenderer in a precision time-synchronized manner.
As described above, the control point can invoke the ConnectionManager::GetFeatureList() action in order to determine the specific details of the synchronized playback supported by the device hosting the ConnectionManager service.
The <syncProtocolID> element of the <Feature> element containing the CLOCKSYNC feature enumerates the clock synchronization protocol that was used to synchronize the implementation’s local time-of-day clock.
The possible clock synchronization protocols include 802.1AS, NTP (Network Timing Protocol) and SNTP (Simple Network Timing Protocol) protocols. 802.1AS clock synchronization protocol enables precision synchronization (accuracy exceeding 1 micro-second), thus enabling usages such as synchronized audio and video playback. For other usages such as party music being piped to multiple rooms, NTP and SNTP protocols may provide sufficient clock synchronization accuracy.
Similarly, the <masterClockID> element of the <Feature> element containing the CLOCKSYNC feature identifies the master clock to which this implementation has synchronized its local time-of-day clock. Depending on the clock synchronization protocol, the <masterClockID> element specifies either the 8-byte binary sequence (<High 24-bits MAC> 0xFF 0xFE <Low 24-bits MAC>) in case of 802.1AS, or the URL of the time server in case of NTP or SNTP.
Author
Topic: IEEE 802.1AS - Precise synchronization- is the answer to sync in ethernet stack? (Read 14886 times)