Audio Codec configuration for 44100Hz sample rate on STM32MP1 - difficulties with Bluetooth Audio Streaming

[KDehm]

Dear community,

I once again need your help. 🙂

I'm using a TAS5760L on a custom board with STM32MP157 MPU and Yocto-Linux, Dunfell.

Since the codec is not part of the available Linux kernel audio codecs, a simple spdif-codec (inux,spdif-dit) with I2S signal is used to send data to the TAS5760L.

Audio is working quite well when playing wav-files with aplay. But I recognised, that the Frame Sync (FS, or LRCLK) is always at 48kHz, no matter what is configured in the device tree or in /etc/alsa.conf.

Background:

For aplay this doesn't matter much, but if audio is streamed via Bluetooth (at 44.1kHz) there is a difference in sample rates, which results in the following error:

"An underrun has occurred". This error occurs cyclically about every 7 seconds and a glitch/stutter can be heard then in the audio.

I use bluez-alsa (bluealsa/bluealsa-aplay) to send audio stream from for example a smartphone to the board. Here is some more information:

• Bluetooth module has CYW4343W chipset (same as the STM32MP157-DK2)
• BT audio stream comes via UART/A2DP 
• If the BT audio stream is captured with arecord (arecord -D bluealsa capture.wav), the resulting wav-file is glitch-free.
• Bluetooth audio streaming works glitch-free on the STM32MP157-DK2 with the same configuration/frameworks (bluez-alsa, UART/AD2P, Linux Kernel: 5.10)

My question now: 

I think the "underrun" is caused by the differences of the sample rates. How can I set LRCLK of my audio codec to 44.1kHz? Or asked differently: Why do I always measure 48kHz there, no matter how I configure?

I would be very grateful for any help or tips regarding this issue.

Appendix

Device Tree snippet:

	/* Sound interface */
	sound {
	#address-cells = <1>;
        #size-cells = <0>;
	compatible = "simple-audio-card";
 
	simple-audio-card,name = "TAS5760L";
	simple-audio-card,dai-link@0 {
	    reg = <0>;
	    format = "i2s";
	    bitclock-master = <&sound1_cpu>;
	    frame-master = <&sound1_cpu>;
	    mclk-fs = <256>; /*factor x for mclk  = x*fs (framesynchro clock)*/
 
	    sound1_cpu: cpu {
				sound-dai = <&sai3b>;
			};
			codec {
				sound-dai = <&codec_out>;
			};
            };
	};
	codec_out: spdif-out {
                #address-cells = <0>;
                #size-cells = <0>;
                #sound-dai-cells = <0>;
                compatible = "linux,spdif-dit";
                status = "okay";
            };
};

Asound.conf;

defaults.pcm.card 0
defaults.ctl.card 0
defaults.pcm.rate_converter "linear"
 
pcm.tas5760l {
  type hw
  card 0
  device 0
}
 
pcm.dmixer {
  type dmix
  ipc_key 4096
  ipc_perm 0666
  slave.pcm "tas5760l"
  slave {
    period_time 1000000
    period_size 2048
    buffer_size 5000000
    format S16_LE
  }
  bindings {
    0 0
    1 1
  }
}
ctl.dmixer {
  type hw
  card 0
}
pcm.softvol {
  type softvol
  slave.pcm "dmixer"
  control {
    name "Softvol"
    card 0
  }
  min_dB -70.2
  max_dB -0.0
}
pcm.bluetooth_softvol {
  type softvol
  slave.pcm "dmixer"
  control {
    name "Bluetooth_Vol"
    card 0
  }
  min_dB -70.2
  max_dB -0.0
}
pcm.!default {
  type plug
  slave.pcm "softvol"
}
pcm.bluetooth {
  type plug
  slave.pcm "bluetooth_softvol"
}
 
defaults.bluealsa.interface "hci0"
defaults.bluealsa.profile "a2dp"

Block diagram of the setup:

[Kevin HUBER]

Hello @KDehm​ ,

I'm not an audio expert, but I will try to help you and maybe our exchanges will inspire someone in the community who will have an answer.

In your Device Tree snippet, I can see that you are using the "simple-audio-card" driver.

The simple-card is not the recommended way, the "audio-graph-card" should be used instead, like it's already done in stm32mp15xx-dkx.dtsi with the STM32MP157-DK2 where it works.

Please can I have your DTS and your complete DTB?

And your complete boot log traces?

Regards,

Kevin

[KDehm · Accepted solution]

Thank you @Kevin HUBER​ for your answer.

Meanwhile I solved the problem.

I could now clearly determine the cause of the "underrun" and have found a solution. There are no more glitches in the audio stream.

Problem was actually the sample rate conversion. But not in userspace (alsa.conf), but on a lower level → at the clocks initialization of the SAI interface (Serial Audio Interface) in the Device Tree. The clocks of our SAI channel (SAI3) were not configured correctly by CubeMX, which is why 48kHz always arrived at the frame sync (LRCLK) of the audio codec, even if 44.1kHz was set in alsa.conf. An adjustment of the SAI clocks to the configuration of the STM32MP Discovery Kit (they use SAI2) then showed: The audio stream to the codec generates the desired sample rate of 44.1kHz.

The system runs now with a static sample rate setting, no more "underruns" occur. Whether there is also a way for a dynamic configuration remains open for now.

Maybe someone else will stumble across this problem as well. 

Best 

Kai

[Kevin HUBER]

Hi @KDehm​ ,

Good news and thank you for the feedback that will surely help other people 🙂

Best Regards,

Kevin