Strings Synchronization Model
`
`Synopsis
`
`This document describes a collection of beads and conventions developed to support
`multi-host synchronization in Strings.
`
`Overview
`
`The synchronization model consists of the following components:
`
`i)
`
`ii)
`
`iii)
`
`An inter-host clock monitoring protocol, implemented in timesync, which
`determines the relative system-clock offset for each synchronized host.
`A sample-clock implementation (sampleclock), which distributes stream-
`position information across all cooperating hosts. Each playout node has a
`‘master’ clock, which records the idealized playout position, and a ‘render’
`which records the actual playout position. The clocksync bead provides a
`mechanism for propogating the path clocks across network boundaries, using
`data collected by timesync to convert remote system clock values into local
`system clock values.
`A media-specific mechanism for adjusting the playout rate of a given media
`type. For rgb video, the rgbvideo times frame deliver based on the master
`clock, and sets the render clock. For pcm audio, the speaker bead sets the
`render clock, and the audiosync bead adjusts the playout rate of the sample
`stream to try to minimize the error between the master and render clocks.
`
`One playout node must be identified as the time master. For simple audio/video playout,
`generally the master will be the audio stream, since audio playout rates are effectively
`regulated by the consumption rate of the audio output device.
`
`The master clock for all synchronized streams is a reference to the single render clock for
`the master time source. Thus the time master’s clocks will always match exactly. All
`other streams vary playout rate to try to minimize the error between the render and master
`clocks.
`
`Rate Adjustment
`
`Consumer
`
`Master Clock
`
`Render Clock
`
`Page 1 of 3
`
`Implicit Exhibit 2037
`Sonos v. Implicit, IPR2018-0766, -0767
`
`
`
`Synopsis
`
`This document describes a collection of beads and conventions developed to support
`multi-host synchronization in Strings.
`
`Overview
`
`The synchronization model consists of the following components:
`
`i)
`
`ii)
`
`iii)
`
`An inter-host clock monitoring protocol, implemented in timesync, which
`determines the relative system-clock offset for each synchronized host.
`A sample-clock implementation (sampleclock), which distributes stream-
`position information across all cooperating hosts. Each playout node has a
`‘master’ clock, which records the idealized playout position, and a ‘render’
`which records the actual playout position. The clocksync bead provides a
`mechanism for propogating the path clocks across network boundaries, using
`data collected by timesync to convert remote system clock values into local
`system clock values.
`A media-specific mechanism for adjusting the playout rate of a given media
`type. For rgb video, the rgbvideo times frame deliver based on the master
`clock, and sets the render clock. For pcm audio, the speaker bead sets the
`render clock, and the audiosync bead adjusts the playout rate of the sample
`stream to try to minimize the error between the master and render clocks.
`
`One playout node must be identified as the time master. For simple audio/video playout,
`generally the master will be the audio stream, since audio playout rates are effectively
`regulated by the consumption rate of the audio output device.
`
`The master clock for all synchronized streams is a reference to the single render clock for
`the master time source. Thus the time master’s clocks will always match exactly. All
`other streams vary playout rate to try to minimize the error between the render and master
`clocks.
`
`Rate Adjustment
`
`Consumer
`
`Master Clock
`
`Render Clock
`
`Page 1 of 3
`
`Implicit Exhibit 2037
`Sonos v. Implicit, IPR2018-0766, -0767
`
`
`
`TimeSync
`The TimeSync bead is used to create a database of clock offsets for all strings machines
`on the network. The protocol used to estimate clock offsets is based on the NTP
`protocol.
`
`Periodically each host broadcasts the current time, plus a list of all known remote hosts.
`The broadcast includes:
`1. A psuedo-random host identifier,
`2. The local system time at the time of sending.
`
`
`For remote host known by the sender, the broadcast also includes:
`1. The unique identifier of the remote host,
`2. The send time from the most recently received broadcast from that host.
`3. The local system time when the most recent broadcast was received.
`
`
`
`Computation of inter-host clock offset occurs whenever a broadcast is received from a
`remote host containing a host entry for the local host. Timing is derived from the round-
`trip consisting of a prior broadcast from the local machine (B0) followed by the remote
`machines broadcast (B1) which includes values from B0.
`T0 is local time when B0 was sent,
`T1 is the remote time when B0 was received,
`T2 is the remote time when B1 was sent,
`T3 is the local time when B1 was received.
`
`
`We want to compute an estimation for Toffset, such that Tremote + Toffset = Tlocal.
`Network latency is unknown and variable.
`
`L0 is the latency for B0,
`
`L1 is the latency for B1.
`such that
`
`T1+Toffset = T0 + L0
`
`T2+Toffset = T3 – L1
`
`From this we can determine bounds for Toffset:
`
`(T1+Toffset) >= T0
`
`T2 >= T1
`
`T3 >= (T2+Toffset)
`
`And so:
`Toffset > T0 – T1
`Toffset < T3 – T2
`Since we have no way to devolve the effects of L0 and L1, we assume they are
`approximately equal, and so
`
`Toffset ~= ( (T3-T2) – (T0-T1) ) / 2
`
`Since latency does vary substantially over time, we reduce the error by averaging
`subsequent observations. Currently timesync uses the average of the last 8 observations.
`
`Page 2 of 3
`
`Implicit Exhibit 2037
`Sonos v. Implicit, IPR2018-0766, -0767
`
`
`
`
`Related Issues
`Use of Durable Values
`To minimize the effects of latency on synchronization accuracy, all shared information is
`exchanged in terms of stationary or durable values – i.e. values that do not change rapidly
`over time, and do not assume instantaneous delivery. For example, sample clocks are
`computed from the following information:
`
`
`
`
`1. The local system clock value at which the stream position was recorded,
`2. The sample position at that time,
`3. The nominal frequency at which the sample count is expected to be progressing.
`
`
`From these three values the current playout position of a remote stream can be estimated
`based on the most recently received sample clock information. Assuming the actual
`playout rate is close to the nominal playout rate, the accuracy of the estimate does not
`degrade greatly with increased delivery latency. Use of this principal greatly increases
`the robustness of the synchronization model.
`
`Clock Uncertainty
`The following types of timing uncertainties complicate synchronization:
`1. System clock values between machines may have a large relative offset, and a
`small drift relative to each other.
`2. Output devices do not necessarily consume media at exactly the correct rate. The
`output rate for audio is typically regulated by a DSP clock, not the system clock,
`and there may be substantial differences between them.
`
`Page 3 of 3
`
`Implicit Exhibit 2037
`Sonos v. Implicit, IPR2018-0766, -0767
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
