2022-03-30 12:45 PM
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:
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:
Solved! Go to Solution.
2022-04-20 06:56 AM
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
2022-04-19 09:07 AM
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
2022-04-20 06:56 AM
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
2022-04-20 07:28 AM
Hi @KDehm ,
Good news and thank you for the feedback that will surely help other people :)
Best Regards,
Kevin