English:
[0001] Many computing devices employ input devices, such as sensors (e.g., inertial sensors, camera sensors, etc.) that produce output streams for consumption by applications operating on the computing device. The sensors can include or otherwise utilize a timing source to operate a clock for providing timing information of captured data. The timing sources among the input devices and/or the computing device (e.g., of a central processing unit (CPU) or other processor in the computing device), however, may not be the same, and thus may not always be synchronized and/or may experience drift from one another as time goes on. For certain types of devices and/or associated applications, high synchronization between peripheral devices and/or the CPU may be desirable to attain a certain level of user experience, such as in virtual reality, mixed reality, autonomous driving, or similar applications.
[0002] 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.
[0003] In an example, a method for synchronizing multiple timing sources in a computing device is provided. The method includes maintaining, by the computing device, at least a first clock associated with a first timing source and a second clock associated with a second timing source, receiving, from an application, a request for an indication of a difference in values between the first clock and the second clock, determining, 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 an event, and providing, to the application, an indication related to the first elapsed time and the second elapsed time.
[0004] In another example, a device for synchronizing multiple timing sources is provided. The device includes a memory storing one or more parameters or instructions for maintaining multiple timing sources, and at least one processor coupled to the memory. The at least one processor is configured to maintain at least a first clock associated with a first timing source and a second clock associated with a second timing source, receive, from an application, a request for an indication of a difference in values between the first clock and the second clock, determine, 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 an event, and provide, to the application, an indication related to the first elapsed time and the second elapsed time.
[0005] In another example, a computer-readable medium including code executable by one or more processors for synchronizing multiple timing sources in a computing device is provided. The code includes code for maintaining, by the computing device, at least a first clock associated with a first timing source and a second clock associated with a second timing source, receiving, from an application, a request for an indication of a difference in values between the first clock and the second clock, determining, 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 an event, and providing, to the application, an indication related to the first elapsed time and the second elapsed time.
[0007] Figure 1 is a schematic diagram of an example of a device for synchronizing timing among multiple timing sources in accordance with examples described herein.
[0008] Figure 2 is a flow diagram of an example of a method for synchronizing timing among multiple timing sources in accordance with examples described herein.
[0009] Figure 3 is an example of a message flow diagram for synchronizing timing among multiple timing sources and providing timing information in accordance with examples described herein.
[0010] Figure 4 is a schematic diagram of an example of a device for performing functions described herein.
[0011] The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known components are shown in block diagram form in order to avoid obscuring such concepts.
[0012] 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.
[0013] 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.
[0014] Turning now to Figures 1-3, 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 Figure 2 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.
[0015] Figure 1 is a schematic diagram of an example of a device 100 (e.g., a computing device) that can synchronize timing among multiple timing sources. In an example, device 100 can include a processor 102 and/or memory 104 configured to execute or store instructions or other parameters related to providing an operating system 108, which can provide an environment for executing one or more applications 110, etc. For example, processor 102 and memory 104 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 102 can include the memory 104 as an on-board component 101), and/or the like. Memory 104 may store instructions, parameters, data structures, etc., for use/execution by processor 102 to perform functions described herein. Device 100 can also include one or more input devices 112, 114 that can be integrated within device 100, attached as a peripheral to the device 100 (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 112, 114 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 100.
[0016] In an example, device 100 can provide an interface controller 116 over which input devices 112, 114 can communicate with other components of the device 100, such as operating system 108, applications 110, etc. to provide data received from the input device. For example, operating system 108 can provide an interface controller driver 118, which can be a user mode driver, to facilitate communication between the interface controller 116 and the operating system 108 to receive and/or transmit data from/to the input devices 112, 114. In an example, the interface controller 1 16 can be a USB controller configured to communicate with one or more input devices 112, 114 via a USB interface. The USB controller can receive data from the input devices 112, 114 in a format for communicating over USB, and can provide corresponding data to the interface controller driver 118. Operating system 108, and/or application 110, can access the data from the input devices 112, 114 via the interface controller driver 118 communicating with interface controller 116. In other examples, interface controller 116 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 118.
[0017] For example, processor 102 (or another component of the device 100) can maintain a timing source in the form of a host clock 120, which can provide a clock used in executing instructions on the processor 102 (e.g., a CPU clock). For example, the host clock 120 can track time using a first granularity (e.g., a number of hertz (Hz)). In addition, in an example, the operating system 108 may access the host clock 120, and can provide an interface to host clock 120 values via a query performance counter (QPC) function. The interface controller 116, in an example, can also maintain a timing source in the form of an interface clock 122 for timestamping data received from the input devices 112, 114. The interface clock 122 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 120 and interface clock 122 may operate using a similar bus speed in theory, but the clocks 120, 122 may actually drift (e.g., at different rates) over time due to a variety of factors. For example, the interface clock 122 may be implemented in different hardware than the host clock 120, and each clock 120, 122 or related hardware may have properties that result in the clocks 120, 122 tracking time differently. In one example, silicon used to provide the processor 102 and/or interface controller 116 may be different, which may cause the clocks 120, 122 to drift. In another example, operating or ambient temperature may be different, which may cause the clocks to drift. Moreover, the clocks 120, 122 may not initialize to the same initial time value. Accordingly, the host clock 120 and interface clock 122 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.
[0018] Accordingly, interface controller driver 118 (and/or another component of the operating system 108) may include a timing source synchronizing component 124 for applying a synchronization to clock values of different timing sources, such to allow the operating system 108 and/or one or more applications 110 to resolve the clock values of the timing sources with respect to one another. For example, in applying the synchronization, the timing source synchronizing component 124 can provide clock values of the host clock 120, interface clock 122 (and/or other clocks) at a particular instant in time, which may correspond to a reoccurring event in the domain of the host clock 120 or interface clock 122. In another example, the timing source synchronizing component 124 can additionally or alternatively provide other information regarding the timing difference between host clock 120 and interface clock 122, 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 120 and/or the interface clock 122, etc.), a prediction of accuracy of the reported clock drift, and/or the like. Operating system 108 and/or one or more applications 110 can use this information to resolve a clock value of interface clock 122 in the domain of host clock 120, and/or vice versa (and/or resolve other clock values of one domain in another domain). This can enable the operating system 108 and/or one or more applications 110 to correlate data received from multiple input devices via the interface controller 116 (and/or via one or more other interface controllers, not shown) and/or data associated with the operating system 108 and/or application(s) 110, etc.
[0019] Figure 2 is a flowchart of an example of a method 200 for synchronizing multiple timing sources in a computing device. For example, method 200 can be performed by a device 100 and/or one or more components thereof to facilitate synchronizing timing values received from a host clock 120, interface clock 122, and/or other clocks.
[0021] In an example, as described, processor 102 may maintain host clock 120 as a CPU clock based on a number of pulses per second that can be measured in Hz. In addition, for example, interface controller 116 may maintain interface clock 122 as a USB clock for tracking a number of USB frames, occurring every 1 millisecond (ms), and a number of USB microframes within each USB frame, which occur every 125 microseconds (us). The host clock 120 and interface clock 122 may not always be synchronized based on being provided by different hardware, at environments with different ambient temperatures within the device 100, etc. Based on this and/or based on the fact that the clocks 120, 122 operate using different granularities, the device 100 may benefit from a synchronization of the clocks 120, 122 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.
[0022] In method 200, at action 204, 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 118, e.g., in conjunction with processor 102, memory 104, operating system 108, etc., can receive the request (e.g., from an application 110) for the indication of the difference in values between the first clock (e.g., host clock 120) and the second clock (e.g., interface clock 122). In one example, the application 110 can issue the request to the timing source synchronizing component 124 based on the application 110 initializing a module for receiving data from the one or more input devices 112, 114 via interface controller 116. In another example, the application 110 can issue 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 124 does not cause undesirable load on the processor 102. 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 (e.g., occurring based on one or more detectable events, such as a clock overflow, as described further herein).
[0023] In method 200, at action 206, 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 124, e.g., in conjunction with processor 102, memory 104, operating system 108, etc., can determine, at the instance of the reoccurring event in the domain of the one of the first timing source (e.g., processor 102) or the second timing source (e.g. interface controller 116), 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 120 and/or interface clock 122, a previous instance of the reoccurring event, and/or the like. In addition, in an example, the reoccurring event may correspond to a clock overflow of the host clock 120 and/or interface clock 122.
[0024] In a specific example, the interface controller 116 may be a USB controller, and the interface clock 122 may accordingly report time to the operating system 108 through a register (MFINDEX) with 14 bits for the elapsed USB micro frames, where 11 bits are used for elapsed 1 ms frames and 3 bits are used for elapsed 125 us microframes within the given 1 ms frame. Accordingly, the interface clock 122 for USB can report clock values up to 2048 ms at a granularity of 125 us. In this example, the reoccurring event can correspond to an interrupt received when the MFINDEX register overflows (e.g., and resets the interface clock 122, which can occur every 2048 ms in the interface clock 122 domain). In this example, the timing source synchronizing component 124 can continuously determine an elapsed time of the host clock 120 every 2048 ms in the interface clock 122 domain, based on occurrence of the MFINDEX register overflow, to determine the clock drift between the host clock 120 and the interface clock 122. For example, where timing source synchronizing component 124 determines that the host clock 120 elapses 2200 ms between instances of the reoccurring event (e.g., when the interface clock 122 elapses 2048 ms), the timing source synchronizing component 124 can determine that the interface clock 122 is around 2200 / 2048 = 7.42% faster than the host clock 120. Accordingly, after the start of a new frame, the timing source synchronizing component 124 can expect the next microframe to occur at 125 us * 107.42% = 134.27 us, the second microframe to start at 268.55 us, the third microframe to start at 402.83 us, etc., in the host clock 120 domain. In an example, timing source synchronizing component 124 can provide the difference in values of the clocks 120,
[0025] In method 200, optionally at action 208, 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 124, e.g., in conjunction with processor 102, memory 104, operating system 108, 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 124 can determine the first elapsed time of the first clock (e.g., host clock 120) between two instants in time and the second elapsed time of the second clock (e.g., interface clock 122) 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 124 can determine this clock drift at each instance of the reoccurring event, as described. Moreover, for example, timing source synchronizing component 124 can report the clock drift to operating system 108 (or one or more components thereof), one or more applications 110, etc. periodically and/or based on request.
[0026] In method 200, optionally at action 210, 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 124, e.g., in conjunction with processor 102, memory 104, operating system 108, 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 124, 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 124 can apply the clock drift, determined in the domain of the host clock 120, to a time of a past event occurring in the domain of the interface clock 122, and can compare the result to the actual time of the event in the domain of the interface clock 122 to determine the accuracy. For example, timing source synchronizing component 124 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 124 to indicate the accuracy when providing an indication of clock values, clock drift, etc., as described herein.
[0027] In method 200, optionally at action 212, an accuracy of the predicted time can be determined. In an example, timing source synchronizing component 124, e.g., in conjunction with processor 102, memory 104, operating system 108, etc., can determine the accuracy of the predicted time. For example, timing source synchronizing component 124 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., 125 us). In an example, however, the request received at action 204 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 122 is for USB, timing source synchronizing component 124 can determine the first elapsed time and second elapsed time at an edge of the interface clock 122 (e.g., at a beginning of a USB frame of 1 ms or a beginning of a USB microframe at 125 us). In this example, timing source synchronizing component 124 can determine (and indicate, e.g., as part of the indication in action 214 below) an accuracy corresponding to the granularity of the host clock 120 (e.g., on the order of tens or hundreds of nanoseconds for a QPC).
[0028] In method 200, at action 214, an indication related to the first elapsed time and the second elapsed time can be provided. In an example, timing source synchronizing component 124, e.g., in conjunction with processor 102, memory 104, operating system 108, etc., can provide the indication related to the first elapsed time and the second elapsed time. For example, timing source synchronizing component 124 can provide the indication to the application 1 10, which can have requested the indication (e.g., at action 204). In addition, timing source synchronizing component 124 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 124 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 124 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.
[0029] In one example, timing source synchronizing component 124 can autonomously (and/or based on an initial request) manage synchronizing of the clocks 120, 122, 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 124 may provide the current indication of the first and/or second elapsed time, clock drift, accuracy, etc. upon request.
[0030] The examples described above can allow for sufficiently accurate and power- efficient synchronization between the time derived from the processor 102 clock and the interface clock 122 (e.g., USB bus time derived from the USB controller clock). For example, the application 110 can query an application programming interface (API) that can be exposed by the interface controller driver 118 (e.g., the USB driver stack in the operating system 108) that maps to the QPC values, which can be tracked by the operating system 108 and can correspond to a timing of the host clock 120, to the interface (e.g., USB) frame and microframes tracked by the interface controller 116 (e.g., USB host controller hardware). This can allow the application 110 to synchronize its own functions, which can operate on the processor 102 and thus correspond to the timing of the host clock 120, with the data provided by the devices on the interface controller 116 (e.g., USB bus), which can correspond to the timing of the interface clock 122. For example, the API exposed by the interface controller driver 118 can allow application 110 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 118 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 110 upon request. In addition, for example, the API can allow the application 110 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 124 can detect and use to determine to record the corresponding QPC). Moreover, in an example, the API can allow the application 110 to get the predicted accuracy of the QPC value, as described.
[0031] In a specific example, device 100 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 112, 114 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 102 of the HMD device) via a USB bus. In this example, an application 110 executing to provide the virtual reality/mixed reality experience can obtain data from the various input devices 112, 114, 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 110 may be desirable (e.g., to match inertial measurements with corresponding captured images, etc.). The interface controller 116 can receive the data from the various input devices 112, 114 with timestamps (e.g., based on clocks in the input devices 112, 114, the interface clock 122, such as a USB clock, etc.) and/or may perform the timestamping as the input data is received.
[0032] In this example, the application 110 can resolve the timestamps from the interface clock 122 to corresponding time values of the host clock 120. In one example, the application 110 can request and/or periodically receive, from the timing source synchronizing component 124, the interface clock 122 value (e.g., frame and/or microframes) and the host clock 120 value (e.g., QPC value) at the same or similar instant in time. Timing source synchronizing component 124 can compute (e.g., on request) or otherwise maintain (e.g., and report on request) the clock drift between the values of the clocks 120, 122. In this example, application 110 can resolve the timestamps by applying the currently maintained clock drift thereto. In another example, application 110 can request, from the timing source synchronizing component 124, the host clock 120 value corresponding to a previous interface clock 122 value, which application 110 can indicate in the request, and timing source synchronizing component 124 can predict the previous time, as described above, and/or may return a computed accuracy for the predicted time. In yet another example, application 110 can request and/or periodically receive, from the timing source synchronizing component 124, the determined clock drift amount, which the application 110 can apply to received interface clock 122 values to resolve the corresponding host clock 120 value. In any case, application 110 can determine the host clock 120 value corresponding to input data received from input devices 112, 114 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 110), synchronizing the received data with operations of the application 110, and/or the like.
[0033] Figure 3 illustrates an example of a message flow diagram 300 for indicating synchronization information for multiple timing sources in accordance with examples described herein. Message flow diagram 300 shows an application 110 that can communicate with an interface controller driver 118 to obtain synchronization information for multiple clocks, and an interface controller 116 that can maintain a clock for an interface (e.g., a USB interface). In one example, application 110 can optionally send an API registration to the interface controller driver 118 at 302, which can allow the application 110 to request use of the interface controller driver 118 to communicate with the interface controller 116, and/or more specifically, to receive timing synchronization information from the interface controller driver 118. In response or otherwise, interface controller driver 118 can optionally send a request synchronization start command to the interface controller 116 at 302, which can cause the interface controller 116 to provide or call interrupts on the interface controller driver 118 to notify the interface controller driver 118 of one or more timing-related events. Starting the interrupts when the API registration is sent at 302 can allow for minimizing interruptions to the device where the synchronization functionality is not needed. For example, interface controller 116 can call a callback function on the interface controller driver 118, or otherwise notify the interface controller driver 118 of the timing-related event, which may include interface controller 116 notifying the interface controller driver 118 when a new frame starts, when a new microframe starts, and/or the like.
[0034] For example, interface controller 116 can maintain a clock (e.g., interface clock 122) that can track frames and/or microframes over the interface for communicating with one or more input devices. Where the interface controller 116 is a USB controller, as described above, the frames can occur every 1 ms and the microframes can occur every 125us within each 1 ms frame. In any case, interface controller 116 can notify the interface controller driver 118 of each frame by sending a frame start notification to the interface controller driver 118 at 306. Interface controller driver 118 can store the frame, microframe, and/or a QPC (e.g., in a memory, such as memory 104) based on receiving the frame start at 308. For example, interface controller driver 118 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 120 of processor 102, etc.). In another example, interface controller 116 can optionally also notify the interface controller driver 118 of each microframe start at 310, and/or the interface controller driver 118 can similarly store the frame, microframe, and/or QPC at 312. In yet another example, interface controller 116 can notify the interface controller driver 118 each time the interface clock overflows, as described.
[0036] Moreover, for example, based on the timing request at 314 or otherwise, interface controller driver 118 can optionally notify the application 1 10 of timing information based on certain events. For example, interface controller driver 118 can notify the application 110 of updated timing information, at each frame start 318, at 320. In another example, interface controller driver 118 can additionally or alternatively notify the application 110 of updated timing information, at one or more microframe starts 322, at 324. In yet another example, interface controller driver 118 can notify the application 110 of updated timing information when the interface clock overflows. In any case, application 110 can optionally deregister the API at 326 (e.g., upon termination of the application 110 or otherwise determining that timing synchronization is no longer needed, and the interface controller driver 118 can optionally request, from the interface controller 116, termination of receiving the synchronization interrupts at 328.
[0037] Figure 4 illustrates an example of device 400, similar to or the same as device 100 (Figure 1), including additional optional component details as those shown in Figure 1. In one implementation, device 400 may include processor 402, which may be similar to processor 102 for carrying out processing functions associated with one or more of components and functions described herein. Processor 402 can include a single or multiple set of processors or multi-core processors. Moreover, processor 402 can be implemented as an integrated processing system and/or a distributed processing system.
[0038] Device 400 may further include memory 404, which may be similar to memory 104 such as for storing local versions of applications being executed by processor 402, such as timing source synchronizing component 124, applications, related instructions, parameters, etc. Memory 404 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.
[0039] Further, device 400 may include a communications component 406 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 406 may carry communications between components on device 400, as well as between device 400 and external devices, such as devices located across a communications network and/or devices serially or locally connected to device 400. For example, communications component 406 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.
[0040] Additionally, device 400 may include a data store 408, 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 408 may be or may include a data repository for applications and/or related parameters (e.g., timing source synchronizing component 124, applications, etc.) not currently being executed by processor 402. In addition, data store 408 may be a data repository for timing source synchronizing component 124, applications, and/or one or more other components of the device 400.
[0041] Device 400 may optionally include a user interface component 410 operable to receive inputs from a user of device 400 and further operable to generate outputs for presentation to the user. User interface component 410 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 410 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.
[0042] Device 400 may additionally include timing source synchronizing component 124 for synchronizing timing among multiple timing sources related to the device 400, such to facilitate association of time-occurring events in the same or similar time domain.
[0043] By way of example, an element, or any portion of an element, or any combination of elements may be implemented with a "processing system" that includes one or more processors. Examples of processors include microprocessors, microcontrollers, digital signal processors (DSPs), field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this disclosure. One or more processors in the processing system may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.
[0044] Accordingly, in one or more implementations, one or more of the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. Storage media may be any available media that can be accessed by a computer. 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. Combinations of the above should also be included within the scope of computer-readable media.
[0045] The previous description is provided to enable any person skilled in the art to practice the various implementations described herein. Various modifications to these implementations will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other implementations. Thus, the claims are not intended to be limited to the implementations shown herein, but are to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean "one and only one" unless specifically so stated, but rather "one or more." Unless specifically stated otherwise, the term "some" refers to one or more. All structural and functional equivalents to the elements of the various implementations described herein that are known or later come to be known to those of ordinary skill in the art are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element is to be construed as a means plus function unless the element is expressly recited using the phrase "means for."

中文:
[0001]许多计算设备采用诸如传感器(例如,惯性传感器、相机传感器等)等输入设备,这些输入设备产生输出流以供在计算设备上操作的应用消耗。传感器可以包括或以其他方式利用定时源来操作时钟以提供所捕获的数据的定时信息。然而,(例如,中央处理单元(CPU)或计算设备中的其他处理器的)输入设备和/或计算设备之间的定时源可能不相同,并且因此可能并不总是同步和/或随着时间的推移可能会彼此漂移。对于某些类型的设备和/或相关联的应用,可能需要外围设备和/或CPU之间的高度同步以获取某种级别的用户体验,诸如在虚拟现实、混合现实、自动驾驶或类似应用中。
[0002]以下给出了对一个或多个实施例的简化概述以便提供对这样的实施例的基本理解。该概述不是所有预期实施例的详尽概述,并且既不旨在标识所有实施例的关键或重要元素,也不旨在界定任何或所有实施例的范围。其唯一目的是以简化的形式呈现一个或多个实施例的某些概念,作为稍后呈现的更详细描述的序言。
[0003]在一个示例中,提供了一种用于使计算设备中的多个定时源同步的方法。该方法包括:由计算设备至少维持与第一定时源相关联的第一时钟和与第二定时源相关联的第二时钟,从应用接收针对第一时钟与第二时钟之间的值差的指示的请求,由计算设备在第一定时源或第二定时源中的一个定时源的域中的重复事件(reoccurring event)的实例确定自从事件的先前实例以来第一时钟的第一经过时间和第二时钟的第二经过时间,以及向应用提供与第一经过时间和第二经过时间相关的指示。
[0004]在另一示例中,提供了一种用于使多个定时源同步的设备。该设备包括:存储用于维持多个定时源的一个或多个参数或指令的存储器、以及耦合到存储器的至少一个处理器。至少一个处理器被配置为至少维持与第一定时源相关联的第一时钟和与第二定时源相关联的第二时钟,从应用接收针对第一时钟与第二时钟之间的值差的指示的请求,在第一定时源或第二定时源中的一个定时源的域中的重复事件的实例确定自从事件的先前实例以来第一时钟的第一经过时间和第二时钟的第二经过时间,以及向应用提供与第一经过时间和第二经过时间相关的指示。
[0005]在另一示例中,提供了一种计算机可读介质,该计算机可读介质包括由一个或多个处理器可执行的用于使计算设备中的多个定时源同步的代码。该代码包括用于以下各项的代码:由计算设备至少维持与第一定时源相关联的第一时钟和与第二定时源相关联的第二时钟,从应用接收针对第一时钟与第二时钟之间的值差的指示的请求,由计算设备在第一定时源或第二定时源中的一个定时源的域中的重复事件的实例确定自从事件的先前实例以来第一时钟的第一经过时间和第二时钟的第二经过时间,以及向应用提供与第一经过时间和第二经过时间相关的指示。
[0007]图1是根据本文中描述的示例的用于在多个定时源之间使定时同步的设备的示例的示意图。
[0008]图2是根据本文中描述的示例的用于在多个定时源之间使定时同步的方法的示例的流程图。
[0009]图3是根据本文中描述的示例的用于在多个定时源之间使定时同步并且提供定时信息的消息流程图的示例。
[0010]图4是用于执行本文中描述的功能的设备的示例的示意图。
[0011]下面结合附图阐述的详细描述旨在作为对各种配置的描述,而非旨在表示可以实践本文中描述的概念的唯一配置。详细描述包括特定细节以提供对各种概念的透彻理解。然而,对于本领域技术人员将很清楚的是,可以在没有这些具体细节的情况下实践这些概念。在某些情况下,以框图形式示出了众所周知的组件,以避免使这样的概念模糊。
[0012]本公开描述了与在计算设备中的多个定时源之间使定时同步相关的各种示例,这可以促进从多个源获取的数据的关联,尽管可以基于不同的定时源对数据加时间戳(或以其他方式与时间相关联)。例如,在计算设备操作多个定时源的情况下,可以与第二定时源的第二时钟值分别地或者以其他方式与第二定时源的第二时钟值进行比较地确定第一定时源的第一时钟值。在一个示例中,第一时钟值和第二时钟值可以对应于在已知事件之间(诸如在重复事件的实例之间,在事件的初始化与实例之间,等等)第一定时源和第二定时源的经过时间值。经过时间值之间的差可以提供定时源之间的时钟漂移的指示(例如,从已知事件中测量的)。可以将时钟漂移或第一时钟值与第二时钟值之间的其他差的指示提供给一个或多个应用以允许应用在定时源之间使定时同步。
[0013]在特定示例中,应用可以从具有关联时间戳的输入设备接收数据,该关联时间戳使用与该输入设备相关联的定时源。例如,该定时源可以是输入设备本身的定时源、将输入设备与计算设备接口的对应接口控制器的定时源等。应用可以从操作系统请求同步信息,其可以包括与接口控制器相关联的定时源的当前帧的时钟值、以及接口控制器的当前帧的(例如,中央处理器(CPU)或计算设备的其他处理器的)计算设备的主机时钟值。应用可以使用时钟值和主机时钟值来确定与来自输入设备的数据的时间戳相关联的主机时钟值。在另一示例中,同步信息可以包括时钟漂移信息,应用还可以应用该时钟漂移信息来确定与来自发生时钟漂移的输入设备的数据的时间戳相关联的更准确的主机时钟值。
[0014]现在转到图1-3,参考可以执行本文中描述的动作或操作的一个或多个组件和一种或多种方法来描绘示例,其中虚线中的组件和/或动作/操作可以是可选的。尽管下面在图2中描述的操作以特定顺序和/或由示例组件执行,但是在一些示例中,取决于实现,可以改变动作的顺序和执行动作的组件。而且,在一些示例中,动作、功能和/或所描述的组件中的一个或多个可以由专门编程的处理器、执行专门编程的软件或计算机可读介质的处理器、或者能够执行所描述的动作或功能的硬件组件和/或软件组件的任何其他组合来执行。
[0015]图1是可以在多个定时源之间使定时同步的设备100(例如,计算设备)的示例的示意图。在一个示例中,设备100可以包括被配置为执行或存储与提供操作系统108相关的指令或其他参数的处理器102和/或存储器104,该操作系统108可以提供用于执行一个或多个应用110等的环境。处理器102和存储器104可以是通过总线(例如,在母板或计算设备的其他部分上,在集成电路上,诸如片上系统(SoC)等)通信耦合的单独组件、集成在彼此之内的组件(例如,处理器102可以包括存储器104作为板载组件101)等。存储器104可以存储指令、参数、数据结构等以供处理器102使用/执行以执行本文中描述的功能。设备100还可以包括一个或多个输入设备112、114,输入设备可以集成在设备100中,作为外围设备附接到设备100(例如,经由一个或多个有线或无线接口(例如,通用串行总线(USB)、火线、局域网(LAN)、无线LAN(WLAN)、Bluetooth、射频识别(RFID)、近场通信(NFC)等),等等。例如,一个或多个输入设备112、114可以包括用于接收和/或处理意图用于设备100的输入数据的一个或多个传感器设备,传感器设备可以包括惯性传感器(例如,加速度计、陀螺仪等)、图像传感器(例如,红、绿、蓝(RGB)相机、红外(IR)相机、深度相机等)(其可以是视频相机、静止图像相机等)、眼睛扫描或眼睛跟踪传感器、指纹或触摸传感器、麦克风等。
[0016]在一个示例中,设备100可以提供接口控制器116,输入设备112、114可以通过该接口控制器116与设备100的其他组件(诸如操作系统108、应用110等)通信以提供从输入设备接收的数据。例如,操作系统108可以提供接口控制器驱动器118(其可以是用户模式驱动器)以促进接口控制器116与操作系统108之间的通信以从/向输入设备112、114接收和/或传输数据。在一个示例中,接口控制器116可以是被配置为经由USB接口与一个或多个输入设备112、114通信的USB控制器。USB控制器可以以用于通过USB进行通信的格式从输入设备112、114接收数据,并且可以向接口控制器驱动器118提供对应的数据。操作系统108和/或应用110可以经由与接口控制器116通信的接口控制器驱动器118从输入设备112、114访问数据。在其他示例中,接口控制器116可以包括火线、LAN、WLAN、Bluetooth、RFID、NFC、或者被配置用于经由有线或无线接口进行通信的基本上任何控制器,并且可以具有对应的接口控制器驱动器118。
[0017]例如,处理器102(或设备100的另一组件)可以以主机时钟120的形式维持定时源,该主机时钟120可以提供用于在处理器102上执行指令的时钟(例如,CPU时钟)。例如,主机时钟120可以使用第一粒度(例如,赫兹数(Hz))来跟踪时间。另外,在一个示例中,操作系统108可以访问主机时钟120,并且可以经由查询性能计数器(QPC)功能来提供与主机时钟120值的接口。在一个示例中,接口控制器116还可以维持接口时钟122形式的定时源以用于对从输入设备112、114接收的数据加时间戳。接口时钟122可以使用第二粒度(例如,Hz数)(其可以与第一粒度不同)来跟踪时间。在一个示例中,理论上,主机时钟120和接口时钟122可以使用类似的总线速度操作,但是由于各种因素,时钟120、122实际上可以随着时间漂移(例如,以不同的速率)。例如,接口时钟122可以用与主机时钟120不同的硬件而被实现,并且每个时钟120、122或相关硬件可以具有导致时钟120、122以不同的方式跟踪时间的属性。在一个示例中,用于提供处理器102和/或接口控制器116的硅可以不同,这可能导致时钟120、122发生漂移。在另一示例中,操作温度或环境温度可以不同,这可能导致时钟发生漂移。此外,时钟120、122可以未初始化为相同的初始时间值。因此,主机时钟120和接口时钟122可能未被同步,并且因此它们在任何给定时间的时钟值可能随着时间而不同和/或以不同的速率(漂移)而不同。
[0018]因此,接口控制器驱动器118(和/或操作系统108的另一组件)可以包括定时源同步组件124,该定时源同步组件124用于将同步应用于不同定时源的时钟值,从而允许操作系统108和/或一个或多个应用110相对于彼此解析定时源的时钟值。例如,在应用同步时,定时源同步组件124可以在特定的时刻提供主机时钟120、接口时钟122(和/或其他时钟)的时钟值,这可以对应于主机时钟120或接口时钟122的域中的重复事件。在另一示例中,附加地或备选地,定时源同步组件124可以提供关于主机时钟120与接口时钟122之间的定时差的其他信息,诸如在当前时刻的差值、相对于先前时刻的在该时刻测量的时钟漂移(例如,重复事件的先前实例的时间、主机时钟120和/或接口时钟122的初始化的时间等)、所报告的时钟漂移的准确性的预测等。操作系统108和/或一个或多个应用110可以使用该信息来在主机时钟120的域中解析接口时钟122的时钟值,和/或反之亦然(和/或在另一域中解析一个域的其他时钟值)。这可以使得操作系统108和/或一个或多个应用110能够将经由接口控制器116(和/或经由一个或多个其他接口控制器,未示出)从多个输入设备接收的数据和/或与操作系统108和/或应用110相关联的数据等进行关联。
[0019]图2是用于使计算设备中的多个定时源同步的方法200的示例的流程图。例如,方法200可以由设备100和/或其一个或多个组件执行以促进使从主机时钟120、接口时钟122和/或其他时钟接收的定时值同步。
[0021]在一个示例中,如上所述,处理器102可以基于可以以Hz为单位进行测量的每秒脉冲数来将主机时钟120维持为CPU时钟。另外,例如,接口控制器116可以将接口时钟122维持为USB时钟以跟踪每1毫秒(ms)出现的USB帧数以及每125微秒(μs)出现的每个USB帧内的USB微帧数。主机时钟120和接口时钟122可能并不总是基于由不同硬件提供,在设备100内具有不同环境温度的环境下等等被同步。基于此和/或基于时钟120、122使用不同粒度操作的这一事实,设备100可以受益于使用所提供的指示在一个或多个时刻将一个时钟的值与另一时钟的值进行匹配而实现的时钟120、122的同步。本文中描述了用于实现这样的同步的机制。
[0022]在方法200中,在动作204处,可以接收针对第一时钟与第二时钟之间的值差到指示的请求。在一个示例中,接口控制器驱动器118(例如,与处理器102、存储器104、操作系统108等相结合)可以接收(例如,从应用110)针对第一时钟(例如,主机时钟120)与第二时钟(例如,接口时钟122)之间的值差的指示的请求。在一个示例中,应用110可以基于应用110初始化用于经由接口控制器116从一个或多个输入设备112、114接收数据的模块来向定时源同步组件124发出请求。在另一示例中,应用110可以至少部分基于将处理负载与阈值进行比较或者将操作/环境温度与阈值进行比较来发出请求,以确保由定时源同步组件124执行的附加处理不会在处理器102上造成不期望的负载。另外,例如,请求可以对应于对差的单个指示的请求,该请求可以以ms、μs等的数目而被测量。在另一示例中,请求可以对应于接收差的多个指示的请求(例如,如本文中进一步所述,基于一个或多个可检测事件(诸如时钟溢出)而发生)。
[0023]在方法200中,在动作206处,可以在第一定时源或第二定时源中的一个定时源的域中的重复事件的实例确定自从事件的先前实例以来第一时钟的第一经过时间和第二时钟的第二经过时间。在一个示例中,定时源同步组件124(例如,与处理器102、存储器104、操作系统108等相结合)可以在第一定时源(例如,处理器102)或第二定时源(例如,接口控制器116)中的一个定时源的域中的重复事件的实例确定自从事件的先前实例以来第一时钟的第一经过时间和第二时钟的第二经过时间。例如,事件的先前实例可以对应于主机时钟120和/或接口时钟122的初始化、重复事件的先前实例等。另外,在一个示例中,重复事件可以对应于主机时钟120和/或接口时钟122的时钟溢出。
[0024]在特定示例中,接口控制器116可以是USB控制器,并且接口时钟122可以相应地通过寄存器(MFINDEX)向操作系统108报告时间,该寄存器具有14位用于经过的USB微帧,其中在给定的1ms帧内,11位用于经过的1ms帧,而3位用于经过的125μs微帧。因此,用于USB的接口时钟122可以以125μs的粒度报告高达2048ms的时钟值。在该示例中,重复事件可以对应于当MFINDEX寄存器溢出(例如,并且重置接口时钟122,这可以在接口时钟122域中每2048ms发生一次)时接收的中断。在该示例中,定时源同步组件124可以基于MFINDEX寄存器溢出的发生来在接口时钟122域中每2048ms连续地确定主机时钟120的经过时间,以确定主机时钟120与接口时钟122之间的时钟漂移。例如,在定时源同步组件124确定主机时钟120在重复事件的实例之间经过了2200ms的情况下(例如,当接口时钟122经过2048ms时),定时源同步组件124可以确定接口时钟122比主机时钟120快大约2200/2048=7.42%。因此,在新帧开始之后,定时源同步组件124可以期望在主机时钟120域中:下一微帧出现在125μs*107.42%=134.27μs,第二微帧开始于268.55μs,第三微帧开始于402.83μs,以此类推。在一个示例中,定时源同步组件124可以提供时钟120、122的值的差、所计算出的时钟漂移(例如,作为百分比和/或应用于时钟值之一)等。
[0025]在方法200中,可选地,在动作208处,可以基于第一经过时间与第二经过时间之间的差来计算时钟漂移。在一个示例中,定时源同步组件124(例如,与处理器102、存储器104、操作系统108等相结合)可以计算第一经过时间与第二经过时间之间的时钟漂移。如上所述,例如,定时源同步组件124可以确定两个时刻之间的第一时钟(例如,主机时钟120)的第一经过时间和时刻之间的第二时钟(例如,接口时钟122)的第二经过时间,并且可以基于经过时间之间的差(例如,以ms、μs等为单位测量的)来确定时钟漂移。另外,例如,定时源同步组件124可以在重复事件的每个实例确定该时钟漂移,如上所述。另外,例如,定时源同步组件124可以周期性地和/或基于请求向操作系统108(或其一个或多个组件)、一个或多个应用110等报告时钟漂移。
[0026]在方法200中,可选地,在动作210处,可以基于时钟漂移在第一定时源或第二定时源中的一个定时源的域中预测在第一定时源或第二定时源中的另一定时源的第二域中发生过去事件的时间,以确定所计算出的时钟漂移的准确性。在一个示例中,定时源同步组件124(例如,与处理器102、存储器104、操作系统108等相结合)可以基于时钟漂移(例如,由定时源同步组件124确定的时钟漂移,如上所述)在第一定时源或第二定时源中的一个定时源的域中预测在第一定时源或第二定时源中的另一定时源的第二域中发生过去事件的时间,以确定所计算出的时钟漂移的准确性。例如,定时源同步组件124可以将在主机时钟120的域中确定的时钟漂移应用于在接口时钟122的域中发生的过去事件的时间,并且可以将结果与接口时钟122的域中的事件的实际时间进行比较以确定准确性。例如,定时源同步组件124可以将准确性确定为预测的时间和实际时间的计算值(例如,预测的时间与实际时间的比率等)。如本文所述,这可以允许定时源同步组件124在提供时钟值、时钟漂移等的指示时指示准确性。
[0027]在方法200中,可选地,在动作212处,可以确定预测的时间的准确性。在一个示例中,定时源同步组件124(例如,与处理器102、存储器104、操作系统108等相结合)可以确定预测的时间的准确性。例如,定时源同步组件124可以基于第一定时源或第二定时源中的一个定时源的准确性来确定预测的时间的准确性。因此,例如,在USB定时源的情况下,准确性可以对应于USB时钟的粒度(例如,125μs)。然而,在一个示例中,在动作204处接收的请求可以指示用于边沿检测的选项,在这种情况下,确定第一时钟的第一经过时间和第二时钟的第二经过时间可以发生在时钟之一的边沿的实例(例如,边沿可以是时间的圆分割(rounddivision),诸如帧或微帧、微秒开始的实例等)。例如,在接口时钟122用于USB的情况下,定时源同步组件124可以在接口时钟122的边沿处(例如,在1ms的USB帧的开始或在125μs的USB微帧的开始时)确定第一经过时间和第二经过时间。在该示例中,定时源同步组件124可以确定(并且例如作为下面的动作214中的指示的一部分来指示)与主机时钟120的粒度相对应的准确性(例如,对于QPC,为数十或数百纳秒的量级)。
[0028]在方法200中,在动作214处,可以提供与第一经过时间和第二经过时间相关的指示。在一个示例中,定时源同步组件124(例如,与处理器102、存储器104、操作系统108等相结合)可以提供与第一经过时间和第二经过时间相关的指示。例如,定时源同步组件124可以将该指示提供给可能已经请求该指示(例如,在动作204处)的应用110。另外,定时源同步组件124可以基于一个或多个触发(诸如重复事件等)周期性地响应于该请求而提供该指示。此外,定时源同步组件124可以在指示中包括来自第一时钟和/或第二时钟的一个或多个时钟值、第一经过时间和第二经过时间、第一经过时间与第二经过时间之间的差、所计算出的时钟漂移(例如,以百分比、微秒数或其他时间量度等表示)、所计算出的时钟漂移的预测准确性等,如上所述。另外,定时源同步组件124可以基于诸如功率利用率、环境或操作温度等多种因素来启用或禁用跟踪和/或确定时钟漂移。
[0029]在一个示例中,定时源同步组件124可以自主地(和/或基于初始请求)管理时钟120、122的同步,以及基于一段时间内的重复事件来确定第一经过时间和/或第二经过时间、时钟漂移、准确性等。在该示例中,定时源同步组件124可以根据请求提供第一经过时间和/或第二经过时间、时钟漂移、准确性等的当前指示。
[0030]上述示例可以允许在从处理器102时钟中导出的时间与从接口时钟122时钟中导出的时间(例如,从USB控制器时钟中导出的USB总线时间)之间的足够准确且省电的同步。例如,应用110可以查询可以由接口控制器驱动器118(例如,操作系统108中的USB驱动器栈)公开的应用程序编程接口(API),该API将可以由操作系统108跟踪并且可以对应于主机时钟120的定时的QPC值映射到由接口控制器116(例如,USB主机控制器硬件)跟踪的接口(例如,USB)帧和微帧。这可以允许应用110将其自身的功能(其可以在处理器102上运行并且因此对应于主机时钟120的定时)与由接口控制器116上的设备(例如,USB总线)提供的数据(其可以对应于接口时钟122的定时)同步。例如,由接口控制器驱动器118公开的API可以允许应用110获取当前接口(例如,USB)帧和微帧、以及与帧和微帧相关联的QPC值。如上所述,例如,接口控制器驱动器118可以确定与当前帧和微帧相关联的QPC值、与先前帧和微帧相关联的QPC值等,并且可以根据请求将该信息提供给应用110。另外,例如,API可以允许应用110获取在指定接口(例如,USB)帧和微帧的开始时(例如,在边沿处,定时源同步组件124可以在该边沿处检测并且将其用于确定以记录对应的QPC)出现的QPC值。此外,在一个示例中,API可以允许应用110获取QPC值的预测准确性,如上所述。
[0031]在特定示例中,设备100可以包括用于提供虚拟现实、混合现实或类似体验的头戴式显示器(HMD)设备。HMD设备可以包括各种惯性传感器、相机等作为输入设备112、114以检测HMD设备的头部位置,其可以用于将场景渲染到HMD设备上的显示器。在一个示例中,惯性传感器、相机等可以经由USB总线连接到HMD设备(例如,HMD设备的处理器102)。在该示例中,执行以提供虚拟现实/混合现实体验的应用110可以从各种输入设备112、114获取数据,这些数据可以指示HMD设备的运动、与该运动相关的加速度或速度、从HMD设备捕获的图像等。在一个示例中,可能需要来自各种传感器和应用110的数据之间的强定时相关性(例如,以将惯性测量与对应的捕获图像等相匹配)。接口控制器116可以从各种输入设备112、114接收带有时间戳的数据(例如,基于输入设备112、114中的时钟、接口时钟122,诸如USB时钟等),和/或可以在收到输入数据时执行加时间戳。
[0032]在该示例中,应用110可以将来自接口时钟122的时间戳解析为主机时钟120的对应时间值。在一个示例中,应用110可以在相同或相似的时刻从定时源同步组件124请求和/或定期接收接口时钟122值(例如,帧和/或微帧)和主机时钟120值(例如,QPC值)。定时源同步组件124可以计算(例如,根据请求)或者以其他方式维持(例如,并且根据请求报告)时钟120、122的值之间的时钟漂移。在该示例中,应用110可以通过向时间戳应用当前保持的时钟漂移来解析时间戳。在另一示例中,应用110可以从定时源同步组件124请求与应用110可以在请求中指示的先前接口时钟122值相对应的主机时钟120值,并且定时源同步组件124可以预测先前时间,如上所述,和/或可以返回预测的时间的计算准确性。在又一示例中,应用110可以从定时源同步组件124请求和/或周期性地接收所确定的时钟漂移量,应用110可以将该时钟漂移量应用于所接收的接口时钟122值以解析对应的主机时钟120值。在任何情况下,应用110都可以确定与从输入设备112、114接收的输入数据相对应的主机时钟120值,以使所接收的数据与其他接收的或生成的数据同步(例如,使HMD设备的运动数据与由应用110渲染的图像或场景同步),使所接收的数据与应用110的操作同步,等等。
[0033]图3示出了根据本文中描述的示例的用于指示用于多个定时源的同步信息的消息流程图300的示例。消息流程图300示出了可以与接口控制器驱动器118通信以获取多个时钟的同步信息的应用110、以及可以维持接口(例如,USB接口)的时钟的接口控制器116。在一个示例中,可选地,应用110可以在302处向接口控制器驱动器118发送API注册,这可以允许应用110请求使用接口控制器驱动器118来与接口控制器116通信和/或更具体地从接口控制器驱动器118接收定时同步信息。作为响应或以其他方式,可选地,接口控制器驱动器118可以在302处向接口控制器116发送请求同步开始命令,这可以引起接口控制器116在接口控制器驱动器118上提供或调用中断以向接口控制器驱动器118通知一个或多个定时相关事件。当在302处发送API注册时启动中断可以允许使对不需要同步功能的设备的中断最小化。例如,接口控制器116可以在接口控制器驱动器118上调用回调函数,或者以其他方式向接口控制器驱动器118通知时间相关事件,这可以包括接口控制器116向接口控制器驱动器118通知新帧何时开始时,新微帧何时开始,等等。
[0034]例如,接口控制器116可以维持可以跟踪接口上用于与一个或多个输入设备通信的帧和/或微帧的时钟(例如,接口时钟122)。如上所述,在接口控制器116是USB控制器的情况下,帧可以每1ms发生一次,而微帧可以在每1ms帧中每125μs发生一次。在任何情况下,接口控制器116都可以通过在306处向接口控制器驱动器118发送帧开始通知来向接口控制器驱动器118通知每个帧。接口控制器驱动器118可以基于在308处接收到帧开始来存储帧、微帧和/或QPC(例如,在诸如存储器104等存储器中)。例如,接口控制器驱动器118可以基于接收到帧开始来获取QPC,其中QPC可以基于设备的处理器的主机时钟(例如,处理器102的主机时钟120等)。在另一示例中,可选地,接口控制器116还可以在310处向接口控制器驱动器118通知每个微帧开始,和/或类似地,接口控制器驱动器118可以在312处存储帧、微帧和/或QPC。如上所述,接口控制器116可以在每次接口时钟溢出时通知接口控制器驱动器118。
[0036]此外,例如,可选地,基于在314处的定时请求或者以其他方式,接口控制器驱动器118可以基于某些事件向应用110通知定时信息。例如,接口控制器驱动器118可以在320处在每个帧开始318时向应用110通知更新后的定时信息。在另一示例中,附加地或备选地,接口控制器驱动器118可以在324处在一个或多个微帧开始322时向应用110通知更新后的定时信息。在又一示例中,当接口时钟溢出时,接口控制器驱动器118可以向应用110通知更新后的定时信息。在任何情况下,可选地,应用110都可以在326处注销API(例如,在应用110终止时,或者以其他方式确定不再需要定时同步时),并且可选地,接口控制器驱动器118可以在328处从接口控制器116请求同步中断的接收的终止。
[0037]图4示出了与设备100(图1)相似或相同的设备400的示例,设备400包括如图1所示的其他可选组件细节。在一种实现中,设备400可以包括用于执行与本文中描述的组件和功能中的一个或多个相关联的处理功能的处理器402,处理器402可以类似于处理器102。处理器402可以包括单组或多组处理器或多核处理器。此外,处理器402可以被实现为集成处理系统和/或分布式处理系统。
[0038]设备400还可以包括存储器404,存储器404可以类似于存储器104,诸如用于存储由处理器402执行的应用的本地版本,诸如定时源同步组件124、应用、相关指令、参数等。存储器404可以包括由计算机可使用的类型的存储器,诸如随机存取存储器(RAM)、只读存储器(ROM)、磁带、磁盘、光盘、易失性存储器、非易失性存储器及其任何组合。
[0039]此外,设备400可以包括通信组件406,通信组件406利用本文中描述的硬件、软件和服务来提供与一个或多个其他设备、参与者、实体等的建立和维持通信。通信组件406可以在设备400上的组件之间以及在设备400与外部设备(诸如跨通信网络定位的设备和/或串行或本地连接到设备400的设备)之间进行通信。例如,通信组件406可以包括一个或多个总线,并且还可以包括分别与可操作用于与外部设备接口的无线或有线发射器和接收器相关联的发射链组件和接收链组件。
[0040]另外,设备400可以包括数据存储库408,数据存储库408可以是硬件和/或软件的任何合适的组合,数据存储库408提供结合本文中描述的实现而采用的信息、数据库和程序的大容量存储。例如,数据存储库408可以是或可以包括用于处理器402当前未执行的应用和/或相关参数(例如,定时源同步组件124、应用等)的数据存储库。数据存储库408可以是用于定时源同步组件124、应用和/或设备400的一个或多个其他组件的数据存储库。
[0041]可选地,设备400可以包括用户接口组件410,用户接口组件410可操作以从设备400的用户接收输入并且进一步可操作以生成用于呈现给用户的输出。用户接口组件410可以包括一个或多个输入设备,包括但不限于键盘、数字键盘、鼠标、触敏显示器、导航键、功能键、麦克风、语音识别组件、手势识别组件、深度传感器、凝视跟踪传感器、开关/按钮、能够从用户接收输入的任何其他机制、或其任何组合。此外,用户接口组件410可以包括一个或多个输出设备,包括但不限于显示器、扬声器、触觉反馈机制、打印机、能够向用户呈现输出的任何其他机制、或其任何组合。
[0042]设备400可以附加地包括定时源同步组件124,定时源同步组件124用于在与设备400相关的多个定时源之间使定时同步,以便于在相同或相似的时域中时间发生的事件的关联。
[0043]作为示例,元素或元素的任何部分或元素的任何组合可以用包括一个或多个处理器的“处理系统”而被实现。处理器的示例包括微处理器、微控制器、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑器件(PLD)、状态机、门控逻辑、分立硬件电路、以及被配置为执行整个本文档中描述的各种功能的其他合适的硬件。处理系统中的一个或多个处理器可以执行软件。软件应当广义地解释为表示指令、指令集、代码、代码段、程序代码、程序、子程序、软件模块、应用、软件应用、软件包、例程、子例程、对象、可执行文件、执行线程、过程、功能等,无论是被称为软件、固件、中间件、微码、硬件描述语言还是其他形式。
[0044]因此,在一个或多个实现中,一个或多个所描述的功能可以以硬件、软件、固件或其任何组合而被实现。如果以软件实现,则功能可以存储在计算机可读介质上或者作为一个或多个指令或代码被编码在计算机可读介质上。计算机可读介质包括计算机存储介质。存储介质可以是可以由计算机访问的任何可用介质。作为示例而非限制,这样的计算机可读介质可以包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储、磁盘存储或其他磁性存储设备、或者可以用于以指令或数据结构的形式承载或存储期望的程序代码并且可以由计算机访问的任何其他介质。本文中使用的磁盘和光盘包括光盘(CD)、激光光盘、光盘、数字多功能光盘(DVD)和软盘,其中磁盘通常磁性地复制数据,而光盘则通过激光光学地复制数据。上述的组合也应当被包括在计算机可读介质的范围内。
[0045]提供先前描述以使得本领域任何技术人员能够实践本文中描述的各个实现。对这些实现的各种修改对于本领域技术人员将是很清楚的,并且本文中定义的一般原理可以应用于其他实现。因此,权利要求书并非旨在限于本文中示出的实现,而是应当被赋予与语言权利要求书相一致的完整范围,其中除非明确指出,否则以单数形式提及元素并不意图表示“一个且仅一个”,而是表示“一个或多个”。除非另有明确说明,否则术语“一些”是指一个或多个。本领域普通技术人员已知或以后将知道的本文中描述的各个实现的元素的所有结构和功能等同物旨在被权利要求所涵盖。此外,本文中公开的任何内容都不旨在献给公众,无论这样的公开在权利要求书中是否明确记载。除非权利要求要素使用短语“用于......的手段”明确地叙述,否则任何权利要求要素都不应当被解释为手段加功能。