External audio CODEC (ADI ADAU1977) sampling rate wrong value on STM32MP157-DK2

[StefanC]

Dear STM engineers and community,

I'm working with STM32MP157-DK2 (Developer-Package 1.2) and an evaluation board for ADAU1977 ADC from Analog Devices. Desired setup entails using the external codec as the master of I2S communication (the same as with the onboard Cirrus codec on the board).

Following the great documentation provided by the wiki pages (kudos to the teams working on that!) I have almost managed to get everything working perfectly.

In order to get to this point I have done the following:

1. Desoldered SB1 through SB4, and then soldered SB13 through SB16 in order to disconnect onboard codec from SAI2 and access it from the GPIO header
2. Added the codec_of_xlate_dai_id in the source of the manufacturers driver according to: https://wiki.st.com/stm32mpu/wiki/SAI_device_tree_configuration
3. Included the source files of the edited codec driver through kconfing and menuconfig and configured them as modular
4. Edited the device tree (stm32mp157c-dk1.dts) according to all available documentation regarding audio-graph-card and practically changed all the entries regarding the onboard cirrus codec to fit my setup

After all of that I have run into a couple of problems, and after a week or so, I am practically clueless of where to go next.

First (and a lesser) problem that I have encountered is that the soundcard isn't being registered automatically on boot, which it should be since it's configured in the device tree.

I can go around that problem by manually loading the manufacturers module using modprobe. After that, everything is loaded properly, and I can change all exposed parameters with alsamixer, record on all 4 channels but...

The other problem and a much bigger one is that the codec is working with the sampling rate of 48kHz (verified with a oscilloscope) which is what i want, but the ALSA subsystem "thinks" it is working on 44.1kHz. I have tried to record in 48kHz by using alsa-tools like arecord with option -r 48000 and it returns: "Warning: rate is not accurate (requested = 48000Hz, got = 44100Hz)".  I can record, but the audio is transposed by 44.1/48 i.e. if I am recording a sine of 440Hz, the recorded file contains a sine of ~404Hz. I have also tried to record using ALSA API in my own C project but the system still reports 44.1kHz.

By inserting a few printk-s in source files of codec drivers and platform drivers (adau1977.c and audio-graph-card.c) I have found that the parameters passed on to both the audio graph card and ADAU1977 module contain the rate of 44100 which is accessed by calling params_rate(snd_pcm_hw_params *params).

Is there something that I missed? What is the source of hw_params structure?

Best regards,

Stefan

[Olivier GALLIEN]

Hi @StefanC​ 

Here is one clue given by expert :

"Quickly look at ADAU1977 codec. Please check adau1977_set_sysclk function. It's here that codec set supported frequency following source clock ( MCLK or LR) .

Suspect can be here that max freq is clamp in case MCLK not in expected range.

Else please share DT in order we can check it and particularly mclk-fs field"

Hope it help

Olivier

[Olivier GALLIEN]

The message "Warning: rate is not accurate (requested = 48000Hz, got = 44100Hz)" suggests that when the application

negotiates the rate, the 48000Hz appears as not supported.

This may occurs for instance because the codec drivers does not support 48000Hz.

A general mean to debug this, is to trace hardware param negotiation at startup of the record.

See: https://wiki.st.com/stm32mpu/wiki/ALSA_overview#Activate_PCM_hardware_parameter_traces

The dynamic traces may help as well: https://wiki.st.com/stm32mpu/wiki/ALSA_overview#Dynamic_traces

If Pulseaudio is running, it can be useful to disable it first.

[StefanC · Accepted solution]

Hi @Community member​ ,

Thank you so much for your prompt response!

Before your messages here I made headway by hardcoding a constraint mask in the adau1977_set_sysclk function mentioned by the expert (that's the one that I was also looking into the whole time). That way I got the system to work at 48kHz.

I wanted to look at the links you provided for tracing, but since the STM32MPU wiki was down for me up until a few minutes ago, while I waited I took more notice to the last thing you wrote.

I have thought that I have disabled Pulseaudio, by editing the /etc/pulse/client.conf with: 

autospawn = no

allow-autospawn-for-root = no

But it appears that an additional few steps were needed because of systemd.

So I had to also turn off daemonization in the conf file and have also masked it with systemctl.

And now it just works, so it looks I have lost a lot of time debugging ASoC and ALSA, when the problem the whole time was caused by Pulseaudio!

The only thing now is that the audio card isn't being registered on boot until I manually do a modprobe.

Again, thank you so much! Combination of your clue and STM32MPU wiki being down solved my problem.

Best regards,

Stefan