Some of the more common errors (caused by packet loss, network jitter, ...)
should be reported with INFO unless there is some indication about how
to fix the problem.
Fixes#4559
We want to track the difference between the PTP timestamp (now) and the
last RTP send, not the synthesized next RTP timestamp (which will always
be smoothly incrementing).
When not using PTP as the driver, it is possible that packet receive and
the process() callback are out of sync, meaning that the target buffer
fill level might be off by upto one ptime's worth of samples
occasionally. This would make the DLL hunt for the target rate, and
cause a constantly varying delay.
Accounting for the delta between the packet receive time and the
process() time allows us to eliminate this jitter, resulting in much
more consistent rate matching.
Our current AES67 sender setup requires that that PTP driver drive the
entire graph. This adds support for allowing the AES67 RTP sink to be
driven by an arbitrary driver, while still using the PTP driver for
sending data on the network.
When aes67.driver-group is specified a pw_filter is created with no
ports, node.always-process = true and node.group set to the
aes67.driver-group. When set to PTP, this gives us process callbacks at
the PTP rate which we use to get the current PTP time in the RTP sender
by interpolating the clock snapshots from the pw-filter.
Implementation ideas from Wim Taymans. Co-authored with Sanchayan Maity.
For a detailed reference, refer the following papers by Fons Adriaensen.
- Using a DLL to filter time
(https://kokkinizita.linuxaudio.org/papers/usingdll.pdf)
- Controlling adaptive resampling
(http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf)
We allow a quantum of jitter in the write timestamp. The previous value
of 32 seems to be empirically determined, using the actual quantum
allows us to reason about this better.
When multiple packets need to be flushed (because sess.latency is set
and larger than ptime) use a timer to space the packets uniformly in
the current quantum to avoid bursts.
See !1873
Move the stream function setup to a stream specific method.
Keep a separate stream format, that can be different later from the
rtp format once we add encoding.
Rename some methods to make them more unique.