Thanks to visit codestin.com
Credit goes to github.com

Skip to content

dsp.c: Fix and improve potentially inaccurate log message.#596

Merged
asterisk-org-access-app[bot] merged 1 commit into
asterisk:masterfrom
InterLinked1:master-issue-595
Feb 14, 2024
Merged

dsp.c: Fix and improve potentially inaccurate log message.#596
asterisk-org-access-app[bot] merged 1 commit into
asterisk:masterfrom
InterLinked1:master-issue-595

Conversation

@InterLinked1

Copy link
Copy Markdown
Contributor

If ast_dsp_process is called with a codec besides slin, ulaw, or alaw, a warning is logged that in-band DTMF is not supported, but this message is not always appropriate or correct, because ast_dsp_process is much more generic than just DTMF detection.

This logs a more generic message in those cases, and also improves codec-mismatch logging throughout dsp.c by ensuring incompatible codecs are printed out.

Resolves: #595

@InterLinked1

Copy link
Copy Markdown
Contributor Author

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

Comment thread main/dsp.c Outdated
int freqmode;
int dtmf_began;
int display_inband_dtmf_warning;
unsigned int display_inband_dtmf_warning:1;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated change that snuck in? If not can you explain the rationale for this change?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is related; I reviewed all the code where this is used and set, and it only needs to be a bitfield, not an int.
I considered renaming the variable too for clarity but guess I didn't do that.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But you aren't changing any code that reads or sets this structure member, so it's not clear to me what the benefit is. Does it change the generated code? Due to alignment concerns I don't think it would change the size of the struct either?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's more semantic. You can look at the struct and know that it's a boolean variable, which was not conveyed before. I think it helps with code clarity to do this, regardless of space savings, since it serves as documentation.

If more bitfields are added in the future, then it would actually reduce memory usage.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If more bitfields are added in the future, then it would actually reduce memory usage.

I don't think that is correct, but I will defer to your expertise on this.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like change for the sake of change. If that time ever comes, then it can be changed at that point. Right now it is premature to touch it or care about it. Just changing the log message is fine.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It wasn't really for a future hypothetical performance benefit, it was more for making the code more self-documenting, since that variable is already a misnomer. I've changed it back but added a documentation note about this.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like busymaybe could be a bitfield too. I would add the same comment there so people aren't confused.

Comment thread main/dsp.c Outdated
Comment thread main/dsp.c Outdated
int freqmode;
int dtmf_began;
int display_inband_dtmf_warning;
unsigned int display_inband_dtmf_warning:1;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like change for the sake of change. If that time ever comes, then it can be changed at that point. Right now it is premature to touch it or care about it. Just changing the log message is fine.

jcolp
jcolp previously approved these changes Feb 13, 2024
If ast_dsp_process is called with a codec besides slin, ulaw,
or alaw, a warning is logged that in-band DTMF is not supported,
but this message is not always appropriate or correct, because
ast_dsp_process is much more generic than just DTMF detection.

This logs a more generic message in those cases, and also improves
codec-mismatch logging throughout dsp.c by ensuring incompatible
codecs are printed out.

Resolves: asterisk#595
@gtjoseph gtjoseph added the cherry-pick-test Trigger dry run of cherry-picks label Feb 13, 2024
@github-actions github-actions Bot added cherry-pick-testing-in-progress Cherry-Pick tests in progress cherry-pick-checks-passed Cherry-Pick checks passed cherry-pick-gates-failed Cherry-Pick gates failed and removed cherry-pick-test Trigger dry run of cherry-picks cherry-pick-testing-in-progress Cherry-Pick tests in progress labels Feb 13, 2024
@github-actions

Copy link
Copy Markdown

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[improvement]: dsp.c: Fix and improve confusing warning message.

4 participants