-
Notifications
You must be signed in to change notification settings - Fork 452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
augain: add audio volume filter module #3166
Conversation
modules/augain/augain.c
Outdated
if (!st || !af || !af->sampv || !af->sampc) | ||
return EINVAL; | ||
|
||
if (af->fmt != AUFMT_S16LE) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check should be moved to encode_update
(prm->fmt
), not needed to execute for every frame.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved af->fmt
check but was not sure if also if (!st || !af || !af->sampv || !af->sampc)
could have been moved.
modules/augain/augain.c
Outdated
gained_sample = (int16_t)(sample * encode_gain); | ||
/* | ||
info("augain: sample=%d/gained=%d\n", sample, gained_sample); | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove debug code
Does it make any sense to have call
in |
|
||
highest_possible_gain = 32767.0 / highest_abs_sample; | ||
if (encode_gain > highest_possible_gain) | ||
encode_gain = highest_possible_gain; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the real gain is different for each frame, depending on the frame energy.
Does this algorithm work, is there any audible noise or artefacts ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I thought that it is better than cutting those sample values that that would not fit 32768 - 32767 range.
I have made tests and haven't noticed anything very bad. It is trade of between not hearing anything and hearing, but with some artifacts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made several tests using both adaptive and fixed algorithm and noticed less artifacts with the adaptive one. Thus I don't think that it is worth to add fixed algorithm to this PR. It can be added later if someone needs it.
From my point of view, this PR is done.
Here is another implementation, for inspiration: https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/af_volume.c |
@alfredh If I interpreted the quoted ffmpeg code correctly, it is after applying the gain cutting the resulting value to -32768 - 32767 range, whereas the code in this PR lowers the gain so that the the resulting value stays within the range. To me the ffmpeg version (if I understood it correctly), could result to lots of min or max sample values if gain is large. |
One possibility might be to introduce two algorithms, say |
thanks, can you please also update this page with the new module and your name ? https://github.com/baresip/baresip/wiki/Modules |
Thanks for the merge. Added the module to Wiki. |
This module can be used to increase volume of audio source, for example, microphone.