I would like to improve the sound quality of the IVR menu. When I play a recording in FreePBX everything is as expected (but I think I play the wav file and not one off the other codecs). All audio is converted/saved in FreePBX to wav, alaw, ulaw and g722 (but it is not really clear to me what the benefits are).
When someone calls, the IVR plays these audio clips but not in the same quality (it chops a bit, like it is realtime recoding the source).
Questions to this issue:
How are the right codec audio clip selected for an incoming call
Are these details logged somewhere (so I can check which clip/compression were selected, so I can check these audio files)
What happens if a codec is not available for the IVR, is there a realtime conversion somehow that can cause choppy audio?
The codec for which there is the chain of conversions (including null) with the lowest computed cost. For aggressively compressed codecs, that will generally go through an uncompressed stage, so your wav file will be used as the most common fallback.
The file extension chosen is logged, although I cannot remember at what level it is logged.
As above, the codec is transcoded using the translations available. This will not cause choppy audio,
Choppy audio is caused by jitter or packet loss caused when the processor is overloaded (on a 10s of ms timescale) or the network is overloaded.
I’m sure that I don’t have a network overload (jitter or packet loss), because everything else works as designed flawless ;-). Reading your explanation about selecting the codec… is deleting the alaw and ulaw files a forced method to kick in the G722 encoded clips ?
Still wondering what can be the cause. Can I set a debug level to analyze this ?
It would fall back to wav. You really do want to keep wav or slin (its underlying codec). Generally you would only want G.772 used if the phone was using G.722, not as the source for a transcoding chain. Ideally you would want files in all the codecs which are actually being used by phones, although that assumes you have original recordings that are at least as good. That way no transcoding is needed on the fly, although that is a CPU performance issue, not an audio quality one.
If you want a source to transcode to 16kHz sampled audio, you should use slin16 or slin32, but that assumes you have at least a good an original to prepare that file.
You should upload the announcement in the same format your trunking provider uses, typically ulaw or alaw. If you are in a country such as Germany where VoLTE calls are delivered in wideband “HD voice”, upload a wideband version also. That way, Asterisk should never have to transcode.
If you still have problems, do a ‘fair’ test by listening to the call and also listening to what you uploaded, using the same device e.g. a softphone. They should sound identical. If not, capture the RTP exiting the PBX with tcpdump and analyze it with Wireshark for jitter (and possibly packet loss). If it’s bad, tell us about the machine running Asterisk (resources, virtualization, etc.) If good, troubleshoot further (network issue, trunking provider problem, etc.)
It’s common to have choppy voice in the first one or two seconds of a call, while jitter buffers adjust. If that’s your only issue, put one second of silence at the beginning of the announcement. If you need more, put two or three seconds of fake ringback tone at the beginning.
@Stewart1: Thank you for your advise. I will start with adding silence at the beginning. The easiest to do and check. Will post the results here → Outcome of the test: Jitter was not in the start, but during a second sound clip in the IVR.
Started to disable IVR clips by renaming the ulaw/alaw/g722 related clips, to see what was causing this (wav version remained untouched).
No real improvement so I decided to dive into the audio codec settings and changed the waterfall to G729, G722 and Alaw (previous order Ulaw, Alaw, G722). This seems to improve the overall audio quality so far. But I have to test more.
@Charles: Have 50mb down/10mb up internet connection, no issues with that. I control the router.
I never have any voice call quality issues. I can even check that based on the calls I record automatically.
Will correct that immediately