Unclear Audio for Bluetooth HFP/SCO Calls on SL1680 with MAX98357A via I2S

[VaishSPadiyappanavar]

I'm experiencing unclear (muffled, noisy) audio when routing Bluetooth Classic phone call audio (HFP/SCO) to a speaker connected to a Synaptics SL1680 processor running Linux, using BlueALSA. The audio is piped from the Bluetooth device to the speaker via I2S with a MAX98357A amplifier. In contrast, playing local .wav files (e.g., 48 kHz mono/stereo or 8 kHz mono) through the same speaker is clear, suggesting the issue is specific to Bluetooth audio handling.

Software:

OS: Linux (custom Yocto build]) Bluetooth Stack: BlueZ BlueALSA: [v3.1.0-47-gaac8742] Audio System: ALSA (no PulseAudio)

Bluetooth Device: Phone is paired and connected via HFP/SCO profile

Command Used: arecord -D bluealsa:DEV=XX:XX:XX:XX:XX:XX,PROFILE=sco -f S16_LE -r 8000 -c 1 | aplay -D plughw:0,0 -f S16_LE -r 8000 -c 1 This captures SCO audio (assumed CVSD, 8 kHz mono) and plays it on the I2S device (MAX98357A). Audio is audible but muffled/noisy, like low-quality telephony.

Issue:

Phone call audio is unclear (muffled, lacks high frequencies, some noise), unlike .wav files played via aplay -D plughw:0,0 test_8k_mono.wav (8 kHz mono, clear) or higher-rate .wav files (48 kHz, very clear). Suspected causes: CVSD codec limitations, sample rate mismatch, pipe buffering issues, or BlueALSA configuration.

Questions:

1.Is the muffled audio expected due to CVSD’s 8 kHz mono limitations, or could BlueALSA improve clarity? 2.How can I force/verify (16 kHz wideband)t in BlueALSA? 3.Are there BlueALSA options (e.g., buffer size, SCO settings) to reduce noise or improve piping? 4.Would switching to PulseAudio with BlueZ improve HFP audio routing over ALSA piping?

[borine]

BlueALSA: [v3.1.0-47-gaac8742]

That version of BlueALSA is over 4 years out of date and no longer supported. You may get better results just by updating your software.

There are some notes in the wiki about using ALSA utilities with HFP here: https://github.com/arkq/bluez-alsa/wiki/Using-BlueALSA-with-HFP-and-HSP-Devices#using-alsa-utilities-for-audio-transfer-on-an-hfp-hf-or-hsp-hs-host

You may find some of the other information on that page useful too.

2.How can I force/verify (16 kHz wideband)t in BlueALSA?

Normally when wideband is available with your bluetooth adapter, and enabled in the BlueALSA build, then mSBC codec with 16kHz sample rate is selected automatically. You can use the bluealsactl utility (called bluealsa-cli in release 3.1.0) to change the codec after connection, or with more recent versions of BlueALSA you can select the codec using a parameter to the ALSA PCM. Or you can do it the hard way using D-Bus utilities. Read the manual pages for help with any of these options.

[VaishSPadiyappanavar]

Hi,

Thanks for the clarification and the wiki reference. I’ve already updated to the latest version of BlueALSA, but the issue still persists.

My Bluetooth speaker expects mono input — only mono audio plays correctly. When I run the following command:

arecord -D bluealsa:DEV=,PROFILE=sco -f S16_LE -r 8000 -c 1
| aplay -D plughw:0,0 -f S16_LE -r 48000 -c 2

the mono stream is not being converted to stereo properly, and the audio output sounds distorted or “cartoonish.” I’m also seeing buffer underruns, and the overall volume is very low.

Any guidance on proper configuration or debugging steps would be appreciated.

[borine]

the mono stream is not being converted to stereo properly

yes, the problem is that you have misunderstood the meaning of the aplay options. For aplay the format, rate and channels options are used only to describe the input stream, for use only when the input is raw PCM with no header information. Your arecord command is using its default output type of .wav, so the stream parameters (mono, s16_le, 8000Hz) are communicated between arecord and aplay automatically as a header block written to the pipe before the actual PCM data is sent. Therefore do not use -c, -r, or -f with aplay . The plughw output device will automatically select the correct output parameters for the stream.

[VaishSPadiyappanavar]

Thanks for the clarification. I tried removing the -c, -r, and -f options from aplay as you suggested, but unfortunately the issue still persists. I'm still seeing the same behavior. Let me know if there's anything else I should check or tweak.

[borine]

If you let me know:

• the command line used for bluealsad,
• the command line that your are now using for piping from arecord to aplay,
• the outputs (with the phone connected) of:

bluealsa-aplay -L

and

amixer -D bluealsa scontents

Then I will try to reproduce this on my own system.

[VaishSPadiyappanavar]

Hi,

Thanks for offering to reproduce the setup. I found the root cause was related to mono-to-stereo conversion—the original command wasn’t handling it properly, which led to distorted, cartoonish audio. I modified the .asoundrc (or asound.conf) to handle the conversion correctly, and now the voice sounds natural. However, the speaker volume is still quite low. I’m trying to control it via the phone to keep things synchronized, especially during calls, but I’m not sure how to achieve that yet. If you’ve come across a way to sync volume control between phone and BlueALSA for call audio, I’d appreciate any pointers.

[borine]

Without knowing what you are doing, we cannot diagnose the cause of low volume. Please supply the information requested in my previous comment (and also any relevant entries in ~/.asoundrc as it now seems you are using some additional local ALSA config that you did not mention earlier) so that others can understand your setup.