translate.c: implement new direct comp table mode

[zebastian]

The new mode gives for each codec translation the actual real cost of microseconds per second cpu time taken. This allows to compare actual real cpu usage of translations and helps in evaluation of codec implementation changes regarding performance (regression testing)

sample output:

Resolves: #601

[InterLinked1]

CLA has not been signed, so this can't be reviewed yet.

However, I'm curious what one is supposed to make of "999999". It's not clear how that should be interpreted, or if that is even correct.

[zebastian]

CLA still pending, probably can get this by next week.

about the 999999:
these are present for the linear resamplers:
translate.c: Translator 'slin 8000khz -> 48000khz' does not produce sample frames.

this is due to the codec_resample.c not setting a sample on the translators, eg slin8_sample.
--> Not sure if this is intended or just missing.

Suggestion as both the 0 values and the 999999 values have no actual meaning in the context of evaluating the computational time in this table:

• For values = 999999 fill in "-"
• Also for values = 0 fill in "-"

[zebastian]

see also updated patch which now yields:

as a sample in red we can now read the expected computational cost from codec2 over slin8 to gsm as
2223 + 286 = 2509 = 2.5 milliseconds / second (as measured on an intel shared cpu vps server):

[zebastian]

Please note the alaw/ulaw and ulaw/alaw costs in the table come from a new direct alaw/ulaw|ulaw/alaw transcoder in my local environment, which runs 50% faster than the existing "A-law and Mulaw direct Coder/Decoder". (part of next patches)

    alaw:8000        To ulaw:8000       : (alaw@8000)->(ulaw@8000)

[gtjoseph]

A few things you need to do...

• Sign the CLA.
• Open an issue that describes the problem.
• Squash the commits into a single commit referencing the issue just created.
• Update the PR description and the commit message to reference the issue.
• Add a comment with the appropriate "cherry-pick" statements.

See
https://docs.asterisk.org/Development/Policies-and-Procedures/Code-Contribution/
https://docs.asterisk.org/Development/Policies-and-Procedures/Commit-Messages/

[zebastian]

@gtjoseph
i now did the following:

• Sign the CLA.
• Open an issue that describes the problem.
• Update the PR description and the commit message to reference the issue.

Not sure about the following, do you do the squashing when you merge the PR?

• Squash the commits into a single commit referencing the issue just created.

about the cherry picking: Since it is a new feature i assume this is not backported to any previous versions but only is merged against the master branch for the next version, right?

[gtjoseph]

@gtjoseph i now did the following:

• Sign the CLA.
• Open an issue that describes the problem.
• Update the PR description and the commit message to reference the issue.

You still need to update the PR description and the commit message so you need to add
a line to both like:

Resolves: #601

This allows the automation to automatically close the issue when this PR merges and also tie the issue and commit together in the change logs.

Not sure about the following, do you do the squashing when you merge the PR?

• Squash the commits into a single commit referencing the issue just created.

Nope. The automated process that does the merges doesn't squash (for many reasons) so you need to squash the commits yourself and do a force push.

about the cherry picking: Since it is a new feature i assume this is not backported to any previous versions but only is merged against the master branch for the next version, right?

If the change is a major one or one that breaks some existing behavior then yes, it'd be master-only. Most new features though are fine to backport into the currently supported branches which, at the present time, are 18, 20 and 21.

[zebastian]

@gtjoseph
thanks, all done now, see squashed commit in here.

[gtjoseph]

@gtjoseph thanks, all done now, see squashed commit in here.

cherry-pick-to: 21 cherry-pick-to: 20 cherry-pick-to: 18

You're getting closer but the "Resolves" line needs to be in the PR description, not the summary, and the cherry-pick lines need to be by themselves in a separate comment.

I'll fix both for you but keep this in mind if you should create more PRs.

[gtjoseph]

cherry-pick-to: 18
cherry-pick-to: 20
cherry-pick-to: 21

[zebastian]

Thanks @gtjoseph, will keep that in mind for future pull requests

[sangoma-oss-cla]

All committers have signed the CLA.

[github-actions]

Successfully merged to branch master and cherry-picked to ["18","20","21"]