CM3 HDMI audio : bad sampling frequency and unstable audio channel status

[jeanphi-francois]

Describe the bug

When playing a sine or multitone signal (48 kHz sampling rate) into an AudioPrecision audio analyser.
Sound is played but Performance is horrible (15 % THD+N)
Sampling frequency reported by Analyzer is 50.5 kHz instead of the expected 48 kHz
Audio Status bits are not stable : The copyright, Emphasis and Category Code are moving.

Steps to reproduce the behaviour

Set Video with modetest -M vc4 -s 32:1280x720. Video is fine.
aplay --device sysdefault:CARD=vc4hdmi /tmp/channel_multitone_48k.wav

I initially doubted my aplay command, and was not sure if the right status bits were sent, so I instrumented alsalib, and the status bits are correctly set, so the vc4-hdmi.conf file is correctly used.

Device (s)

Raspberry Pi CM3+

System

OS : buildroot based
Firmware :
[ 0.070392] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-01-17T19:22:03, variant start
[ 0.080405] raspberrypi-firmware soc:firmware: Firmware hash is bd34f55ef7b01b0a367f131060b561a2a58b80bb

Kernel :
Linux isp-host 6.1.21-v4 #1 SMP Tue Sep 17 16:58:25 CEST 2024 armv7l GNU/Linux
(raspberry kernel, using KMS driver)

Alsalib is 1.2.8

Logs

No response

Additional context

I initially suspected I was maybe doing something wrong on the alsa side, so I went to the troubleshooting section of the forum.
I am now confident that it is not a bad aplay command or alsa conf issue.
Forum issue : https://forums.raspberrypi.com/viewtopic.php?t=376835

[popcornmix]

Perhaps have a read of #5525
If it is that there are a couple of workarounds in there.

[jeanphi-francois]

Yeah I read that, doesn't look like the same issue to me.

[popcornmix]

Did you try #5525 (comment)

[jeanphi-francois]

Well, I am playing at 48 Khz, so 0x2 would suit me anyway. However, I believe my alsa conf is correct, and indeed AES3 is set to 1 when entering alsa-lib. and alsa-lib version is correct, so should replace this field with the actual sampling rate.

The thing is, on the receiver side, the channel status bits are not stable. Indicated frequency is 48 kHz, but the measured frequency for the audioclock is 50.5 kHz.

[pelwell]

Does the audio analyser have an HDMI input? What's your configuration.

[jeanphi-francois]

Yes the audio analyzer has an HDMI input.

CM3+ is seated into a custom board.
HDMI of board is connected to HDMI input of Audio Precision APx 582.
Let me try with a CM4S board

[popcornmix]

I have an analyser I can check with later.
I could see csb instability when investigating the issue I linked (but only when libalsa was using the wrong sampling freq for AES). But it was stable when sample freq agreed.
I would have been testing on Pi4/5, so I can try on a Pi3.

[jeanphi-francois]

It works with a CM4S
Audio channel status are stable
THD+N is at -96 dB when playing a 16 bit file.
Audio clock is measured at 48.0005 kHz

[pelwell]

Is that running exactly the same image?

[jeanphi-francois]

Yes, same image

[jeanphi-francois]

Which aplay command should I use to play 8 channel audio ?
The iec958 plugin is always configured for two channel.

Nevermind, it looks like the alsa capabilities are set by the First EDID seen. Unplugging HDMI and replugging into another sink doesn't refresh the alsa capabilities

[popcornmix]

I normally test with speaker-test. e.g.

speaker-test -D sysdefault:CARD=vc4hdmi -r48000 -c2

My analyser shows stable csb on Pi3+ (it shows 0x4,0x82,0x0,0x2,0x2) with this command.

Is it unstable for you?

[popcornmix]

Also tried with:

aplay --device sysdefault:CARD=vc4hdmi dell/audio/testout2.wav

for 48kHz, 44.1kHz and 8 channel wav files, and all have stable csb for me.

Also tried with modetest -M vc4 -s 33:1280x720 active.

I do note you are on 6.1 kernel, and using your own builtroot.

Probably best for you to test with RPiOS bookworm (using 6.6 kernel) and see if that works for you.
If it does we can try to narrow down what is the difference (likely kernel, but could be alsa).

[jeanphi-francois]

Ok I checked with an RPI3B and I have the same issue.
I will check with 6.6 kernel