Transient noise suppression seems to not work

[morajabi]

(I'm using the new version from #23)

I tried enabling transient noise canceller to avoid keyboard noise, but it doesn't have any effect on the sound. Do you have any idea what should I expect and if it's indeed a bug or not?

Can it be related to this line: https://github.com/tonarino/webrtc-audio-processing/pull/23/files#diff-2fe5cefee42b0a50cdae6b4fe71600b8574c7127d629c49738414dd3ee45fe1aR50

Here's my config:

    let config = webrtc_audio_processing::Config {
      echo_canceller: EchoCanceller::Full {
        enforce_high_pass_filtering: true,
      }
      .into(),

      reporting: webrtc_audio_processing::ReportingConfig {
        enable_voice_detection: true,
        enable_residual_echo_detector: false,
        enable_level_estimation: false,
      },

      enable_transient_suppression: true,
      high_pass_filter: Some(webrtc_audio_processing::HighPassFilter {
        apply_in_full_band: true,
      }),

      pre_amplifier: Some(webrtc_audio_processing::PreAmplifier {
        ..Default::default()
      }),

      noise_suppression: Some(NoiseSuppression {
        level: noise_cancel_level, // low was lower than libwebrtc
        analyze_linear_aec_output: false,
      }),

      gain_controller: Some(GainController {
        ..Default::default()
      }),

      pipeline: Pipeline {
        maximum_internal_processing_rate:
          webrtc_audio_processing::PipelineProcessingRate::Max48000Hz,
        multi_channel_capture: true,
        multi_channel_render: true,
      },

      ..webrtc_audio_processing::Config::default()
    };

[bschwind]

Can it be related to this line: https://github.com/tonarino/webrtc-audio-processing/pull/23/files#diff-2fe5cefee42b0a50cdae6b4fe71600b8574c7127d629c49738414dd3ee45fe1aR50

I haven't actually played with the has_keyboard flag but that would definitely be the first place I look to see if it makes a difference. Set it to true and let us know if the keystroke sounds get reduced.

[morajabi]

@bschwind found the solution! turns out audio processor has a signal that you need to set before processing capture frame called set_stream_key_pressed to indicate a key was pressed in this frame. I added it in my fork and it's working well (tested on macOS)

[bschwind]

@morajabi good find! I'd be happy to review and merge the change if you put up a PR.

[morajabi]

@bschwind I'd love to but It's based on #23 what should I do?

[bschwind]

Ahhh right.

Has #23 been working well for you? I think if so, we could polish it up and merge it. We're also using this library, but we could target a specific commit or tag instead if #23 doesn't work well for us (we had run into some issues with our setup but that might be a quirk to our own systems).

@skywhale what do you think?

[morajabi]

what issues have you ran into? because I think we need to provide more fine tuning for the config. in older version, we can set stream_delay and echo cancellation level. but in #23 it's not yet handled and it has worse cross talk performance (ie. it cancels a lot of actual signal in cross talk scenarios)

I'd love to hear your findings. if you believe master provides better performance and It's not configuration issue, I can backport my changes and add key_pressed support for that and switch to it.

[bschwind]

I think overall it's like you said - more ducking, less audio clarity, but we didn't do any objective measurements on it yet.

Speaking of which, I'm not sure of the formal approaches you would take to evaluate audio quality, I've always just kind of done side-by-side listening comparisons. Maybe it's like you said, we just need to configure it more properly.

Either way, a PR on top of #23 or a PR on top of the main branch will be fine.

[morajabi]

Making a PR on top of main branch and reverting our app to use it too!