There is a high CPU load on an asterisk server. To record calls to disk g729 is being transcoded to pcm_s16le.
Can it cause high CPU load?
By the way, command
'core show translation paths g729' shows
g729 To slin16 : (g729)->(slin)->(g722)->(slin16).
Transcoding from or to a frequency domain type codec is the most CPU intensive activity normally associated with an Asterisk system.
I note your translation path has three such translations. I’m surprised there is no direct translation from slin to slin16. What is in your codec translation costs matrix?
Given that this translation path goes through slin, there is no quality advantage in using slin16 over slin. G.729 is also an 8kHz codec, so slin16 offers it no advantage over slin.
Costs matrix is the following:
ulaw alaw slin g729 g722 slin16 testlaw
ulaw - 15000 9000 15000 17250 26250 15000
alaw 15000 - 9000 15000 17250 26250 15000
slin 6000 6000 - 6000 8250 17250 6000
g729 15000 15000 9000 - 17250 6250 15000
g722 15600 15600 9600 15600 - 9000 15600
slin16 21600 21600 15600 21600 6000 - 21600
testlaw 15000 15000 9000 15000 17250 26250 -
So the best solution is to write files to disk with MixMonitor right in g729?
MixMonitor needs to transcode to signed linear of some form to be be able to work at at all, as it has to add the linear samples together!
Looking at https://asteriskfaqs.org/2012/11/21/asterisk-users/core-show-translation-difference-in-asterisk-versions.html it seems to me that Asterisk may be making some bad routing decisions and using the scenic route between codecs. I can’t see that using g722 as an intermediate is really going to produce better audio than say a cubic interpolation to rate adapt 8kHz signed linear to 16kHz signed linear, and, if the original is G.729, there is no point in sampling faster than 8kHz.
As Jonathon commented in the quoted article, he can possibly say more about why such convoluted transcoding paths are being used.
If the codec_resample module is not built and loaded I could see it doing that. The g722 translator has a direct path from signed linear at 8kHz.
Thank you, codec_resample seems to work!
However, i wonder if it is possible to write to disk in slin, without further converting to slim16?