Apply suggestions from code review

(doc review, finished)

Co-authored-by: stevomatthews <smatthews@haivision.com>

docs/API/API-socket-options.md

@@ -1309,11 +1309,11 @@ is determined by the negotiation in the connection establishment (handshake exch
 The general idea for the latency mechanism is to keep the time distance between two consecutive
 received packets the same as the time when these same packets were scheduled for sending by the
 sender application (or per the time explicitly declared when sending - see
-[`srt_sendmsg2`](API-functions.md#srt_sendmsg2) for details). This makes the packets, that have arrived
-earlier than their delivery time, kept in the receiver buffer until this time comes. This should
-compensate any jitter in the network and an extra delay needed for a packet retransmission.
+[`srt_sendmsg2`](API-functions.md#srt_sendmsg2) for details). This keeps any packets that have arrived
+earlier than their delivery time in the receiver buffer until their delivery time comes. This should
+compensate for any jitter in the network and provides an extra delay needed for a packet retransmission.
 
-For the detailed information on how the latency setting influences the actual packet delivery time and
+For detailed information on how the latency setting influences the actual packet delivery time and
 how this time is defined, refer to the [latency documentation](../features/latency.md).
 
 Reading the `SRTO_RCVLATENCY` value on a socket after the connection is established provides the actual (negotiated)

docs/features/latency.md

@@ -133,10 +133,9 @@ both machines with identical time bases and speeds, then:
 
 * `ATS[x] = program_delay[x] + network_delay[x] + STS[x]`
 
-(The only problem with treating this above formula too seriously
-is that there doesn't exist the common clock base for two
-network-communicating machines, so these components should be
-treated as something that does exist, but isn't exactly measurable).
+Note that two machines communicating over a network do not typically have a
+common clock base. Therefore, although this formula is correct, it involves
+components that can neither be measured nor captured at the receiver side.
 
 This formula for ATS doesn't apply to the real latency, which is based strictly 
 on ETS. But you can apply this formula for the very first arriving packet, 
@@ -189,8 +188,9 @@ We can now get the true network latency in SRT by moving STS to the other side:
 The DRIFT
 =========
 
-The DRIFT, for simplifyint the calculations above, should be treated as 0,
-which is the initial state. In time, however, it gets changed basing on the
+The DRIFT is a measure of the variance over time of the base time. 
+To simplify the calculations above, DRIFT is considered to be 0,
+which is the initial state. In time, however, it changes based on the
 value of the Arrival Time Deviation:
 
 * `ATD[x] = ATS[x] - ETS[x]`