I tried upping the ressources on the VM, (4vCPUs) and it was still bad.
What I did is I installed a new VM with FreePBX 15 and Asterisk 16. Did the test again and same results. Now fastforward a bit, we’ve done some more testing from the Office today and still choppy audio from local extensions.
So here we are:
Remote extensions in conference bridge=crappy sound
Local extensions in conference bridge=crappy sound
External callers in conference bridge=crappy sound
Remote extensions calls inbound/outbound=fine
Local extensions calls inbound/outbound=fine
I use confbridge but tried reverting to meetme but it wasn’t better. I tried to force time sync between host and guest on VMware and force hpet=enable in grub, not better. I also set the latency sensitivity to high in VMware for that particular VM but still bad.
The only thing I think I have yet to try is to change the timing source (currently timerfd)
VMware server hardware is a Dell R740 if that helps. Anybody getting a good audio quality from conference bridges in FreePBX installed on a VMware host ?
Can you describe the bad sound a little better? “Crappy” and “choppy” could mean a few things. Or even take a recording of it.
Is “Talker Optimization” turned on? Turn it off so that everyone’s audio gets mixed in the room.
Is there any transcoding taking place? You said all are set to G.711µ. Can you confirm that? Are all ptimes (Packetization Interval/Time) the same? (commonly 20ms - if you can’t find this setting to confirm, it’s probably not available to you, so don’t worry about it)
I suspect that the timer used to clock out mixed samples is running at the wrong speed. A simple test:
Create a test conference with Leader Leave set to Yes. This is needed so the test call gets knocked down when you hang up.
Dial 1-415-421-0020 (a Milliwatt test tone). You should hear 9 seconds of clean tone, followed by 1 second of silence, repeating every 10 seconds.
Do an attended transfer to the test conference, enter the User PIN and complete the transfer.
Call the test conference and enter the Admin PIN. Ideally, it will sound the same as the direct call, but you will probably hear the impairment that’s troubling you. If you hear 20 ms gaps or clicks at regular intervals, that’s almost certainly a clock rate error.
To confirm this further, do a tcpdump capture and compare the rate of RTP packets coming in from the trunking provider and RTP packets going out to your extension.
Missing parts of words or even sentences when it is worse. Talker Optimization has been tried with or without, that being said, there’s a warning in the UI: “Sets talker detection. Asterisk will send events on the manager interface identifying the channel that is talking. The talker will also be identified on the output of the conference list CLI command. Note: If Conferences Pro is installed and licensed this will always be enabled” We do have Conferences Pro so… So far no transcoding but there are not ways of choosing the conferences codec that I know of. It’s also choppy when it’s all external callers if that helps. I also see nothing of interest when watching asterisk’s full log. All other calls are working perfectly fine, it seems it’s related with the conferences. Tried Echo Test and quality was as good as non-conferences calls.
I understood that but chose an external source, because the internal Asterisk milliwatt is derived from the same (possibly bad) clock that controls the conference bridge output. If you want to avoid anything external, play a steady tone into the mic of a local IP phone.
I tried your test (with the attended transfer/415 number) and, as I expected, I had cuts in the tone but they were not regular (each 20ms let’s say) they were more random. Now I am pretty sure I have a clocking issue coming from either VMware or the Dell server it’s running on. I tried pretty much everything I thought of VMware-wise but I am open to any suggestions/ideas…
This is beyond my expertise; I’m not familiar with what tools my be available to determine the cause of irregular clock interrupts. I can’t directly blame VMware, many FreePBX systems on those VMs work fine.
On possibility is to try your existing PBX image on another platform (cloud server, old PC, etc.). If the problem persists, you can try different Confbridge and other Asterisk settings in a test scenario and when you get it working, migrate those settings to your production system.
If the other server does conferencing OK, perhaps you can get help from VMware or their community.