mirrors/pipewire
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/pipewire/pipewire.git synced 2025-10-29 05:40:27 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

rtp: aes67: Document sess.ts-direct property and set it to true for AES67

Browse source
This commit is contained in:
Carlos Rafael Giani 2025-05-20 12:03:14 +02:00
parent 2fe77c47e1
commit 023525eca2
2 changed files with 15 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

5
src/daemon/pipewire-aes67.conf.in
View file

@ -128,6 +128,11 @@ context.modules = [
# This property is used if you aren't using ptp4l 4
sess.ts-refclk = "ptp=traceable"
sess.ts-offset = 0
# Directly synchronize output against the PTP-synced driver using the RTP timestamps
# This can be set to true if the reference clocks are the same; it then makes the
# synchronization more robust against transport delay variations and can help lower
# latency
sess.ts-direct = false
# You can adjust the latency buffering here. Use integer values only
sess.latency.msec = 3
audio.format = "S24BE"

10
src/modules/module-rtp-source.c
View file

@ -56,9 +56,19 @@
* - `sess.latency.msec = <float>`: target network latency in milliseconds, default 100
* - `sess.ignore-ssrc = <bool>`: ignore SSRC, default false
* - `sess.media = <string>`: the media type audio|midi|opus, default audio
* - `sess.ts-direct = <bool>`: directly synchronize output against the current
* graph driver time, using the RTP timestamps, default false
* - `stream.may-pause = <bool>`: pause the stream when no data is reveived, default false
* - `stream.props = {}`: properties to be passed to the stream
*
* Set `sess.ts-direct` to true if receivers shall play precisely in sync with the sender even
* if the transport delay differs. This can be important for use cases like AES67 sessions.
* The graph driver must then produce time that is in sync with the sender's graph driver.
* If it is set to false, the RTP timestamps will be used to reproduce the pace of the sender,
* but not directly for synchronizing when output starts. Note though that this requires that
* the receivers and senders have synchronized clocks. In PTP, the reference clocks must then
* be the same. Otherwise, senders and receives will be out of sync.
*
* ## General options
*
* Options with well-known behavior: