No alsa sound cards on Pi 5

(incidentally, the issue appears specific to the 5 -- hasn't occurred on the 4's I've tested so far)

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
https://iso.qa.ubuntu.com/qatracker/reports/bugs/2038924

Status changed to 'Confirmed' because the bug affects multiple users.

On Pi 4 server with a monitor attached:

$ cat /proc/asound/cards
 0 [b1 ]: bcm2835_hdmi - bcm2835 HDMI 1
                      bcm2835 HDMI 1
 1 [Headphones ]: bcm2835_headpho - bcm2835 Headphones
                      bcm2835 Headphones

On Pi 4 desktop:

$ cat /proc/asound/cards
 0 [Headphones ]: bcm2835_headpho - bcm2835 Headphones
                      bcm2835 Headphones
 1 [vc4hdmi0 ]: vc4-hdmi - vc4-hdmi-0
                      vc4-hdmi-0
 2 [vc4hdmi1 ]: vc4-hdmi - vc4-hdmi-1
                      vc4-hdmi-1

On Pi 5 server:

$ cat /proc/asound/cards
--- no soundcards ---

On Pi 5 server with 'dtoverlay=vc4-kms-v3d':

$ cat /proc/asound/cards
 0 [vc4hdmi0 ]: vc4-hdmi - vc4-hdmi-0
                      vc4-hdmi-0
 1 [vc4hdmi1 ]: vc4-hdmi - vc4-hdmi-1
                      vc4-hdmi-1

Audio on Pi 5 is via hdmi, so a different driver. If that driver is not loaded, no sound cards are listed. That is expected, no?

I'm currently investigating switching the server images to load the kms overlay by default (they don't currently). This does appear to fix the issue, in that the vc4-hdmi ports show up in /proc/asound/cards once the overlay is loaded. Unfortunately, it also appears to break boot on the 512MB 3A+ with an out of memory kernel oops. Bizarrely, the Zero 2W (which also has 512MB of RAM) continues to boot just fine with the change, so I'm not entirely sure why the 3A+ is breaking...

Argh, another wrinkle in this story: during ISO testing of the server images, I also tried the audio output tests with both the current setup (framebuffer driver) and the intended setup (KMS driver). The KMS driver works happily for audio output on the Pi 4 and 5. But on the 3B+, it throws the following error in mpg321:

    $ mpg321 -o alsa -a hw:1,0 test.mp3
    ...
    Can't open libao driver with device hw:1,0 (is device in use?)

The device isn't (to the best of my knowledge) in use, as this is directly after boot-up. Attempting output to the same device with ffmpeg results in no sound, and numerous ALSA buffer xrun reports:

    $ ffmpeg -i test.mp3 -f alsa default:
    ...
    [alsa @ 0xaaaae49062f0] ALSA buffer xrun.N/A speed= 0x
        Last message repeated 6 times
    [alsa @ 0xaaaae49062f0] ALSA buffer xrun.ed=0.743x
        Last message repeated 6 times
    [alsa @ 0xaaaae49062f0] ALSA buffer xrun.ed=0.553x
        Last message repeated 1 times

The content of /proc/asound/cards on the machine is:

    $ cat /proc/asound/cards
     0 [Headphones ]: bcm2835_headpho - bcm2835 Headphones
                          bcm2835 Headphones
     1 [vc4hdmi ]: vc4-hdmi - vc4-hdmi
                          vc4-hdmi

I can accept that using KMS is the way forward, and the "proper" solution to the lack of soundcards on the Pi 5. But if we go this route, we also need to avoid breaking audio output on the older platforms too.

Similar results on the 3A+ under the KMS overlay (with cma-128 to ensure it boots, re LP: #2060300); except here ffmpeg results in:

    [alsa @ 0xaaaad948a930] ALSA buffer xrun
    [alsa @ 0xaaaad948a930] ALSA write error: Cannot allocate memory
    [aost#0:0/pcm_s16le @ 0xaaaad94c5a30] Error submitting a packet to the muxer: Input/output error
    [out#0/alsa @ 0xaaaad94a5070] Error muxing a packet

And the following appears in dmesg:

    [ 118.466695] vc4_hdmi 3f902000.hdmi: ASoC: error at soc_component_trigger on 3f902000.hdmi: -12
    [ 118.468527] vc4_hdmi 3f902000.hdmi: ASoC: error at soc_component_trigger on 3f902000.hdmi: -12

Patched in pi-gadget classic branch with commit https://github.com/snapcore/pi-gadget/commit/cebff92bd4b67d1bfffab5d98cdcefa38809b62e