You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/technical_documentation.md
+7-2Lines changed: 7 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -260,8 +260,13 @@ This packet requests from us to send a RPLY with the current CMTime for the Cloc
260
260
261
261
#### 3.2.7. SKEW Packet
262
262
##### General Description
263
-
(WIP) It seems like this packet requires us to reply with the difference of our local clock in 48khz ticks to the device clock, which
264
-
we can get from the audio samples.
263
+
This packet tells the device about the clock skew of the audio clock (clockRef used in EAT! packets, which we sent as response to cwpa). As denoted in this [wikipedia](https://en.wikipedia.org/wiki/Clock_skew#On_a_network) article, clock skew means the difference in frequency of both clocks. In other words, both clocks supposedly
264
+
run at 48khz, and the device wants to know how many ticks per second our clock executed during the time the device clock had one tick.
265
+
So we have to respond with:
266
+
- 48000 if the clocks were aligned
267
+
- some value above 48000 if our clock was slower
268
+
- and some value below 48000 if our clock was faster than the device clock
269
+
If implemented correctly, we should see that the skew responses converge towards 48000 with small deviations sometimes `(48000+x where -1 < x <1)`
0 commit comments