outputs {
zmq "zmq+tcp://*:18081"
test "simul://"
}
The audio encoders and the multiplexer are running on the same machine. The output of the multiplexer is then fed to a EasyDABv2 exciter board. The output of timedatectl on the encoder/multiplexer is:
Local time: Sun 2022-02-06 22:24:07 CET
Universal time: Sun 2022-02-06 21:24:07 UTC
RTC time: Sun 2022-02-06 21:24:07
Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
so everything is looking good. Chrony is also running. I just did a few more tests: When I stop ODR-DabMux, the audio is gone immediately. That tells me that the issue is not between the transmitter and the multiplexer. When I stop ODR-AudioEnc, there is a delay of exactly 37 seconds which is why I thought that the TAI-UTC offset has something to do with this. When I use zmq instead of EDI, the delay is much lower (only about 2 seconds) but the delay keeps growing indefinitely. If you would like to take a look at the configuration, I would be happy to enable SSH access for you. This is only a test setup in my lab, the production unit that is actually broadcasting is still running with zmq and the buffer option "prebuffering" but will be switched over to EDI with "buffer-management timestamped" once the cause of this strange phenomenon is identified. :-)
Cheers
Felix
Reference ID : 81468425 (stratum2-4.NTP.TechFak.NET)
Stratum : 3
Ref time (UTC) : Sat Feb 19 17:10:14 2022
System time : 0.000284899 seconds slow of NTP time
Last offset : -0.000129834 seconds
RMS offset : 0.000627513 seconds
Frequency : 11.001 ppm slow
Residual freq : +0.006 ppm
Skew : 0.917 ppm
Root delay : 0.021726156 seconds
Root dispersion : 0.002185798 seconds
Update interval : 129.7 seconds
Leap status : Normal
The Python Script returns:
Statistics from ODR-DabMux v4.0.0
id max min under over audio L audio R peak L peak R state version uptime offset
sub_radio1 43200 42768 1511 0 -6 -6 0 0 Unstable (2) ODR-AudioEnc v3.1.0-3-g137828b 381 0
sub_radio2 15552 13824 197 33 -7 -7 0 0 Unstable (2) 0 0
sub_radio3 15552 13392 812 132 -90 -90 -90 -90 Unstable (2) 0 0
sub_radio4 15552 13824 197 33 -7 -6 -1 -1 Unstable (2) 0 0
sub_radio5 15552 13824 196 33 -7 -7 -1 -2 Unstable (2) 0 0
sub_radio6 15552 13824 196 33 -8 -6 -4 -4 Unstable (2) 0 0
sub_radio7 15552 13824 196 33 -8 -8 -4 -4 Unstable (2) 0 0
sub_radio8 15552 13392 196 33 -8 -7 -3 -3 Unstable (2) 0 0
sub_radio9 15552 13824 196 33 -11 -12 -5 -5 Unstable (2) 0 0
Currently, only sub_radio1 is configured to use the timestamped option, the other channels are configured to use pre-buffering and have a normal latency that, however, keeps increasing continuously.
Greetings and have a great weekend :-)
Cheers
Felix
Statistics from ODR-DabMux v4.0.0
id max min under over audio L audio R peak L peak R state version uptime offset
sub_radio1 42768 42768 1511 0 -5 -5 0 0 Streaming (4) ODR-AudioEnc v3.1.0-3-g137828b 4171 0
sub_radio2 15552 13392 197 33 -9 -9 0 0 Streaming (4) 0 0
sub_radio3 15552 0 12075 1947 -90 -90 -90 -90 Unstable (2) 0 0
sub_radio4 15552 13824 197 33 -3 -4 -1 -1 Streaming (4) 0 0
sub_radio5 15552 13824 196 33 -5 -5 -1 -2 Streaming (4) 0 0
sub_radio6 15552 13392 196 33 -8 -7 -3 -4 Streaming (4) 0 0
sub_radio7 15552 13392 196 33 -7 -7 -4 -4 Streaming (4) 0 0
sub_radio8 15552 13392 196 33 -11 -13 -3 -2 Streaming (4) 0 0
sub_radio9 15552 13392 196 33 -13 -12 -4 -5 Streaming (4) 0 0