ΣSigmaStudio Ask AI Русский Log in

Optimization of ADAU1701 Audio Processing with BM83 – Volume Discrepancies Across Bluetooth Devices

SigmaDSP & SigmaStudio denivie Feb 13, 2025 00:00 1 replies Original on forum ↗
Subscribe
denivie Question
Feb 13, 2025 00:00

Dear Analog Devices Support Community,

We are currently integrating the ADAU1701 DSP in our product alongside the BM83SM1-00AB Bluetooth module, which serves as the master Bluetooth interface and codec source. Our system also includes an ESP32-S2-WROVER for control and a TPA3118 amplifier, which is connected to the ADAU1701 for final audio output.

During testing, we have observed notable differences in audio output levels depending on the connected Bluetooth source device.

System Configuration Overview

BM83SM1-00AB – Bluetooth audio module (), handles Bluetooth connectivity, codec processing, and AVRCP volume control.

ESP32-S2-WROVER – Microcontroller used for system control, communication, and user interface functions.

ADAU1701 – DSP (), responsible for all signal processing, including equalization, filtering, and possible gain control.

TPA3118 – Class-D audio amplifier connected to the ADAU1701, used to drive speakers.

Key Observations

Volume Differences Across Devices

Apple devices (iPhone, iPad, MacBook) output significantly louder audio compared to Android devices.

This discrepancy appears to be independent of the codec used (AAC/SBC).

Some Android devices, like the Samsung S24, recognize our device as a speaker and allow full volume output, while others, such as Redmi 10 Pro, initially limit the volume until manual adjustments are made in system settings.

Potential Causes Under Investigation

Signal processing within the ADAU1701: Could there be differences in how incoming Bluetooth audio signals are interpreted by the DSP?

Gain staging between BM83 and ADAU1701: Are there best practices for ensuring a consistent signal path?

Operating system behavior: Some systems may apply automatic gain control (AGC), normalization, or volume caps based on the reported volume levels from BM83.

AVRCP 1.6 volume scaling: We are investigating whether incorrect AVRCP volume mapping could be influencing the perceived output.

Optimization Goals
Our objective is to achieve consistent and maximized audio performance across all source devices while maintaining optimal volume and sound quality.

Questions for Support

DSP Configuration for Volume Normalization:

Are there specific filters, gain structures, or signal path optimizations within the ADAU1701 that could help equalize volume levels across different Bluetooth sources?

Would adjusting input gain scaling, limiter thresholds, or compression settings be beneficial?

Automatic Gain Control (AGC) and Dynamic Processing:

Would enabling AGC or dynamic range compression within the ADAU1701 help mitigate these discrepancies?

If so, what would be the recommended AGC settings to balance volume levels while preserving audio dynamics?

Gain Staging Between BM83 and ADAU1701:

Could the BM83 output levels be mismatched with the ADAU1701 input sensitivity?

Are there recommended gain settings or attenuation adjustments we should apply to ensure optimal signal levels?

Debugging and Monitoring Input Levels:

What tools or methods would you recommend for monitoring and analyzing the input levels coming from BM83 into ADAU1701?

Are there registers within the ADAU1701 that can help us track and adjust real-time signal levels?

AVRCP 1.6 Volume Mapping:

We currently scale volume levels from 0 to 128 across 16 steps.

Are there recommended mapping strategies to ensure accurate Bluetooth volume control across various devices?

Could incorrect volume step mapping be causing Apple and Android devices to behave differently?

Codec-Dependent Volume Variations:

Do different Bluetooth codecs (AAC vs. SBC) inherently apply different gain structures, and should we compensate for these within ADAU1701?

For reference, our product integrates BM83 as the primary Bluetooth module, while ADAU1701 handles all downstream signal processing. You can find additional details about our product at

We appreciate your guidance in fine-tuning our setup to ensure the best possible audio performance across all platforms. Please find our DSP configuration files attached for your review.

Edit Notes
Removed link to vendor - violates EngineerZone Code of Conduct

[edited by: GenevaCooper at 1:43 PM (GMT -5) on 14 Feb 2025]

Audio Signal Processors

Datasheet/Specs

SigmaDSP Audio Processors

adau1701

4745.schematic.png
4745.schematic.png
DaveThib Reply
Feb 17, 2025 00:00

Hello denivie

There is so much to unfold here. The 1701 will just process the audio being sent to it and send it to the output. Any differences between codecs used and anything else with the Bluetooth standard is outside of the influence of the DSP.

One easy way is to look at the I2S data on a scope but then I am a geek enough to quickly "see" that the audio level is high or low by looking at the bits. I look at this stuff on a daily basis. I did write this post which shows how to setup a scope to read this stuff. (+) How to Take Meaningful Screenshots of I2S Audio Signals - Q&A - Audio - EngineerZone

But, I think you should simply put in a meter in your DSP project that reads the level of the audio coming into the DSP. Then just like SigmaStudio can poll the meter for its data your system controller can poll the meter for level data. SigmaStudio reads the meter every 10ms so it does not miss any peaks. The meters are programmed to accumulate and get the RMS value over that period of time. I have explained some of this on my YouTube channels but not in great detail yet. You should watch the video about the Capture/Params/Sequencer windows. This helps gain an understanding of what the blocks are doing and what is available to read by a system controller.

Your block diagram shows volume up/down going over I2S? Is control data somehow appended to the actual audio? I have seen where 24 bit audio has data appended to it to fill out the 32 bit channel slot. Is that going on? Otherwise, the gain up/down should come over the I2C port to control the DSP.

Yes, you could implement an AGC of some kind but to have it not be too audible then it has to have a super slow time constant and so it will slowly come up or distort for a little while as it slowly goes down. Both of these are not great. If you can recognize what the source is and be able to just change the volume before you even begin to play the audio then that is preferred.

Feel free to PM me because this conversation will get into proprietary details rather quickly. Just make sure to also send a friend request or I will not be able to respond.

Dave T