FreePBX v17 playback jitter

FreePBX Installation / Upgrade
,
1

We successfully migrated to v17 only to find that audio playback has jitter, but calls do not. This seems like an issue with the timing module possibly.

This instance is running on vSphere as was the previous v16 instance that has no issues.

2

The FreePBX version has nothing to do with the timing used by Asterisk. What version of Asterisk are you running? And is there jitter if you record the call on the server side in the playback?

3

There is also the “timing test” CLI command in Asterisk which can be used to test timing, you can run that and see how timing is.

1 Like
4

We tested Asterisk 18 which was installed by default on FreePBX v17 and then we upgraded it to v20. The jitter only occurs on audio playback and not on the call, which is why I was suspecting the timer.

5

Seems pretty consistent:

FreePBXv17CLI> timing test
Attempting to test a timer with 50 ticks per second.
Using the ‘timerfd’ timing module for this test.
It has been 1000 milliseconds, and we got 50 timer ticks
FreePBXv17CLI> timing test
Attempting to test a timer with 50 ticks per second.
Using the ‘timerfd’ timing module for this test.
It has been 1000 milliseconds, and we got 50 timer ticks
FreePBXv17CLI> timing test
Attempting to test a timer with 50 ticks per second.
Using the ‘timerfd’ timing module for this test.
It has been 1000 milliseconds, and we got 50 timer ticks
FreePBXv17CLI> timing test
Attempting to test a timer with 50 ticks per second.
Using the ‘timerfd’ timing module for this test.
It has been 1000 milliseconds, and we got 50 timer ticks

6

At the time of execution the timer would appear to be functioning fine.

7

I did notice that if we disabled the timerfd module, the playback jitter was slightly worse, so it does seem like a timing issue.

PRETTY_NAME=“Debian GNU/Linux 12 (bookworm)”
NAME=“Debian GNU/Linux”
VERSION_ID=“12”
VERSION=“12 (bookworm)”
VERSION_CODENAME=bookworm
ID=debian
HOME_URL=“https://www.debian.org/”
SUPPORT_URL=“Debian -- User Support”
BUG_REPORT_URL=“https://bugs.debian.org/”

Linux FreePBXv17 6.1.0-35-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.137-1 (2025-05-07) x86_64 GNU/Linux

8

We could try to build Asterisk from source on this system and retest.

9

That wouldn’t really change things. The Asterisk side of timers hasn’t changed in years upon years upon years, and the timerfd implementation is from the kernel itself. Changing Asterisk wouldn’t change that.

When the issue occurs with the playback then “timing test” should show it, if the problem is indeed timing related. You could also get a packet capture and look at the underlying audio sent to the endpoint itself - the timing of the packets and their contents.

10

Is there anything else that would cause jitter only on audio playback? We ran many test calls for long periods and never had so much as a glitch on the audio; but any and all audio playback is problematic. We tried converting the audio from wav to ulaw to see if that would change anything, but it didn’t. Latency tests on the hard drive were 134us so there weren’t any speed issues on the filesystem.

I’m just wondering what specifically might cause issues only with audio file playback.

11

It can be timing, but a packet capture would actually quantify it and show what on the wire is happening.

12

FreePBX v17 installs Asterisk v21 by default. You would have to switch to a lower version like 18 manually at some point.

13

Yeah, sorry, it is actually v22 that we have running:

Asterisk 22.3.0 built by jenkins @ 8b393604a586 on a x86_64 running Linux on 2025-04-08 09:21:18 UTC

14

I noticed this when migrating from freepbx 14 to 17, and whichever asterisk versions came with those. The issue was specifically with ogg format files and I ended up having to rerecord all my custom recordings in PCM.

15

Since January, FreePBX v17 installs Asterisk v22 by default:

16

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.