AV amplifier turns on but no sound, since libCEC update

[UnasZole]

I'm using :

• A Raspberry Pi with Raspberry Pi OS, including libCEC
• A Yamaha RX-V675 receiver.

On Raspberry Pi OS Buster, with libCEC 4.0.4, everything was working fine.

Since I upgraded to Raspberry Pi OS Bullseye, with libCEC 6.0.2-2, I cannot get my receiver to output anything when it's powered on by libCEC. I have to put it manually in stand by and wake it manually to get sound working.

More specifically, I'm using cec-client to test it :

• I start my raspberry pi, leaving the receiver in standby
• I start some sound on the raspberry pi (eg a long youtube video).
• I start cec-client
• I send "scan" to locate my receiver, and I get

device #5: Audio address: 1.0.0.0 active source: no vendor: Yamaha osd string: RX-V675 CEC version: 1.4 power status: standby language: ???

• I send "on 5". The receiver turns on, but no sound. Output was :

DEBUG: [ 26472] expected response not received (82: active source) on 5 DEBUG: [ 79206] << requesting power status of 'Audio' (5) TRAFFIC: [ 79206] << 15:8f DEBUG: [ 79259] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT - tx_status=01 len=2 addr=15 opcode=8f DEBUG: [ 79354] CLinuxCECAdapterCommunication::Process - ioctl CEC_RECEIVE - rx_status=01 len=3 addr=51 opcode=90 TRAFFIC: [ 79354] >> 51:90:01 DEBUG: [ 79354] expected response received (90: report power status) NOTICE: [ 79354] << powering on 'Audio' (5) DEBUG: [ 79354] >> Audio (5) -> Recorder 1 (1): report power status (90) TRAFFIC: [ 79354] << 15:44:40 DEBUG: [ 79441] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT - tx_status=01 len=3 addr=15 opcode=44 TRAFFIC: [ 79441] << 15:45 DEBUG: [ 79508] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT - tx_status=01 len=2 addr=15 opcode=45 DEBUG: [ 79543] CLinuxCECAdapterCommunication::Process - CEC_DQEVENT - CEC_EVENT_STATE_CHANGE - log_addr_mask=0000 phys_addr=ffff DEBUG: [ 81021] CLinuxCECAdapterCommunication::Process - CEC_DQEVENT - CEC_EVENT_STATE_CHANGE - log_addr_mask=0000 phys_addr=1100 DEBUG: [ 81155] CLinuxCECAdapterCommunication::Process - CEC_DQEVENT - CEC_EVENT_STATE_CHANGE - log_addr_mask=0002 phys_addr=1100 DEBUG: [ 81997] CLinuxCECAdapterCommunication::Process - ioctl CEC_RECEIVE - rx_status=01 len=2 addr=51 opcode=46 TRAFFIC: [ 81997] >> 51:46 DEBUG: [ 81997] << Recorder 1 (1) -> Audio (5): OSD name 'CECTester' TRAFFIC: [ 81997] << 15:47:43:45:43:54:65:73:74:65:72 DEBUG: [ 81997] >> Audio (5) -> Recorder 1 (1): give osd name (46) DEBUG: [ 82276] CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT - tx_status=01 len=11 addr=15 opcode=47

• I can send the receiver back to standby, either manually or with "standby 5"
• Then, if I turn the receiver on manually, sound works fine.

Note that I've tried pretty much all other cec-client commands :

• as and is (to declare active/inactive source) have no effect
• volup, voldown, mute work "fine", in that the receiver reacts and the OSD reports the new volume/mute setting. But even unmuting does not actually bring the sound back.

Honestly, at first glance it looks like a quirk in the CEC implementation of the receiver... But I had no problem with libCEC 4.0.4 before. Did anything change in the signals sent by the "on" command between 4.0.4 and 6.0.2 ?

[popcornmix]

Are you able to build libcec from source? If so you could narrow down which commit introduced the issue. E.g. check 4.0.4 works and 6.0.2 fails, and then build from a commit between the two.

[UnasZole]

Well, I wasn't planning on installing gcc on my raspberry pi, but I could try, if you can give me a few pointers on the simplest way to compile and test the lib and the cec-client :-)

Before installing all this, though, I just tried checking if I could replicate the working case by using the 4.0.4 files from debian buster's deb archives, but it won't even detect the devices. With the cec-client 4.0.4 binary and the so lib from debian buster in the same folder :

pi@dhd:~/cec-experiments/4.0.4 $ LD_LIBRARY_PATH=. ./cec-client -l libCEC version: 4.0.4, compiled on Linux-4.9.0-8-arm64 ... , features: P8_USB, DRM, P8_detect, randr, Exynos, AOCEC Found devices: NONE

Whereas using the cec-client installed by RaspiOS :

pi@dhd:~/cec-experiments/4.0.4 $ cec-client -l libCEC version: 6.0.2, compiled on Linux-5.4.0-72-generic ... , features: P8_USB, DRM, P8_detect, randr, RPi, Exynos, Linux, AOCEC Found devices: 2

device: 1 com port: /dev/cec0 vendor id: 0000 product id: 0000 firmware version: 0 type: Linux

device: 2 com port: /dev/cec1 vendor id: 0000 product id: 0000 firmware version: 0 type: Linux

Do you have any idea why the old lib can't see the devices ? Before I install everything to compile the lib and such, I'd like to make sure that there isn't a bigger blocker preventing me from testing old lib versions ! :-)

[popcornmix]

Bullseye uses the kms driver by default, buster uses fkms. Older libcec will only support fkms. Can you change dtoverlay=vc4-kms-v3d in config.txt to dtoverlay=vc4-fkms-v3d and test with both new (6.0.2) and older (4.0.4)?

[UnasZole]

I just tried switching to fkms as you described.

Test with 4.0.4 is the same, it still doesn't find any device :

LD_LIBRARY_PATH=. ./cec-client -l libCEC version: 4.0.4, compiled on Linux-4.9.0-8-arm64 ... , features: P8_USB, DRM, P8_detect, randr, Exynos, AOCEC Found devices: NONE

Interestingly, the test with 6.0.2 changed, it now detects only one device, and with the proper info (whereas with kms all cec devices had null info) :

pi@dhd:~ $ cec-client -l libCEC version: 6.0.2, compiled on Linux-5.4.0-72-generic ... , features: P8_USB, DRM, P8_detect, randr, RPi, Exynos, Linux, AOCEC Found devices: 1

device: 1 com port: RPI vendor id: 2708 product id: 1001 firmware version: 1 type: Raspberry Pi

Problem is, this time I don't have any sound on HDMI at all, whether I wake my receiver manually or with the "on" command. Is there another config needed to get audio out on HDMI with fkms ?

And for what it's worth, the on command is a lot less verbose :

on 5 NOTICE: [ 43182] << powering on 'Audio' (5) TRAFFIC: [ 43182] << 15:44:40 TRAFFIC: [ 43273] << 15:45 DEBUG: [ 44831] GetPhysicalAddress - physical address = 1100

[popcornmix]

Test with 4.0.4 is the same, it still doesn't find any device : LD_LIBRARY_PATH=. ./cec-client -l libCEC version: 4.0.4, compiled on Linux-4.9.0-8-arm64 ... , features: P8_USB, DRM, P8_detect, randr, Exynos, AOCEC Found devices: NONE

That hasn't been built with RPi support configured. i.e. I guess it's upstream debian rather than a raspbian/rpios build.

[UnasZole]

Oh, my bad, I didn't realise the RPi build was specific.

I've just downloaded 4.0.4 and 4.0.7 from the raspberrypi.org packages, and indeed this is better, if only slightly.

So here are the results so far :

• On KMS,
  • 4.0.4 does not start (could not open a connection), which is expected.
  • 4.0.7 and 6.0.2 both have the issue described (no sound if receiver woken by CEC, but sound works if receiver woken manually)
• On FKMS, all 3 versions start fine, but I don't get any sound at all, no matter how I wake my receiver, so I can't confirm if the issue is present.

Only a small difference in logs between the 3 versions on FKMS, probably insignificant : a debug line "physical address unchanged"

4.0.4 on FKMS

on 5 NOTICE: [ 36873] << powering on 'Audio' (5) TRAFFIC: [ 36873] << 15:44:40 TRAFFIC: [ 36971] << 15:45 DEBUG: [ 38541] GetPhysicalAddress - physical address = 1100 DEBUG: [ 38541] physical address unchanged (1100)

4.0.7 and 6.0.2 on FKMS

on 5 NOTICE: [ 36806] << powering on 'Audio' (5) TRAFFIC: [ 36806] << 15:44:40 TRAFFIC: [ 36898] << 15:45 DEBUG: [ 38387] GetPhysicalAddress - physical address = 1100

I guess to progress more I'd have to understand why I get no sound at all when in FKMS :-/

[popcornmix]

On FKMS, all 3 versions start fine, but I don't get any sound at all

make sure you have dtparam=audio=on in config.txt and you are using the right alsa device (it's a different device when using kms or fkms).

[UnasZole]

Ok, I got sound in FKMS after switching the pulse audio sink with

pactl set-default-sink alsa_output.platform-bcm2835_audio.digital-stereo

But the result is that all versions of cec-client have the same issue, even 4.0.4 !

So I guess it's probably not an issue on libcec itself, but something else that changed in the environment. Since I went from Buster 32-bit to Bullseye 64-bit, that doesn't narrow it down too much.

Not sure what could possibly be the cause for this strange behaviour, then. If it's not a change in the signals sent by libCEC to the receiver... could it be the opposite ? Maybe my receiver sends a signal on HDMI when woken up manually, and doesn't when woken up by CEC ?

Do you know if pulseaudio/alsa or even the linux Kernel expects some signal from the HDMI target to know if it supports audio, or something like this - that my receiver might omit to send if it's woken up by CEC ?

[popcornmix]

Can you re-test buster 32-bit? I have a suspicion it also won't be working, and the issue is in the settings of the CEC devices (AVR/TV).

[UnasZole]

Hi,

Sorry for the long absence. I got busy with many other things, and then kind of got used to turning on my AV receiver manually and forgot about the topic.

I just had another look today, and indeed, it's probably not linked to libcec after all. What I observed after trying many configurations is that basically, if the TV is turned on before the AVR is woken up by CEC, then I get the no sound issue, until I reboot either the TV or the AVR. Whereas if I turn on the TV after the AVR, then the AVR starts outputting sound.

So it's definitely something weird with the AVR itself, which for some reason expects some kind of signal from the TV before outputting sound when it's been woken up via CEC. And maybe the thing that changed when I upgraded my Pi is just the order in which Kodi sends CEC events or something. (maybe kodi was waking up the AVR first before, and now the TV first, or whatever).

I don't have a spare microSD card to try again with Buster, but in any case, this seems really specific to my hardware... So I guess I'll just close the ticket. I'll just have to live with it ^^