TECHNICAL FIELD
[0001] The present disclosure generally relates to digital media playback
systems, and more particularly to regulating the playback of media streams in such
systems.
BACKGROUND
[0002] Digital media streaming, such as the streaming of audio, video,
and/or text media content is becoming increasingly popular. The term "streaming"
is typically used to indicate that the data representing the media is provided by a
host computer device over a network to a client device (i.e., a media playback
device implemented as any of a variety of conventional computing devices, such as
a desktop PC, a notebook or portable computer, a cellular telephone or other
wireless communications device, a personal digital assistant (PDA), a gaming
console, an IP set-top box, a handheld PC, and so on). The client device renders
the streaming content as the content is received from the host, rather than waiting
for all the content or the entire "file" to be delivered.
[0003] When media content is "streamed" over a network, it is typically
streamed in data packets. However, there is not always a guarantee that the data
packets will arrive at their destination in the same order in which they are sent, or
even that they will arrive at their destination at all. Additionally, there is usually no
guarantee that the time it takes a data packet to travel from the source to the
destination will be of specific duration, or that the time will be the same for
different data packets.
[0004] In order to account for these variances in data delivery to a client
device, the client device typically maintains a buffer of data. The buffer allows the .
client device to smooth out the variances in data delivery so that they are not as
noticeable to the user during playback of the content. Thus, for example, if there is
a brief glitch in network bandwidth caused by network congestion (e.g., network
cross-traffic, interference, poor wireless reception), in most cases the amount of
data in the buffer permits the client device to continue playing media content so
the user does not experience the effects of the glitch (e.g., an interruption or pause
in playback). However, in some cases variances in data delivery caused by a
network glitch, for example, can deplete the buffer and result in an interruption or
pause in playback.
[0005] Another problem that can cause the continual depletion of the client
buffer and periodic interruption in playback in media content is the presence of
different clock frequencies on the host device (i.e., the source device that encodes
and transmits the streaming content) and the client device (i.e., the device that
receives and plays back the streaming content). That is, the client clock regulating
playback, on the client device may run at a slightly different frequency than the host
clock regulating the encoding process on the host/source device. Clock drift
between the host clock and the client clock can cause the client buffer to run out of
media content for playback. If the client clock runs faster than the host clock, the
client will consume media content from the client buffer at a slightly faster rate
than the host can replenish it. In this case, the client buffer will continually run out
of media content and k periodic pause or interruption in media playback occurs in
order for the buffer to recover. Conversely, clock drift can also cause the client
buffer to overflow with media content. If the client clock runs slower than the host
clock, the client will consume media content from the client buffer at a slightly
slower rate than the host is filling the buffer. In this case, the client buffer will
overflow with media content.
[0006] Accordingly, a need exists for a way to detect clock drift between a
host device delivering streaming content to a client playback device, and the client
device.
SUMMARY
[0007] A digital media system and methods use client buffer fullness reports
to detect clock drift between the clock on a host/source device that delivers
streaming media content and the clock on ar-client playback device that receives'the"
streaming media content.
[0008J In one embodiment, a buffer monitor on the client device monitors a
client buffer and generates buffer fullness reports that indicate the level of data in
the client buffer. The buffer monitor sends the buffer fullness reports to a clock
drift detection and recovery component on the host device. The clock drift
detection and recovery component determines from the buffer fullness reports the
extent of any clock drift between the client device clock and the. host device clock,
If there is clock: drift between the client clock and host clock, the clock drift
detection and recovery component implements a recovery method to synchronize
the clocks.
[0009] In another embodiment, the buffer monitor on the client device sends
the buffer fullness reports to a clock drift detection and recovery component on the
client device. The clock drift detection and recovery component on the client
device determines the extent of any clock drift between the client clock and the .
host clock and implements a recovery method on the client device to synchronize
the clocks. In still another embodiment, the clock drift detection and recovery
component on the client device sends a message to the host device regarding
detected clock drift, arid a clock recovery component on the host device
implements a recovery method to synchronize the clocks. The clock drift detection
and recovery component may also reside on a third device (e.g., a dedicated
control device) and receive buffer fullness reports from the client. Again, the
clock drift detection and recovery component determines the extent of any clock
drift between the client clock and the host clock and can implement a recovery
method to synchronize the clocks.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] The same reference numerals are used throughout the drawings to
reference like components and features.
Fig. 1 illustrates an exemplary environment suitable for detecting clock drift
between the clock on a host/source device that delivers streaming media content
and the clock on a client playback device that receives the streaming media
content.
Fig. 2 illustrates an exemplary embodiment of a digital media system
suitable for detecting clock drift between the clock on a host/source device that
delivers streaming media content and the clock on a client playback device that
receives the streaming media content.
Fig. 3 illustrates scenarios showing what client media buffer fullness levels
might look like over time as a host device streams media content to & client .device. :
Fig. 4 illustrates an additional scenario showing what client media buffer
fullness levels might look like where the buffer fullness level fluctuates over time
due to network bandwidth fluctuations.
Fig. 5 illustrates additional exemplary embodiments of a digital media
system suitable for detecting clock drift between the clock on a host device that
delivers streaming media content and the clock on a client playback device that
receives the streaming media content.
Figs. 6-7 are flow diagrams illustrating exemplary methods for detecting
clock drift in a digital media system between the clock on a host/source device that
delivers streaming media content and the clock on a client playback device that
receives the-streaming media content.
Fig. 8 illustrates an exemplary computing environment suitable for
implementing a host computer device and client playback device such as those
discussed with reference to Figs. 1-7.
DETAILED DESCRIPTION
Introduction
[0011] The following discussion is directed to a digital media system and
methods that detect clock drift between the clock on a host/source device that
delivers streaming media content and the clock on a client playback device that
receives the streaming media content. The host clock regulates the encoding of the
streaming media on the host device and the client clock regulates the playback of
the streaming media on the client device. Advantages of the described system and
methods-include a reduction in . playback .interruptions, during .playback: of
streaming media content and a greater potential that "live" content encoded by a
host/source device can actually be experienced as "live" content through playback
on a client device.
Exemplary Environment
[0012] Fig. 1 illustrates an exemplary environment 100 suitable for
detecting clock drift between the clock on a host/source device that delivers
streaming media content and the clock on a client playback device that receives the
streaming media content. Network 106 is intended to represent any of a variety of
conventional network topologies and types (including optical, wired and/or
wireless networks), employing any of a variety of conventional network protocols
(including public and/or proprietary protocols). Network 106 may include, for
example, a home network, a corporate network, or the Internet, as well as possibly
at least portions of one or more local area networks (LANs) and/or wide area
networks (WANs).
[0013] A host/source device 102 generally provides access to stored media
content, such as media files, and/or live media content, such as a live cable TV
feed or Webcast. Host device 102 streams the media content to a client playback
device 104 upon request. A client device 104 generally receives streaming media
content from host device 102 and plays it back for a user. Requests from client
device 104 for streaming media content that is available on host device 102 are
routed from the client device 104 to the host device 102 via network 106. The host
device 102 receives the request and returns the requested content to the requesting
client device 104 via network 106.
[0014] Host device 102 may be implemented as any of a variety of
conventional computing devices, including, for example, a desktop PC, a notebook
or portable computer, a workstation, a mainframe computer, an Internet appliance,
combinations thereof, and so on, that are configurable to stream stored and/or live
media content to a client device 104. Client playback device 104 may also be
implemented as any of a variety of conventional computing devices, including, for
example, a desktop PC, a notebook or portable computer, a workstation, a
mainframe computer, an Internet appliance, a gaming console, a handheld PC, a
cellular telephone or other wireless communications device, a personal digital
assistant (PDA), a set-top box, combinations thereof, and so on. An exemplary
computing environment-for implementing- a^host device; 102 and a' client device
104 is described in more detail herein below with reference to Fig. 8.
(0015} Host device 102 can make any of a variety of data available for
streaming to client playback device 104, including content such as audio, video,
text, images, animation, and the like. However, as used herein with respect to the
exemplary embodiments described below, media content 200 is intended to
represent audio/video (A/V) content or just video content. Furthermore, references
made herein to "media content", "streaming media", "streaming video", "video
content", and any variation thereof are generally intended to include audio/video
content. The term "streaming" is used to indicate that the data representing the
media content is provided over a network 106 to a client playback device 104 and
that playback of the content can begin prior to the content being delivered in its
entirety. The data may be publicly available or alternatively restricted (e.g.,
restricted to only certain users, available only if the appropriate fee is paid,
xestricted.-to users having access to a.particular network,-etc,). .Additionally, the
data may be "on-demand" (e.g., pre-recorded, stored content of a known size) or
alternatively from a live "broadcast" (e.g., .having no known size, such as a digital
representation of a concert being captured as the concert is performed and made
available for streaming shortly after capture).
Exemplary Embodiments
[0016] Fig. 2 illustrates an exemplary embodiment of a digital media system
suitable for detecting clock drift between the clock on a hostfsource device 102
that delivers streaming media content and the clock on a client playback device
104 that receives the streaming media content. Host device 102 is generally
configured- to encode- media/video content-200 at a rate regulated by-the host-clock •:•
202 of host device 102. Host device 102 may then store and/or stream the encoded
media/video content 200 over a network 106 to client device 104. Client device
104 is generally configured to receive streaming media/video content 200 and play
back the streaming content at a rate regulated by the client clock 204 of client
device 104.
[0017] In the present embodiment, host device 102 includes a clock drift
detection and recovery module 206 configured to determine if there is clock drift
between the client clock 204 and the host clock 202. The detection and recovery
module 206 determines clock drift based on information it receives from client
device 104 regarding the client media buffer(s) 208. Client device 104 provides"
the buffer information to host device 102 in the form of buffer fullness reports 210.
Buffer fullness reports. 210 indicate the level of data present in client media
buffer(s) 208 on client device 104 during the streaming of media content 200 from
,th.e_v.;-hp,st,device 102 to the client device;.104,:;.. .Thelevelof data indicated-, by -the .,
buffer fullness reports 210 can include the level of audio data 212 in an audio
buffer 208(1) and/or the level of video data 214 in a video buffer 208(2). The
clock drift detection and recoveiy module 206 on host device 102 determines clock
drift based on buffer fullness reports 210(2) it receives from client device 104 as
discussed in greater detail herein below.
[0018] Host device 102 maintains one or more files of media content 200
from which a selection can be made by a media player application 216 on client
device 104 (e.g., in response to user input through the media player application
216). In addition, host device 102 provides access to live content such as from a
live cable TV feed or Webcast that it streams to client playback device 104 upon
request- In -the present embodiment,- -media- content 200 is- to be considered- video
content that typically has an audio component. Thus, as indicated above,
references made herein to "media content", "streaming media", "streaming video",
"video content", and any variation thereof are generally intended to mean
audio/video (A/V) and/or video content. Host device 102 transmits requested
media content 200 as a stream of data over network 106 to media player
application 216 on client device 104.
[0019] Client device 104 maintains media buffer(s) 208 as a way to smooth
out variances in data delivery over network 106 (e.g., network glitches caused by
network cross-traffic, interference, poor wireless reception, etc.), so that they are
not as noticeable to the user during playback of the content. Under favorable
network conditions, the buffer(s) 208 fullness level would be relatively high (e.g.,
>80% full) and would indicate a healthy fullness level. A high fullness level in the
buffer(s) 208 generally permits real time playback of all the media content within
the buffer(s) 208 as well as the remaining streaming media content from host
device 102.
[0020] Buffer monitor 218 on client device 104 is configured to monitor the
fullness level of buffer(s) 208 and to generate buffer fullness reports 210(1) while
media content 200 is being streamed from host device 102. The buffer fullness
reports 210 are a mechanism by which the client device 104 reports buffer fullness
information to the host device 102. In general, this information is used by the
clock drift detection and recovery module 206 on host device 102 to determine if
there is clock drift between the client clock 204 and the host clock 202.
[0021] fig. 3 illustrates four scenarios showing what the client media buffer
208-•fullness-levels might look like over time-as host device 102 streams-media--
content to client device 104. In each scenario, the buffer 208 starts out at a
relatively high or healthy fullness level of approximately 80%. In a first scenario,
demonstrated by plotted line 300, the buffer fullness level gradually increases over
time. This indicates that data in the buffer 208 is being replenished faster than it is
being consumed. In this scenario the buffer 208 will eventually overflow with
data, which typically results in overflow data (frames) either being
discarded/dropped by the client 104 and not played back or stored in a host buffer
(not shown) on the host device 102. In a second scenario, demonstrated by plotted
line 302, the buffer fullness level remains the same over time. This indicates 'that
the data in the buffer 208 is being replenished at the same rate that it is being
consumed. In a third scenario, demonstrated by plotted line 304, the buffer
fullness level gradually~decreases over time. This indicates that data in the buffer
208 is being replenished more slowly than it is being consumed. In the third
.scenario the buffer 208 will eventually be depleted, and a pause or interruption will
occur in media playback on the client device 104 while the buffer 208 is recovered
(i.e., replenished with data). In a fourth scenario, demonstrated by plotted line
306, the buffer fullness drops quickly over time, indicating that data in the buffer
208 is being replenished at a much slower rate than it is being consumed.
[0022] In order to determine if there is clock drift between the client clock
204 and the host clock 202, the clock drift detection and recovery module 206 on
host device 102 receives buffer fullness reports 210(2) generated by buffer monitor
218 on client device 104 and plots the buffer fullness levels over time as indicated
in the buffer fullness reports 210(2). Thus, the clock drift detection and recovery
module 206 may generate plots such as those illustrated and discussed above with
respect to-Fig.-3;—The clock drift detection- and recovery module 206 monitors the
slopes of the lines generated by the plots to determine if clock drift is present
between the client clock 204 and the host clock 202. In general, a gradually
sloping line, either positively or negatively sloped, indicates that clock drift is
present between the client clock 204 and the host clock 202. As discussed in more
detail below, the slope is averaged over time to smooth out network jitter.
[0023J Referring again to Fig. 3, for example, while plotting a line such as
line 300, the clock drift detection and recovery module 206 would determine that
the line 300 has a gradual slope, indicating the presence of clock drift between the
client clock 204 and the host clock 202. Furthermore, because the slope of the line
300 is positive, the clock drift detection and recovery module 206 determines that
the client clock 204 is running at a slower rate than the host clock 202, since the
data in buffer 208 is being consumed (i.e., is being played back by a player
application 216 on client 104) at a slower rate than the host device 102 (regulated
by host clock 202) is .replenishing the data. .Likewise, for other plots-generated
from buffer fullness reports 210(2), the detection and recovery module 206 would
determine from the slopes of the lines plotted whether any clock drift was present
between the client clock 204 and the host clock 202. For example, with respect to
line 302 of Fig. 3, the detection and recovery module 206 would determine that
there is no clock drift because the slope of the line 302 is zero. With respect to line
304, the detection and recovery module 206 would determine from the gradual
negative slope of the line that clock drift was present and that the client clock 104
was running at a faster rate than the host clock 202, since the date in buffer 208 is
being consumed at a faster rate than the host device 102 is replenishing the data.
With respect to line 306, the detection and recovery module 206 would determine
from the- dramatic-negative slope in line-366 that there is -a circumstance beyond
mere clock drift, such as a network outage, that is causing a rapid depletion of the
client buffer 208. A network outage can be differentiated from clock drift because
the rate of incoming media content from the network goes to zero for a network
outage while likely remaining constant, on average, when a network outage does
not exist. In addition, during network congestion the flow of media content may
become slower but not drop completely to zero. For example, if network capacity
is lower than the stream bit-rate (e.g., if an attempt is made to send a 6 mbps
stream over a 5.5 mbps network), buffer fullness on the client device 104 can also
deplete over time. Monitoring additional statistics such as the number of
retrans'mitted/lost packets at the network level, the variation in round trip time over
time, or other statistics can identify such a network overload. Buffer depletion
results that are determined to be a result of network limitations can therefore be
filtered out when determining if clock drift is present between the host clock and
the client clock.
[0024] Fig. 4 illustrates an additional scenario in which the buffer fullness
level fluctuates over time due to network bandwidth fluctuations, as illustrated by
plotted line 400. In this scenario, the buffer fullness may not appear to cleanly
increase or decrease over time. However, the network bandwidth fluctuations can
be filtered out by averaging the buffer fullness over a large time window and
plotting the result (e.g., plotted line 402). The detection and recovery module 206
can then calculate the slope of the plotted line 402 and determine that the buffer
fullness is in fact decreasing at a constant rate. Therefore, as noted above, the
detection and recovery module 206 determines from the gradual negative slope of
line 402 that clock drift is present and that the client clock 104 is running at a
faster rate-than the host clock 202.-
[0025] In addition to detenru'ning whether clock drift is present between the
client clock 204 and the host clock 202, the detection and recovery module 206
calculates the difference in clock speed between the host clock 202 and client
clock 204. Various mathematical models (e.g., mathematical low pass filtering,
statistical analysis, etc.) may be useful in calculating the difference in clock speed
between the host clock 202 and client clock 204 based on the buffer fullness data
from client buffer 208. In one implementation, a difference in clock speed
between the host clock 202 and client clock 204 is defined by the following
definitions and equations (1), (2), and (3):
rh-rc dpc * (ch - cc) (I)
[0026] ch is the actual rate of the host clock 202 in hertz (Hz).
[0027] cc is,the actual rate of the:clientclack2G4.in hertz.
[0028] dpc is a constant indicating the spec'd (i.e., an expected value based
on a value that is specified) data rate of the data stream. That is, dpc is equal to the
spec'ed data rate of both the host device 102 and the client device 104.
[0029] rh is the actual rate of data generation on host device 102, which is
the spec'ed data rate (bits/second) * ch I spec'ed host clock rate in hertz. Thus:
rh = ch * dpc
[0030] re is the actual rate of data consumption on client device 104, which
is the spec'ed data rate (bits/second) * cc I spec'ed client clock rate in hertz. Thus:
re — cc * dpc
[0031] Accordingly, equation (1) above is derived by subtracting re from rh.
Equation (1) can alternatively be expressed with regard to buffer fullness and time
by the following definitions and equation (2):
rh-rc = (ft-fff)/t (2)
[0032] fO is the buffer fullness (in bits of data) at time zero, which is the
percent of buffer fullness at time zero multiplied by the size of the buffer 208 (in
bits).
[0033] ft is the buffer fullness (in bits of data) at time t} which is the percent
of buffer fullness at time t multiplied by the size of the buffer 208 (in bits).
[0034] By equating equations (1) and (2) above, the solution for the
difference in clock speed (i.e., the amount of clock drift) between the host clock
202 and client clack 204. is, apparent as follows in equation (3):
[0035] The values for ft, fO, and / can be determined from the data used to
generate the graph (i.e., from data in the buffer fullness reports 210(2)). The
quantity (ft -fO) 11 is determined from the slope of the line plotted based on the
buffer fullness reports 210(2). Thus, the clock drift detection and recovery module
206 can readily calculate the amount of clock drift between the client clock 204
and the host clock 202 based on equation (3) (i.e., the difference in clock speed
indicated by the quantity ch - cc).
[0036] In the above calculations, an assumption is made that, over time, the
average network capacity is greater than the bit-rate of the media stream being
transmitted by host device 102. If network capacity is lower than the stream bitrate,
buffer fullness on the client device 104 can also deplete over time.
Monitoring additional statistics such as the number of retransmitted/lost packets at
the network level, the variation in round trip time over time, or other statistics that
can identify a network overload, can improve the results noted above for cases in
which network capacity may be lower over time than the stream bit-rate.
[0037] After determining that there is clock drift between the client clock
204 and the host clock 202 and calculating the amount of the clock drift, the
detection and recovery module 206 can implement a recovery method to
synchronize' the clocks. Fof example,' 'the host device 102 may send a'dock change
request to the client 104 instructing the client to speed up or slow down the client
clock 204, If the client clock 204 lags behind the host clock 202, the host device
102 may also drop some video frames from the media content 200 streaming to the
client 104 in order to catch the client clock 204 back up with the host clock 202.
The host device; 102 can also adjust its own clock to synchronize the clocks.
Synchronizing the client clock 204 and host clock 202 helps to reduce playback
interruptions thai can occur when the client buffer 208 is depleted as a result of the
client clock 202 running at a faster rate than the host clock 202. In addition,
synchronizing the client clock 204 and host clock 202 helps to ensure that "live"
content being encoded by the host device 102 at the host clock rate can be
experienced x>r played back on the client device 104 as "live" content at the same
rate it is encoded on the host device 102.
[00383 Fig- 5 illustrates one ot more additional exemplary embodiments of a
digital media system suitable for detecting clock drift between the clock on a host
device 102 that delivers streaming media content and the clock on a client
playback device 104 that receives the streaming media content. The host device
102 and client device 104 are generally configured as discussed above with respect
to the Fig. 2 embodiment. However, in one embodiment of Fig. 5, the client
device 104 may be additionally configured with a clock drift detection and
recovery module 502 to determine if clock drift exists between the client clock 204
snd host clock 202, and to calculate the difference in clock speed between the host
clock 202 and client clock 204 in a manner similar to that discussed above.
Furthermore, upon detecting clock drift and calculating the difference clock speed
between the host clock 202 and client clock 204, the detection and recovery
rapd,ule.,502 of client-device, 104> may. implement: a clock recovery.method, (e.g.r
adjusting the rate of client clock 204 by a certain percentage) to synchronize the
client clock 204 with the host clock 202. In another embodiment, host device 102
may include a clock recovery module 500 configured to receive a clock recoveiy
request and/or information from the clock drift detection and recovery module 502
on the client device 104. Upon receiving such request and/or information, the
clock recovery module 500 may implement a clock recovery method such as
discussed above with regard to the embodiment of Fig. 2.
Exemplary Methods
[0039] Example methods for detecting-clock-drift in a digital media system
between the clock on a host/source device 102 that delivers streaming media
content and the clock on a client playback device 104 that receives the streaming
media content will now be described with primary reference to the flow diagrams
of Figs. 6 and 7. The methods apply to the exemplary embodiments discussed
above with respect to Figs. 3-5. While one or more methods are disclosed by
means of flow diagrams and text associated with the blocks of the flow diagrams,
it is to be understood that the elements of the described methods do not necessarily
have to be performed in the order in which they are presented, and that alternative
orders may result in similar advantages. Furthermore., the methods are not
exclusive and can be performed alone or in combination with one another. The
elements of the described methods may be performed by any appropriate means
including, for example, by hardware logic blocks on an ASIC or by the execution
of processor-readable instructions defined on a processor-readable medium.
[0040] A "processor-readable medium," as used herein, can be any means
that can contain, store, communicate, propagate, or transport instructions for use or
execution by a processor. A processor-readable medium can be, without limitation,
an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor
system, apparatus, device, or propagation medium. More specific examples of a
processor-readable medium include, among others, an electrical connection
(electronic) having one or more wires, a portable computer diskette (magnetic),-a
random access memory (RAM) (magnetic), a read-only memory (ROM)
(magnetic), an erasable programmable-read-only memory (EPROM or Flash
memory), an optical fiber (optical), a rewritable compact disc (CD-RW) (optical),
and a portable • compact-disc read-only memory (ODRQM) (optical).
{0041 ] At block 602 of method 600, a client playback device 104 receives
streaming media content over a network 106 from a host device 102. The media
content includes, for example, audio/video and/or video content. At block 604, the
client device 104 maintains data from the media content in a client buffer 208.
During playback of the streaming media content, the buffer is used to smooth out
variances in data delivery due to fluctuations in network bandwidth (e.g., due to
network glitches caused by network cross-traffic, interference, poor wireless
reception, etc.), so that they are not as noticeable to the user during playback of the
content. At block 606, a buffer monitor 218 monitors the fullness level of the data
in the buffer 208, and at block 608 buffer fullness reports 210(1) are generated
based on the buffer monitoring. Thus as media content streams into the buffer and
is consumed by the client playback device 104, buffer fullness reports are
generated by the buffer monitor that indicate the amount of data present in the
buffer at .various times during the content streaming.
[0042] At block 610 of method $00, a clock drift detection and recovery
module (206, 502) determines if there is clock drift present between the clock on
the host device 102 that is regulating the streaming of the media content and the
clock on the client device 104 that is regulating the playback of the media content.
Method 700, continued on Fig. 7 and discussed below, further describes how clock
drift is determined.
[0043] At block 612 of method 600, the amount of clock drift is calculated.
As discussed herein above, the amount of clock drift is calculated according to the
following equation, where dpc is a constant, and f t , fO, and t can be determined
from the data used to generate the graph (i.e., from data in the buffer fullness
reports 210(2)):
[0044] At block 614 of method 600, the clock drift detection and recovery
module (206, 502) or a clock recovery module 500 implement a clock recovery
method to synchronize the client clock 204 to the host clock 202. The recovery
methods can include, for example, adjusting the client clock, adjusting the host
clock, altering the streaming content from the host device (e.g., dropping frames),
and so on.
[0045] As noted above, method 700 on Fig. 7 further describes how clock
drift detection and recovery module (206, 502) determines if there is clock drift
present between the host clock and the client clock. At block 702 of method 700,
the detection and recovery module (206, 502) plots buffer fullness levels over a
time interval during streaming of the media content to the client device 104. At
block 704, the average slope of a line formed by the plotting is calculated.
Calculating the average slope can include averaging the buffer fullness over a
large time window and plotting the result in order to filter out network bandwidth
fluctuations that might otherwise indicate changes in buffer fullness levels.
[0046] At block 706, the clock drift detection and recovery module (206,
502) determines if there are factors other than clock drift, such as a network
limitation, that might be causing the depletion of client buffer(s) 208. For
example, if network capacity is lower than the stream bit-rate, buffer fullness on
the client device 104 can also deplete over time. Monitoring additional statistics
such as the number of retransmitted/lost packets at the network level,-the variation
in round trip time over time, or other statistics can identify a network overload.
Buffer depletion results that are determined to be a result of network limitations
can therefore be filtered out when determining if clock drift is present between the
host clock and the client clock.
[0047] At block 708, the detection and recovery module (206, 502) monitors
the average slope of the line to determine if there is clock drift present between the
host clock and the client clock. If the average slope of the line is zero, then the
detection and recovery module (206, 502) determines there is no clock drift
present, as shown at block 710. If the average slope of the line is negative, the
detection and recovery module (206, 502) determines that the client clock is faster
than the host clock, as shown at block 712. If the average slope of the line is
positive, the detection and recovery module (206, 502) determines that the client
clock is slower than the host clock, as shown at block 714.
Exemplary Computing Environment
[0048] Fig. 8 illustrates an exemplary computing environment suitable for
implementing computer devices such as a host device 102 and a client playback
device 104 as discussed above with reference to Figs. 1-7. Although one specific
configuration is shown in Fig. 8, such computing devices may be implemented in
other computing configurations.
[0049] The computing environment 800 includes a general-purpose
computing system in the form of a computer 802. The components of computer
802 may include, but are not limited to, one or more processors or processing units
804, a system memory 806, and a system bus 808 that couples various system
components including- the processor 804- to-the system memory 806.
[0050] The system bus 808 represents one or more of any of several types of
bus structures, including a memory bus or memory controller, a peripheral bus, an
accelerated graphics port, and a processor or local bus using any of a variety of bus
architectures. An example of a system bus 808 would be a Peripheral Component
Interconnects (PCI) bus, also known as a Mezzanine bus.
[0051] Computer 802 includes a variety of computer-readable media. Such
media can be any available media that is accessible by computer 802 and includes
both volatile and non-volatile media, removable and non-removable media. The
system memory 806 includes computer readable media in the form of volatile
memory, such as random access memory (RAM) 810, and/or non-volatile memory,
such as read only memory (ROM) 812. A basic input/output system (BIOS) 814,
containing the basic routines that help to transfer information between elements
within computer 802, such as during start-up, is stored in ROM 812. RAM 810
contains data and/or program modules that are immediately accessible to and/or
presently operated on by .the processing unit 804.
[0052] Computer 802 may also include other removable/non-rernovable,
volatile/non-volatile computer storage media. By way of example, Fig. 8
illustrates a hard disk drive 816 for reading from and writing to a non-removable,
non-volatile magnetic media (not shown), a magnetic disk drive 818 for reading
from and writing to a removable, non-volatile magnetic disk 820 (e.g., a "floppy
disk"), and an optical disk drive 822 for reading from and/or writing to a
removable, non-volatile optical disk 824 such as a CD-ROM, DVD-ROM, or other
optical media. The hard disk drive 816, magnetic disk drive 818, and optical disk
drive 822 are each-connected to the system" bus- 808'by one or more -data-media
interfaces 825. Alternatively, the hard disk drive 816, magnetic disk drive 818, and
optical disk drive 822 may be connected to the system bus 808 by a SCSI interface
(not shown).
[0053J The disk drives and their associated computer-readable media
provide non-volatile storage of computer readable instructions, data structures,
program modules, and other data for computer 802. Although the example
illustrates a hard disk 816, a removable magnetic disk 820, and a removable optical
disk 824, it is to be appreciated that other types of computer readable media which
can store data that is accessible by a computer, such as magnetic cassettes or other
magnetic storage devices, flash memory cards, CD-ROM, digital versatile disks
(DVD) or other optical storage, random access memories (RAM), read only
memories (ROM), electrically erasable programmable read-only memory
(EEPROM), and the like, can also be utilized to implement the exemplary
computing system and environment.
[0054] Any number of program modules can be stored on the hard disk 816,
magnetic disk 820, optical disk 824, ROM 812, and/or RAM 810, including by
way of example, an operating system 826, one or more application programs 828,
other program modules 830, and program data 832. Each of such operating system
826, one or more application programs 828, other program-modules 830, and
program data 832 (or some combination thereof) may include an embodiment of a
caching scheme for user network access information.
[0055] Computer 802 can include a variety of computer/processor readable
media identified as communication media. Communication media embodies
computer readable instructions, data structures, program modules, or other data in
a modulated data-signal'such as-a carrier wave-or-other transport mechanism -andincludes
any information delivery media. The term "modulated data signal" means
a signal that has one or more of its characteristics set or changed in such a manner
as to encode information in the signal. By way of example, and not limitation,
communication media includes wired media such as a wired network or directwired
connection, and wireless media such as acoustic, RF, infrared, and other
wireless media. Combinations of any of the above are also included within the
scope of computer readable media.
[0056] A user can enter commands and information into computer system
802 via input devices such as a keyboard 834 and a pointing device 836 (e.g., a
"mouse"). Other input devices 838 (not shown specifically) may include a
microphone, joystick, game pad, satellite dish, serial port, scanner, and/or the like.
These and other input devices are connected to the processing unit 804 via
input/output interfaces 840 that axe coupled to the system bus 808, but may be
connected by other interface and bus structures, such as a parallel port, game port,
or a universal serial bus (USB).
[0057] A monitor 842 or other type of display device may also be connected
to the system bus 808 via an interface, such as a video adapter 844. In addition to
the monitor 842, other output peripheral devices may include components such as
speakers (not shown) and a printer 846 which can be connected to computer 802
via the input/output interfaces 840.
[0058] Computer 802 may operate in a networked environment using logical
connections to one or more remote computers, such as a remote computing device
848. By way of example, the remote computing device 848 can be a personal
computer, portable computer, a server, a router; -a network computer, a peer device
or other common network node, and the like. The remote computing device 348 is
illustrated as a portable computer that may include many or all of the elements and
features described herein relative to computer system 802.
[0059] Logical connections between computer 802 and the remote computer
848 are depicted as a local area network (LAN) 850 and a general wide area
network (WAN) 852. Such networking environments are commonplace in offices,
enterprise-wide computer networks, intranets, and the Internet. When
implemented in a LAN networking environment, the computer 802 is connected to
a local network 850 via a network interface or adapter 854. When implemented in
a WAN networking environment, the computer 802 includes a modem 856 or other
means for establishing communications over the wide network 852. The modem
856, which can be internal or external to computer 802, can be connected to the
system bus 808 via the input/output interfaces 840 or other appropriate
mechanisms. It .is to be appreciated that the illustrated network connections are
exemplary arid that other means of establishing communication link(s) between the
computers 802 and 848 can be employed.
[0060] In a networked environment, such as that illustrated with computing
environment 800, program modules depicted relative to the computer 802, or
portions thereof, may be stored in a remote memory storage device. By way of
example, remote application programs 858 reside on a memory device of remote
computer 848. For purposes of illustration, application programs and other
executable program components, such as the operating system, are illustrated
herein as discrete blocks, although it is recognized that such programs and
components reside at various times in different storage components of the
computer system 802, and are executed by the data-processor(s)-of the computer.
Conclusion
[0061] Although the invention has been described in language specific to
structural features and/or methodological acts, it is to be understood that the
invention defined in the appended claims is not necessarily limited to the specific
features or acts described. Rather, the specific features and acts are disclosed as
exemplary forms of implementing the claimed invention.

WE CLAIMS
1. A method for detecting clock drift in a digital media system including at least a host device and a client device, the method comprising:
on the client device:
receiving (602) streaming content from the host device having a host clock regulating the encoding process of the streaming content, wherein the client device comprises a client clock regulating playback of the streaming content;
maintaining (604) data from the streaming content in a client device buffer;
monitoring (606) a buffer fullness level that reflects a level of data in the buffer; and
generating (608) and sending buffer fullness level reports to the host device;
wherein the method further comprises on the host device:
based on the buffer fullness level reports, determining if there is clock drift between the host clock and the client clock,
2. A method as recited in claim 1, wherein the determining comprises:
plotting buffer fullness levels over a time interval;
calculating an average slope of a line formed by the plotting; and monitoring the average slope of the line.
3. A method as recited in claim 2, wherein the average slope of the line is zero, and the
determining comprises determining that there is no clock drift between the host clock
and the client clock.

4. A method as recited in claim 2, wherein the average slope of the line is negative, and the determining comprises determining that the client clock is faster than the host clock.
5. A method as recited in claim 2, wherein the average slope of the line is positive, and the determining comprises determining that the client clock is slower than the host clock,
6. A method as recited in claim 2, wherein calculating an average slope of a line comprises filtering out bandwidth fluctuations of a network over which the streaming content is transmitted.
7. A method as recited in claim 1, wherein the determining comprises notifying the host
device if there is clock drift between the host clock and the client clock, and the
monitoring and the determining are performed on a device selected from the group
comprising:
the client device; and
a third device other than the host device and the client device.
8. A method as recited in claim 1, further comprising calculating a clock drift amount in accordance with
(Equation Removed)
wherein:
the clock drift amount is equal to ch - cc,
ch is the frequency of the host clock;
cc is the frequency of the client clock;
dpc is a specified data generation rate on the host device in bits per second;
f0 is the buffer fullness level at time 0; and
ft is the buffer fullness level at time t
9. A method as recited in claim 1, further comprising implementing a clock recovery method to eliminate the clock drift between the host clock and the client clock.

0. A method as recited in claim 9 wherein the implementing is selected from the group comprising:
adjusting the client clock;
adjusting the host clock;
altering the streaming content from the host device; and
dropping data frames on the client device.
. A processor-readable medium comprising processor-executable instructions configured for detecting clock drift in a digital media system, the instructions being configured for
transmitting streaming content from a host device having a host clock regulating the encoding process of the streaming content to a client device, the client device comprises a client clock regulating playback of the streaming content;
monitoring a buffer fullness level of a data buffer for data from the streaming content on the client device over a measured time interval;
generating (608) and sending buffer fullness level reports to the host device from the client device; and
based on the buffer fullness level reports, determining on the host device if clock drift is present between the host clock on the host device and the client clock on the client device,
A processor-readable medium as recited in claim 11, wherein the determining comprises:
calculating a rate of change in the buffer fullness level over the measured time interval; and
based on the rate of change in the buffer fullness level, determining that the clock drift is present.
A processor-readable medium as recited in claim 12. wherein the rate of change in the buffer fullness level is a constant positive rate of change, and the determining that the

clock drift is present comprises determining that the client clock is operating at a lower frequency than the host clock.
14. A processor-readable medium as recited in claim 12, wherein the rate of change in the buffer fullness level is a constant negative rate of change, and the determining that the clock drift is present comprises determining that the client clock is operating at a higher frequency than the host clock.
15. A processor-readable medium as recited in claim 12, having further processor-executable instructions configured for calculating an amount of clock drift based on the rate of change in the buffer fullness level.
16. A processor-readable medium as recited in claim 15, wherein the amount of cfock drift is calculated in accordance with
(Equation Removed)
.
wherein:
the clock drift amount is equal to ch - cc,
ch is the frequency of the host clock;
cc is the frequency of the client clock;
dpc is a specified data generation rate on the host device in bits per second;
to is the buffer fullness level at time 0; and
ft is the buffer fullness level at time t
17, A system comprising:
a client device (104) configured for receiving media content from a host device (102) and for playing back the media content, wherein the client device comprises a client clock (204) regulating playback of the media content, and wherein the host device comprises a host clock (202) regulating the encoding process of the media content;
a buffer monitor (218) on the client device configured for monitoring a client buffer (208) and generating buffer fullness reports (210(1)) indicating amounts of data in the client buffer, and

a clock drift detection and recovery module (206) on the host device configured to receive the buffer fullness reports from the buffer monitor and to determine from the buffer fullness reports if clock drift is present between a host clock and a client clock.
18. A system as recited in claim 17, wherein the clock drift detection and recovery module is configured to implement a recovery method to correct the clock drift.