GMF capture defaults to Opus VBR mode causing audio glitches with AEC VC mode

[markotokyo]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate
• Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
• Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

always

Expected behavior

After switching to the GMF-based esp_capture (v0.7.4), OPUS audio encoding should work without audio glitches using the default Opus VBR configuration, just like the pre-GMF capture system.

Actual behavior (suspected bug)

After migrating to GMF capture, audio glitches occur that were not present in the pre-GMF esp_capture system. The audio glitches appear specifically during loud sounds and consonants when using AEC in VC mode.
We traced the issue to VBR mode being enabled by default (bitrate = 0). Forcing CBR mode (bitrate = 90000, enable_vbr = false) eliminates the glitches.

Configuration results:
NEW GMF with VBR (default) and AEC VC mode → glitches during loud sounds and consonants
NEW GMF with CBR (forced) and AEC VC mode → no glitches
NEW GMF with VBR (default) and AEC SR mode → no noticeable glitches
OLD pre-GMF esp_capture with VBR and AEC VC mode → no glitches
OLD pre-GMF esp_capture with CBR and AEC VC mode → no glitches

Error logs or terminal output

No errors are logged.

Steps to reproduce the behavior

1. Use ESP32-S3 with esp-webrtc-solution
2. Use GMF-based esp_capture v0.7.4 with default configuration (latest build)
3. Enable AEC in VC mode
4. Establish a WebRTC call
5. Speak loudly or pronounce consonants (p, t, k, s)
6. Observe audio glitches or crackling during these sounds

Verify the fix:
Modify managed_components/espressif__gmf_audio/esp_gmf_audio_enc.c:

opus_enc_cfg.bitrate = 90000; // Force CBR
opus_enc_cfg.enable_vbr = false; // Disable VBR
opus_enc_cfg.application_mode = ESP_OPUS_ENC_APPLICATION_AUDIO;

Project release version

Latest

System architecture

Intel/AMD 64-bit (modern PC, older Mac)

Operating system

MacOS

Operating system version

ESP IDF 5.4.1

Shell

ZSH

Additional context

No response

[TempoTian]

@markotokyo Thanks for your detail info. I will try local to reproduce it.
For fast location, is it possible to provide old GMF and new GMF dependency module version for: esp-sr and esp_audio_codec, (version info can be found in dependency.lock)? Currently only these 2 module most probably cause the issue.

[markotokyo]

The working build without glitches is from July 23, 2025. That version still uses the pre GMF esp_capture implementation, before the GMF esp_capture integration was committed on August 22.
The non working build (the latest commit) uses GMF esp_capture v0.7.4.
Both builds use esp_audio_codec 2.3.0.
The working build uses esp-sr 1.9.5, and the non working build uses esp-sr 2.1.5.

But we believe the issue is not related to the esp-sr version because we replaced the GMF esp_capture v0.7.4 in the latest build with the pre GMF esp_capture from the July 23 build, and that completely eliminated the glitches.

So the issue appears to come from somewhere inside the new GMF based esp_capture module. We captured audio at the AEC output and at the Opus encoder output. The AEC output is clean, but the decoded Opus output has glitches in VBR mode, so the issue is somewhere in the encoding path between AEC and the Opus encoder.

[majingjing123]

@markotokyo
I found in your description that when you configure CBR, the bitrate is set to 0, which may not be very correct. You can refer to the suggestions in the header file 'esp_opus_dec. h' for configuration