- * Suppose instead that the second track arrives at t=0.5s, and that
- * we've managed to transmit the whole of the first track already. We'll
- * have target_rtp_time=44100.
- *
- * The desired behaviour is to play the second track back to back with
- * first. In this case therefore we do not modify rtp_time.
- *
- * Is it ever right to reduce rtp_time? No; for that would imply
- * transmitting packets with overlapping timestamp ranges, which does not
- * make sense.
+ * It's never right to reduce rtp_time, for that would imply packets with
+ * overlapping timestamp ranges, which does not make sense.