Does transcoding consume CPU? (a lot)

Hello,

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.

2 Likes

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.

2 Likes

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.

2 Likes

david551, jcolp,
Thank you, codec_resample seems to work!

(g729)->(slin)->(slin16) now

However, i wonder if it is possible to write to disk in slin, without further converting to slim16?