Patent Description:
<CIT> relates to techniques for sensor data time alignment. Sensor data from different sensor systems is time-aligned to a reference time base. Reference time values may be propagated to sensor systems to enable the sensor systems to mark sensor data based on the reference time values. Sensor data from a sensor system may be time-aligned by applying an alignment policy to the sensor data. An alignment policy accounts for a difference between a time base of a sensor system and a reference time base.

<CIT> relates to a method of and a system for synchronizing isochronous audio data frames provided by a USB interface to a clock of a wireless RF communication device. The USB interface and the wireless RF communication device are connected via an I2S link, the method comprising receiving the isochronous audio data frames and the wireless RF communication device clock in a streaming controller, phase locking the isochronous audio data frames to a USB interface clock, counting start-of-frame pulses of the phase locked isochronous audio data frames, comparing the counted start-of-frame pulses with the wireless RF communication device clock to determine a difference signal, the difference signal triggering a synchronization event code when a threshold difference has been reached, rate matching the isochronous audio data frames to the wireless RF communication device clock upon receiving the synchronization event code.

<CIT> relates to technology for synchronization of clock information between networked devices. One or more of the devices may include one or more applications needed access to data and a common time reference between devices. The devices have applications utilizing data shared in a network environment with other devices, as well as having a reference to a local clock signal on each device. A device may have a layer of code between the operating system and software applications that processes the data and maintains a remote clock reference for one or more of the other devices on the network.

<CIT> relates to a programmable computer which receives samples of an input signal and outputs the samples under program control. Desired output time points for the samples are determined with respect to a time-base defined by the input signal. The samples are output with a timing determined by an output timer which is asynchronous to that time base. The program reads the output timer via a variable latency bus, which does not provide real time samples of the output timer. The program estimating parameters of the output timer by an averaging process using timer values read from the output timer. The program predicts future time values of the output timer dependent on the output time point and at least one parameter and generates time-stamps from the future time values. The samples are output when the output timer reaches the computed time stamps.

According to aspects of the present invention there is provided a method, device, and computer-readable medium as defined in the accompanying claims.

The following presents a simplified summary of one or more implementations in order to provide a basic understanding of such implementations. This summary is not an extensive overview of all contemplated implementations, and is intended to neither identify key or critical elements of all implementations nor delineate the scope of any or all implementations. Its sole purpose is to present some concepts of one or more implementations in a simplified form as a prelude to the more detailed description that is presented later.

According to one aspect of the invention, there is provided a method for synchronizing multiple timing sources in a computing device as defined by independent claim <NUM>.

In another aspect of the invention, there is provided a device for synchronizing multiple timing sources as defined by independent claim <NUM>.

In another aspect of the invention, there is provided a computer-readable medium including code executable by one or more processors for synchronizing multiple timing sources in a computing device as defined by independent claim <NUM>.

To the accomplishment of the foregoing and related ends, the one or more implementations comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more implementations. These features are indicative, however, of but a few of the various ways in which the principles of various implementations may be employed without departing from the scope of the appended claims.

In some instances, well-known components are shown in block diagram form in order to avoid obscuring such concepts.

This disclosure describes various examples related to synchronizing timing among multiple timing sources in a computing device, which can facilitate association of data obtained from multiple sources though the data may be timestamped (or otherwise associated with a time) based on different timing sources. For example, where a computing device operates multiple timing sources, a first clock value of a first timing source can be determined respective to, or as otherwise compared with, a second clock value of a second timing source. In an example, the first clock value and second clock value can correspond to elapsed time values for the first and second timing sources between known events, such as between instances of a reoccurring event, between initialization and an instance of an event, etc. The difference between the elapsed time values can provide an indication of clock drift among the timing sources (e.g., as measured from the known event(s)). An indication of the clock drift or other difference between the first clock value and the second clock value can be provided to one or more applications to allow the applications to synchronize timing among the timing sources.

In a specific example, an application may receive data from an input device having an associated timestamp that uses a timing source associated with the input device. For example, this timing source may be a timing source of the input device itself, a timing source of a corresponding interface controller that interfaces the input device with the computing device, etc. The application may request the synchronization information from an operating system, which may include a clock value of a current frame of the timing source associated with the interface controller, and a host clock value of the computing device (e.g., of a central processing unit (CPU) or other processor of the computing device) at the current frame of the interface controller. The application can use the clock value and the host clock value to determine a host clock value associated with the timestamp of the data from the input device. In another example, the synchronization information can include clock drift information, which the application can further apply to determine a more accurate host clock value associated with the timestamp of the data from the input device where clock drift is occurring.

Turning now to <FIG>, examples are depicted with reference to one or more components and one or more methods that may perform the actions or operations described herein, where components and/or actions/operations in dashed line may be optional. Although the operations described below in <FIG> are presented in a particular order and/or as being performed by an example component, the ordering of the actions and the components performing the actions may be varied, in some examples, depending on the implementation. Moreover, in some examples, one or more of the actions, functions, and/or described components may be performed by a specially-programmed processor, a processor executing specially-programmed software or computer-readable media, or by any other combination of a hardware component and/or a software component capable of performing the described actions or functions.

<FIG> is a schematic diagram of an example of a device <NUM> (e.g., a computing device) that can synchronize timing among multiple timing sources. The device <NUM> includes a processor <NUM> and memory <NUM> configured to execute or store instructions or other parameters related to providing an operating system <NUM>, which can provide an environment for executing one or more applications <NUM>, etc. For example, processor <NUM> and memory <NUM> may be separate components communicatively coupled by a bus (e.g., on a motherboard or other portion of a computing device, on an integrated circuit, such as a system on a chip (SoC), etc.), components integrated within one another (e.g., processor <NUM> can include the memory <NUM> as an on-board component <NUM>), and/or the like. Memory <NUM> may store instructions, parameters, data structures, etc., for use/execution by processor <NUM> to perform functions described herein. Device <NUM> can also include one or more input devices <NUM>, <NUM> that can be integrated within device <NUM>, attached as a peripheral to the device <NUM> (e.g., via one or more wired or wireless interface (e.g., universal serial bus (USB), Firewire, local area network (LAN), wireless LAN (WLAN), Bluetooth, radio frequency identification (RFID), near field communication (NFC), etc.), and/or the like. For example, the one or more input devices <NUM>, <NUM> may include one or more sensor devices, which may include an inertial sensor (e.g., an accelerometer, gyroscope, etc.), an image sensor (e.g., a red, green, blue (RGB) camera, infrared (IR) camera, depth camera, etc.), which may be video cameras, still image cameras, etc., an eye scan or eye tracking sensor, a fingerprint or touch sensor, a microphone, etc., for receiving and/or processing input data intended for the device <NUM>.

In an example, device <NUM> can provide an interface controller <NUM> over which input devices <NUM>, <NUM> can communicate with other components of the device <NUM>, such as operating system <NUM>, applications <NUM>, etc. to provide data received from the input device. For example, operating system <NUM> can provide an interface controller driver <NUM>, which can be a user mode driver, to facilitate communication between the interface controller <NUM> and the operating system <NUM> to receive and/or transmit data from/to the input devices <NUM>, <NUM>. In an example, the interface controller <NUM> can be a USB controller configured to communicate with one or more input devices <NUM>, <NUM> via a USB interface. The USB controller can receive data from the input devices <NUM>, <NUM> in a format for communicating over USB, and can provide corresponding data to the interface controller driver <NUM>. Operating system <NUM>, and/or application <NUM>, can access the data from the input devices <NUM>, <NUM> via the interface controller driver <NUM> communicating with interface controller <NUM>. In other examples, interface controller <NUM> may include a Firewire, LAN, WLAN, Bluetooth, RFID, NFC, or substantially any controller configured for communicating via a wired or wireless interface, and may have a corresponding interface controller driver <NUM>.

For example, processor <NUM> (or another component of the device <NUM>) can maintain a timing source in the form of a host clock <NUM>, which can provide a clock used in executing instructions on the processor <NUM> (e.g., a CPU clock). For example, the host clock <NUM> can track time using a first granularity (e.g., a number of hertz (Hz)). In addition, in an example, the operating system <NUM> may access the host clock <NUM>, and can provide an interface to host clock <NUM> values via a query performance counter (QPC) function. The interface controller <NUM>, in an example, can also maintain a timing source in the form of an interface clock <NUM> for timestamping data received from the input devices <NUM>, <NUM>. The interface clock <NUM> may track time using a second granularity (e.g., a number of Hz), which may be different than the first granularity. In one example, the host clock <NUM> and interface clock <NUM> may operate using a similar bus speed in theory, but the clocks <NUM>, <NUM> may actually drift (e.g., at different rates) over time due to a variety of factors. For example, the interface clock <NUM> may be implemented in different hardware than the host clock <NUM>, and each clock <NUM>, <NUM> or related hardware may have properties that result in the clocks <NUM>, <NUM> tracking time differently. In one example, silicon used to provide the processor <NUM> and/or interface controller <NUM> may be different, which may cause the clocks <NUM>, <NUM> to drift. In another example, operating or ambient temperature may be different, which may cause the clocks to drift. Moreover, the clocks <NUM>, <NUM> may not initialize to the same initial time value. Accordingly, the host clock <NUM> and interface clock <NUM> may not be synchronized, and thus their clock values at any given time may differ and/or differ at different rates (drift) as time goes by.

Accordingly, interface controller driver <NUM> (and/or another component of the operating system <NUM>) may include a timing source synchronizing component <NUM> for applying a synchronization to clock values of different timing sources, such to allow the operating system <NUM> and/or one or more applications <NUM> to resolve the clock values of the timing sources with respect to one another. In applying the synchronization, the timing source synchronizing component <NUM> can provide clock values of the host clock <NUM>, interface clock <NUM> (and/or other clocks) at a particular instant in time, which corresponds to a reoccurring event in the domain of the host clock <NUM> or interface clock <NUM>. In another example, the timing source synchronizing component <NUM> can additionally provide other information regarding the timing difference between host clock <NUM> and interface clock <NUM>, such as a difference value at the instant in time, a clock drift measured at the instant in time with respect to a previous instant in time (e.g., a time of a previous instance of the reoccurring event, a time at initialization of the host clock <NUM> and/or the interface clock <NUM>, etc.), a prediction of accuracy of the reported clock drift, and/or the like. Operating system <NUM> and/or one or more applications <NUM> can use this information to resolve a clock value of interface clock <NUM> in the domain of host clock <NUM>, and/or vice versa (and/or resolve other clock values of one domain in another domain). This can enable the operating system <NUM> and/or one or more applications <NUM> to correlate data received from multiple input devices via the interface controller <NUM> (and/or via one or more other interface controllers, not shown) and/or data associated with the operating system <NUM> and/or application(s) <NUM>, etc..

<FIG> is a flowchart of an example of a method <NUM> for synchronizing multiple timing sources in a computing device. For example, method <NUM> can be performed by a device <NUM> and/or one or more components thereof to facilitate synchronizing timing values received from a host clock <NUM>, interface clock <NUM>, and/or other clocks.

In method <NUM>, at action <NUM>, at least a first clock associated with a first timing source and a second clock associated with a second timing source can be maintained. In an example, device <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, interface controller <NUM>, etc., can maintain at least the first clock associated with the first timing source (e.g., host clock <NUM> associated with processor <NUM>) and the second clock associated with the second timing source (e.g., interface clock <NUM> associated with interface controller <NUM>). In an example, as described, the clocks <NUM>, <NUM> may be implemented in processor <NUM> and/or interface controller <NUM> hardware, which may be connected via a bus on the device <NUM> to facilitate communication therebetween and/or with other components of the device <NUM>. Maintaining the clocks <NUM>, <NUM>, in this regard, may include the corresponding hardware (e.g., processor <NUM>, interface controller <NUM>, etc.) initializing and/or operating the clocks to track time at corresponding granularities and/or based on corresponding clock speeds (e.g., a number of Hz).

In an example, as described, processor <NUM> may maintain host clock <NUM> as a CPU clock based on a number of pulses per second that can be measured in Hz. In addition, for example, interface controller <NUM> may maintain interface clock <NUM> as a USB clock for tracking a number of USB frames, occurring every <NUM> millisecond (ms), and a number of USB microframes within each USB frame, which occur every <NUM> microseconds (us). The host clock <NUM> and interface clock <NUM> may not always be synchronized based on being provided by different hardware, at environments with different ambient temperatures within the device <NUM>, etc. Based on this and/or based on the fact that the clocks <NUM>, <NUM> operate using different granularities, the device <NUM> may benefit from a synchronization of the clocks <NUM>, <NUM> using a provided indication for matching values of one clock with values of the other at one or more instants in time. Mechanisms for achieving such synchronization are described herein.

In method <NUM>, at action <NUM>, a request for an indication of a difference in values between the first clock and the second clock can be received. In an example, interface controller driver <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, operating system <NUM>, etc., can receive the request (e.g., from an application <NUM>) for the indication of the difference in values between the first clock (e.g., host clock <NUM>) and the second clock (e.g., interface clock <NUM>). In one example, the application <NUM> can issue the request to the timing source synchronizing component <NUM> based on the application <NUM> initializing a module for receiving data from the one or more input devices <NUM>, <NUM> via interface controller <NUM>. According to the invention, the application <NUM> issues the request based at least in part on comparing a processing load to a threshold or an operating/ambient temperature to a threshold to ensure additional processing performed by the timing source synchronizing component <NUM> does not cause undesirable load on the processor <NUM>. Moreover, for example, the request can correspond to a request for a single indication of the difference, which can be measured as a number of ms, us, etc. In another example, the request may correspond to a request to receive multiple indications of the difference occurring based on a clock overflow, as described further herein.

In method <NUM>, at action <NUM>, a first elapsed time of the first clock and a second elapsed time of the second clock from a previous instance of an event can be determined at an instance of a reoccurring event in a domain of one of the first timing source or the second timing source. In an example, timing source synchronizing component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, operating system <NUM>, etc., can determine, at the instance of the reoccurring event in the domain of the one of the first timing source (e.g., processor <NUM>) or the second timing source (e.g. interface controller <NUM>), the first elapsed time of the first clock and the second elapsed time of the second clock from the previous instance of the event. For example, the previous instance of the event may correspond to initialization of the host clock <NUM> and/or interface clock <NUM>, a previous instance of the reoccurring event, and/or the like. According to the invention, the reoccurring event corresponds to a clock overflow of the host clock <NUM> and/or interface clock <NUM>.

In a specific example, the interface controller <NUM> may be a USB controller, and the interface clock <NUM> may accordingly report time to the operating system <NUM> through a register (MFINDEX) with <NUM> bits for the elapsed USB micro frames, where <NUM> bits are used for elapsed <NUM> frames and <NUM> bits are used for elapsed <NUM> microframes within the given <NUM> frame. Accordingly, the interface clock <NUM> for USB can report clock values up to <NUM> at a granularity of <NUM>. In this example, the reoccurring event can correspond to an interrupt received when the MFINDEX register overflows (e.g., and resets the interface clock <NUM>, which can occur every <NUM> in the interface clock <NUM> domain). In this example, the timing source synchronizing component <NUM> can continuously determine an elapsed time of the host clock <NUM> every <NUM> in the interface clock <NUM> domain, based on occurrence of the MFINDEX register overflow, to determine the clock drift between the host clock <NUM> and the interface clock <NUM>. For example, where timing source synchronizing component <NUM> determines that the host clock <NUM> elapses <NUM> between instances of the reoccurring event (e.g., when the interface clock <NUM> elapses <NUM>), the timing source synchronizing component <NUM> can determine that the interface clock <NUM> is around <NUM> / <NUM> = <NUM>% faster than the host clock <NUM>. Accordingly, after the start of a new frame, the timing source synchronizing component <NUM> can expect the next microframe to occur at <NUM> * <NUM>% = <NUM>, the second microframe to start at <NUM>, the third microframe to start at <NUM>, etc., in the host clock <NUM> domain. In an example, timing source synchronizing component <NUM> can provide the difference in values of the clocks <NUM>, <NUM>, a computed clock drift (e.g., as a percentage and/or as applied to one of the clock values), etc..

In method <NUM>, optionally at action <NUM>, a clock drift can be computed based on a difference between the first elapsed time and the second elapsed time. In an example, timing source synchronizing component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, operating system <NUM>, etc., can compute the clock drift between the first elapsed time and the second elapsed time. As described above, for example, the timing source synchronizing component <NUM> can determine the first elapsed time of the first clock (e.g., host clock <NUM>) between two instants in time and the second elapsed time of the second clock (e.g., interface clock <NUM>) between the instants in time, and can determine clock drift based on the difference between the elapsed times (e.g., as measured in ms, us, etc.). In addition, for example, timing source synchronizing component <NUM> can determine this clock drift at each instance of the reoccurring event, as described. Moreover, for example, timing source synchronizing component <NUM> can report the clock drift to operating system <NUM> (or one or more components thereof), one or more applications <NUM>, etc. periodically and/or based on request.

In method <NUM>, optionally at action <NUM>, a time at which the past events occur in a second domain of the other one of the first timing source or the second timing source can be predicted, in the domain of the one of the first timing source or the second timing source and based on the clock drift, to determine an accuracy of the computed clock drift. In an example, timing source synchronizing component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, operating system <NUM>, etc., can predict, in the domain of the one of the first timing source or the second timing source and based on the clock drift (e.g., the clock drift determined by the timing source synchronizing component <NUM>, as described above), the time at which the past events occur in the second domain of the other one of the first timing source or the second timing source to determine an accuracy of the computed clock drift. For example, timing source synchronizing component <NUM> can apply the clock drift, determined in the domain of the host clock <NUM>, to a time of a past event occurring in the domain of the interface clock <NUM>, and can compare the result to the actual time of the event in the domain of the interface clock <NUM> to determine the accuracy. For example, timing source synchronizing component <NUM> can determine the accuracy as a computed value of predicted time and the actual time (e.g., a ratio of predicted time to actual time, and/or the like). This can allow the timing source synchronizing component <NUM> to indicate the accuracy when providing an indication of clock values, clock drift, etc., as described herein.

In method <NUM>, optionally at action <NUM>, an accuracy of the predicted time can be determined. In an example, timing source synchronizing component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, operating system <NUM>, etc., can determine the accuracy of the predicted time. For example, timing source synchronizing component <NUM> can determine the accuracy of the predicted time based on an accuracy of one of the first timing source or the second timing source. Thus, for example, in the case of a USB timing source, the accuracy may correspond to the granularity of the USB clock (e.g., <NUM>). In an example, however, the request received at action <NUM> may indicate an option for an edge detection, in which case determining the first elapsed time of the first clock and second elapsed time of the second clock can occur at an instance of an edge of one of the clocks (e.g., where the edge can be a round division of time, such as a frame or microframe, an instance of a beginning of a microsecond, etc.). For example, where interface clock <NUM> is for USB, timing source synchronizing component <NUM> can determine the first elapsed time and second elapsed time at an edge of the interface clock <NUM> (e.g., at a beginning of a USB frame of <NUM> or a beginning of a USB microframe at <NUM>). In this example, timing source synchronizing component <NUM> can determine (and indicate, e.g., as part of the indication in action <NUM> below) an accuracy corresponding to the granularity of the host clock <NUM> (e.g., on the order of tens or hundreds of nanoseconds for a QPC).

In method <NUM>, at action <NUM>, an indication related to the first elapsed time and the second elapsed time can be provided. In an example, timing source synchronizing component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, operating system <NUM>, etc., can provide the indication related to the first elapsed time and the second elapsed time. For example, timing source synchronizing component <NUM> can provide the indication to the application <NUM>, which can have requested the indication (e.g., at action <NUM>). In addition, timing source synchronizing component <NUM> can provide the indication in response to the request, periodically based on one or more triggers, such as the reoccurring event, etc. Moreover, timing source synchronizing component <NUM> may include, in the indication, one or more clock values from the first clock and/or second clock, the first elapsed time and second elapsed time, a difference between the first elapsed time and the second elapsed time, a computed clock drift (e.g., as a percentage, a number of microseconds or other measure of time, etc.), a predicted accuracy of the computed clock drift, etc., as described above. In addition, timing source synchronizing component <NUM> can enable or disable tracking and/or determining clock drift based on a variety of factors, such as power utilization, ambient or operational temperature, etc..

In one example, timing source synchronizing component <NUM> can autonomously (and/or based on an initial request) manage synchronizing of the clocks <NUM>, <NUM>, and determining of the first and/or second elapsed time, clock drift, accuracy, etc. based on the reoccurring event over a period of time. In this example, timing source synchronizing component <NUM> may provide the current indication of the first and/or second elapsed time, clock drift, accuracy, etc. upon request.

The examples described above can allow for sufficiently accurate and power-efficient synchronization between the time derived from the processor <NUM> clock and the interface clock <NUM> (e.g., USB bus time derived from the USB controller clock). For example, the application <NUM> can query an application programming interface (API) that can be exposed by the interface controller driver <NUM> (e.g., the USB driver stack in the operating system <NUM>) that maps to the QPC values, which can be tracked by the operating system <NUM> and can correspond to a timing of the host clock <NUM>, to the interface (e.g., USB) frame and microframes tracked by the interface controller <NUM> (e.g., USB host controller hardware). This can allow the application <NUM> to synchronize its own functions, which can operate on the processor <NUM> and thus correspond to the timing of the host clock <NUM>, with the data provided by the devices on the interface controller <NUM> (e.g., USB bus), which can correspond to the timing of the interface clock <NUM>. For example, the API exposed by the interface controller driver <NUM> can allow application <NUM> to get the current interface (e.g., USB) frame and microframe, as well as the QPC value associated with the frame and microframe. As described, for example, the interface controller driver <NUM> can determine the QPC value associated with a current frame and microframe, a QPC value associated with a previous frame and microframe, etc., and can provide the information to the application <NUM> upon request. In addition, for example, the API can allow the application <NUM> to get the QPC value that occurred at the beginning of a specified interface (e.g., USB) frame and microframe (e.g., at the edge, which the timing source synchronizing component <NUM> can detect and use to determine to record the corresponding QPC). Moreover, in an example, the API can allow the application <NUM> to get the predicted accuracy of the QPC value, as described.

In a specific example, device <NUM> can include a head-mounted display (HMD) device for providing a virtual reality, mixed reality, or similar experience. The HMD device can include various inertial sensors, cameras, etc. as input devices <NUM>, <NUM> for detecting a head position of the HMD device, which can be used in rendering scenes to a display on the HMD device. In an example, the inertial sensors, cameras, etc. can be connected to the HMD device (e.g., processor <NUM> of the HMD device) via a USB bus. In this example, an application <NUM> executing to provide the virtual reality/mixed reality experience can obtain data from the various input devices <NUM>, <NUM>, which may indicate a movement of the HMD device, an acceleration or speed related to the movement, images captured from the HMD device, etc. In an example, strong timing correlation among the data from the various sensors and the application <NUM> may be desirable (e.g., to match inertial measurements with corresponding captured images, etc.). The interface controller <NUM> can receive the data from the various input devices <NUM>, <NUM> with timestamps (e.g., based on clocks in the input devices <NUM>, <NUM>, the interface clock <NUM>, such as a USB clock, etc.) and/or may perform the timestamping as the input data is received.

In this example, the application <NUM> can resolve the timestamps from the interface clock <NUM> to corresponding time values of the host clock <NUM>. In one example, the application <NUM> can request and/or periodically receive, from the timing source synchronizing component <NUM>, the interface clock <NUM> value (e.g., frame and/or microframes) and the host clock <NUM> value (e.g., QPC value) at the same or similar instant in time. Timing source synchronizing component <NUM> can compute (e.g., on request) or otherwise maintain (e.g., and report on request) the clock drift between the values of the clocks <NUM>, <NUM>. In this example, application <NUM> can resolve the timestamps by applying the currently maintained clock drift thereto. In another example, application <NUM> can request, from the timing source synchronizing component <NUM>, the host clock <NUM> value corresponding to a previous interface clock <NUM> value, which application <NUM> can indicate in the request, and timing source synchronizing component <NUM> can predict the previous time, as described above, and/or may return a computed accuracy for the predicted time. In yet another example, application <NUM> can request and/or periodically receive, from the timing source synchronizing component <NUM>, the determined clock drift amount, which the application <NUM> can apply to received interface clock <NUM> values to resolve the corresponding host clock <NUM> value. In any case, application <NUM> can determine the host clock <NUM> value corresponding to input data received from input devices <NUM>, <NUM> for synchronizing the received data with other received or generated data (e.g., synchronizing motion data of the HMD device with an image or scene rendered by the application <NUM>), synchronizing the received data with operations of the application <NUM>, and/or the like.

<FIG> illustrates an example of a message flow diagram <NUM> for indicating synchronization information for multiple timing sources in accordance with examples described herein. Message flow diagram <NUM> shows an application <NUM> that can communicate with an interface controller driver <NUM> to obtain synchronization information for multiple clocks, and an interface controller <NUM> that can maintain a clock for an interface (e.g., a USB interface). In one example, application <NUM> can optionally send an API registration to the interface controller driver <NUM> at <NUM>, which can allow the application <NUM> to request use of the interface controller driver <NUM> to communicate with the interface controller <NUM>, and/or more specifically, to receive timing synchronization information from the interface controller driver <NUM>. In response or otherwise, interface controller driver <NUM> can optionally send a request synchronization start command to the interface controller <NUM> at <NUM>, which can cause the interface controller <NUM> to provide or call interrupts on the interface controller driver <NUM> to notify the interface controller driver <NUM> of one or more timing-related events. Starting the interrupts when the API registration is sent at <NUM> can allow for minimizing interruptions to the device where the synchronization functionality is not needed. For example, interface controller <NUM> can call a callback function on the interface controller driver <NUM>, or otherwise notify the interface controller driver <NUM> of the timing-related event, which may include interface controller <NUM> notifying the interface controller driver <NUM> when a new frame starts, when a new microframe starts, and/or the like.

For example, interface controller <NUM> can maintain a clock (e.g., interface clock <NUM>) that can track frames and/or microframes over the interface for communicating with one or more input devices. Where the interface controller <NUM> is a USB controller, as described above, the frames can occur every <NUM> and the microframes can occur every <NUM> within each <NUM> frame. In any case, interface controller <NUM> can notify the interface controller driver <NUM> of each frame by sending a frame start notification to the interface controller driver <NUM> at <NUM>. Interface controller driver <NUM> can store the frame, microframe, and/or a QPC (e.g., in a memory, such as memory <NUM>) based on receiving the frame start at <NUM>. For example, interface controller driver <NUM> can obtain the QPC based on receiving the frame start, where the QPC can be based on a host clock of a processor of the device (e.g., host clock <NUM> of processor <NUM>, etc.). In another example, interface controller <NUM> can optionally also notify the interface controller driver <NUM> of each microframe start at <NUM>, and/or the interface controller driver <NUM> can similarly store the frame, microframe, and/or QPC at <NUM>. In yet another example, interface controller <NUM> can notify the interface controller driver <NUM> each time the interface clock overflows, as described.

In this example, application <NUM> may optionally request timing information from the interface controller driver at <NUM> (e.g., via an API call), and the interface controller driver <NUM> can provide corresponding timing information to the application at <NUM>. As described, for example, the timing information <NUM> can include the more recently stored QPC, frame, and/or microframe to allow the application <NUM> to match a current frame and microframe to a current QPC for synchronizing data from an input device received via the interface controller driver <NUM> with other input device data and/or data generated by the application <NUM>. In another example, the timing information received at <NUM> can include a timing difference determined between the QPC and frame/microframe, a computed drift of one or more of the host clock <NUM> or interface clock <NUM> based on two or more previous QPC values and associated frame/microframe, as described above. In yet another example, the application <NUM> can include a previous frame/microframe in the request at <NUM> and can receive an associated QPC in timing information at <NUM>, and/or vice versa, as described.

Moreover, for example, based on the timing request at <NUM> or otherwise, interface controller driver <NUM> can optionally notify the application <NUM> of timing information based on certain events. For example, interface controller driver <NUM> can notify the application <NUM> of updated timing information, at each frame start <NUM>, at <NUM>. In another example, interface controller driver <NUM> can additionally or alternatively notify the application <NUM> of updated timing information, at one or more microframe starts <NUM>, at <NUM>. In yet another example, interface controller driver <NUM> can notify the application <NUM> of updated timing information when the interface clock overflows. In any case, application <NUM> can optionally deregister the API at <NUM> (e.g., upon termination of the application <NUM> or otherwise determining that timing synchronization is no longer needed, and the interface controller driver <NUM> can optionally request, from the interface controller <NUM>, termination of receiving the synchronization interrupts at <NUM>.

<FIG> illustrates an example of device <NUM>, similar to or the same as device <NUM> (<FIG>), including additional optional component details as those shown in <FIG>. In one implementation, device <NUM> may include processor <NUM>, which may be similar to processor <NUM> for carrying out processing functions associated with one or more of components and functions described herein. Processor <NUM> can include a single or multiple set of processors or multi-core processors. Moreover, processor <NUM> can be implemented as an integrated processing system and/or a distributed processing system.

Device <NUM> may further include memory <NUM>, which may be similar to memory <NUM> such as for storing local versions of applications being executed by processor <NUM>, such as timing source synchronizing component <NUM>, applications, related instructions, parameters, etc. Memory <NUM> can include a type of memory usable by a computer, such as random access memory (RAM), read only memory (ROM), tapes, magnetic discs, optical discs, volatile memory, non-volatile memory, and any combination thereof.

Further, device <NUM> may include a communications component <NUM> that provides for establishing and maintaining communications with one or more other devices, parties, entities, etc., utilizing hardware, software, and services as described herein. Communications component <NUM> may carry communications between components on device <NUM>, as well as between device <NUM> and external devices, such as devices located across a communications network and/or devices serially or locally connected to device <NUM>. For example, communications component <NUM> may include one or more buses, and may further include transmit chain components and receive chain components associated with a wireless or wired transmitter and receiver, respectively, operable for interfacing with external devices.

Additionally, device <NUM> may include a data store <NUM>, which can be any suitable combination of hardware and/or software, that provides for mass storage of information, databases, and programs employed in connection with implementations described herein. For example, data store <NUM> may be or may include a data repository for applications and/or related parameters (e.g., timing source synchronizing component <NUM>, applications, etc.) not currently being executed by processor <NUM>. In addition, data store <NUM> may be a data repository for timing source synchronizing component <NUM>, applications, and/or one or more other components of the device <NUM>.

Device <NUM> may optionally include a user interface component <NUM> operable to receive inputs from a user of device <NUM> and further operable to generate outputs for presentation to the user. User interface component <NUM> may include one or more input devices, including but not limited to a keyboard, a number pad, a mouse, a touch-sensitive display, a navigation key, a function key, a microphone, a voice recognition component, a gesture recognition component, a depth sensor, a gaze tracking sensor, a switch/button, any other mechanism capable of receiving an input from a user, or any combination thereof. Further, user interface component <NUM> may include one or more output devices, including but not limited to a display, a speaker, a haptic feedback mechanism, a printer, any other mechanism capable of presenting an output to a user, or any combination thereof.

Device <NUM> may additionally include timing source synchronizing component <NUM> for synchronizing timing among multiple timing sources related to the device <NUM>, such to facilitate association of time-occurring events in the same or similar time domain.

Accordingly, in one or more implementations, one or more of the functions described may be implemented in hardware, software, firmware, or any combination thereof. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), and floppy disk where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.

Claim 1:
A method (<NUM>) for synchronizing multiple timing sources in a computing device (<NUM>, <NUM>), comprising:
maintaining (<NUM>), by the computing device, at least a first clock (<NUM>) associated with a first timing source and a second clock (<NUM>) associated with a second timing source;
receiving (<NUM>), from an application (<NUM>), a request for an indication of a timing difference between the first clock and the second clock, the request being issued by the application (<NUM>) based at least in part on comparing a processing load to a threshold or an operating/ambient temperature to a threshold;
determining (<NUM>), by the computing device and at an instance of a reoccurring event in a domain of one of the first timing source or the second timing source, a first elapsed time of the first clock and a second elapsed time of the second clock from a previous instance of the reoccurring event, wherein the reoccurring event relates to a register overflow of a value of the first clock or the second clock; and
providing (<NUM>), to the application and in response to the request, the indication related to the first elapsed time and the second elapsed time.