Raspberry-Pi-OS-64bit
Raspberry-Pi-OS-64bit copied to clipboard
raspberrypi
No sound out of the box on lite
With kms-driver (which is the default) there's no working sound support. I can get sound to work as soon as I install pulseaudio, but without it, no sound.
kms or fkms? The two are very different.
Try diagnosing the problem a bit - what does aplay -l show? Do you have dtparam=audio=on in /boot/config.txt?
kms. Sound works fine with fkms.
pi@raspberrypi:~ $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: vc4hdmi0 [vc4-hdmi-0], device 0: MAI PCM vc4-hdmi-hifi-0 [MAI PCM vc4-hdmi-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: vc4hdmi1 [vc4-hdmi-1], device 0: MAI PCM vc4-hdmi-hifi-0 [MAI PCM vc4-hdmi-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0
pulseaudio seems to do some magic, so that when the file /etc/alsa/conf.d/99-pulse.conf exists the sound works.
pi@raspberrypi:~ $ speaker-test -c2
speaker-test 1.1.8
Playback device is default Stream parameters are 48000Hz, S16_LE, 2 channels Using 16 octaves of pink noise ALSA lib pcm_direct.c:1193:(snd1_pcm_direct_initialize_slave) requested or auto-format is not available ALSA lib pcm_dmix.c:1120:(snd_pcm_dmix_open) unable to initialize slave Playback open error: -22,Invalid argument
Even raspi-config (1. System Options -> S2 Audio ) says: No internal audio devices found
Don't you think it might be helpful if you say what hardware you are running on?
So raspi-config is correct - there is no built-in audio output (HDMI audio is classed as external).
What's in your /boot/cmdline.txt?
console=serial0,115200 console=tty1 root=PARTUUID=34d911c0-02 rootfstype=ext4 elevator=deadline rootwait quiet
But /proc/cmdline says:
coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:1920x1080M@60 smsc95xx.macaddr=DC:A6:32:D2:C2:C3 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyS0,115200 console=tty1 root=PARTUUID=34d911c0-02 rootfstype=ext4 elevator=deadline rootwait quiet
It works out of the box for me with the current Lite image - zero configuration required - but I am getting a different ALSA configuration:
pi@raspberrypi:~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: b1 [bcm2835 HDMI 1], device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
How old is your image?
...and that's because kms is not the default - vc4-fkms-v3d is. Switching to vc4-kms-v3d I get the same behaviour.
Why do you claim kms is the default? What is your reason for switching to it?
This is 2021-05-07-raspios-buster-arm64-lite, but fully updated.
I'm getting the same output as you of aplay -l if I use fkms instead of kms. But kms is the default.
dtoverlay=vc4-kms-v3d is the default setting in config.txt on 2021-05-07-raspios-buster-arm64-lite
I've accidentally just demonstrated that the problem is shared by the 32-bit Lite build when using the kms driver.
Can you post the contents of /usr/share/alsa/cards/vc4-hdmi.conf and ~/.asoundrc (if it exists).
~/.asoundrc doesn't exist. But here is /usr/share/alsa/cards/vc4-hdmi.conf:
#
# Configuration for the VC4-HDMI sound card using software IEC958
# subframe conversion
#
<confdir:pcm/front.conf>
vc4-hdmi.pcm.front.0 {
@args [ CARD ]
@args.CARD {
type string
}
type hw
card $CARD
}
# default with dmix
vc4-hdmi.pcm.default {
@args [ CARD ]
@args.CARD {
type string
}
type asym
playback.pcm {
type plug
slave.pcm {
@func concat
strings [ "dmix:" $CARD ]
}
}
}
<confdir:pcm/iec958.conf>
vc4-hdmi.pcm.iec958.0 {
@args [ CARD AES0 AES1 AES2 AES3 ]
@args.CARD {
type string
}
@args.AES0 {
type integer
}
@args.AES1 {
type integer
}
@args.AES2 {
type integer
}
@args.AES3 {
type integer
}
type iec958
slave {
format IEC958_SUBFRAME_LE
pcm {
type plug
slave.pcm {
type hw
card $CARD
}
}
}
status [ $AES0 $AES1 $AES2 $AES3 ]
}
Linux raspberrypi 5.10.52-v8+ #1440 SMP PREEMPT Tue Jul 27 09:56:40 BST 2021 aarch64 GNU/Linux
We recognised that indeed the vc4hdmi sound does not work, producing the errors reported above, when using the dmix ALSA plugin, e.g.:
pcm.!default {
type plug
slave.pcm "dmix:0,0"
}
which basically matches the default config reported above.
I checked back and with latest libasound2-data from RPi repository this has changed to not utilise the dmix plugin anymore. Is there some rationale behind this, i.e. that dmix cannot work with the KMS HDMI devices for a specific reason? Would be nice to allow multiple applications accessing the audio device without the need to either revert to legacy graphics or fake KMS or having a PA daemon running all the time.
vc4-hdmi only supports IEC958_SUBFRAME_LE.
I don't believe it's ever worked with dmix which doesn't support that format.
I believe you need a sound server (like PA) to support multiple alsa clients.
Okay, thanks for clarification. I would tend to then simply pass noaudio in every case to have more audio features and same ALSA devices regardless whether KMS is enabled or not, but it breaks at least Kodi 19.3 from RPi repository for some reason. I wonder what the benefits/reason for those dedicated vc4hdmi audio devices actually are? I've never seen such on any other system/SBC, at least it usually looks like HDMI audio is and stays the same sound device, independent of KMS.
kernel kms for video and firmware hdmi audio is not a supported use case. Some settings are interdependent. e.g. if used thi way, the N and CTS value are part of the HDMI audio settings (i.e. firmware) depend on the pixel clock which is set by a hdmi mode set (kernel) and there is no mechanism for the two sides to know what has changed.
kernel kms for video and firmware hdmi audio is not a supported use case.
Does this mean the noaudio parameter is basically obsolete/broken and shouldn't be used, or only in combination with disabling firmware HDMI audio as well? Actually I haven't tested whether noaudio alone breaks Kodi or using the firmware HDMI instead does. If the letter is true, then probably it is best to not have firmware HDMI audio enabled when noaudio is passed, but having the letter basically as general HDMI audio toggle and keep firmware HDMI disabled whenever full KMS is enabled, despite noaudio.
Are there plans to detangle this, when even possible, i.e. to support firmware HDMI with full KMS in the future?
Are there plans to detangle this, when even possible, i.e. to support firmware HDMI with full KMS in the future?
Looking at https://github.com/raspberrypi/linux/issues/4651 and https://github.com/raspberrypi/linux/pull/4652, I wouldn't think this will be changed/supported.
HDMI audio has to be configured based on the video mode that is running. Splitting that over two different processors causes more grief than it is worth, so no it won't be changed.
noaudio still disables HDMI audio on the KMS driver, so it's not broken.
vc4-kms-v3d and vc4-kms-v3d-pi4 both disable HDMI audio from the firmware audio driver whenever it is loaded, regardless of noaudio - brcm,disable-hdmi is set on the &audio DT node.
Did further testing:
-
vc4-kms-v3d,noaudioindeed disables HDMI audio completely. - But the firmware HDMI audio device still appears, with (usually default) card 0 index.
- However, playing any audio,
speaker-test,aplay, Kodi, breaks HDMI video output. The screen goes to power savings, so signal gets lost completely and at least I couldn't fine a way to recover it without a reboot. - So basically
noaudiodoes not break Kodi (symptom reported above and on forum), but it breaks HDMI video output as fast as anything tries to use the firmware HDMI audio device/card 0.
Hence, I underline by suggestion above that noaudio should not unhide the firmware HDMI audio device to prevent accidental display blanks, but vc4-kms-v3d should unconditionally remove/hide it. What do you think?