Cannot play audio via HDMI on server

[Dave Jones]

While attempting to play music as part of the ISO tests for the release, while the vc4hdmi sound card appears in /proc/asound/cards, the mpg321 player used by the tests (which has never worked *well* on the older models, but at least worked) failed with:

  [0.029s] ubuntu@miss-piggy:~$ mpg321 -o alsa -a hw:1,0 test.mp3
  High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2, and 3.
  Version 0.3.2-1 (2012/03/25). Written and copyrights by Joe Drew,
  now maintained by Nanakos Chrysostomos and others.
  Uses code from various people. See 'README' for more!
  THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK!
  Title : Love on a Real Train Artist : State Azure
  Album : Dreams A Tribute to Tangerin Year : 2020
  Comment : Genre : AmbientElectronic

  Playing MPEG stream from test.mp3 ...
  MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo
  Can't open libao driver with device hw:1,0 (is device in use?)

I also tried ffmpeg (which usually works a bit better on the older models) and that fails with a constant series of ALSA buffer xrun errors. The specific models on which this has failed so far are the 2B and 3B+. ffmpeg appears to work happily on the 4B, though.

[Ubuntu QA Website (ubuntuqa)]

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

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

[Dave Jones (waveform)]

Hmm, I may have to revise this. It seems mpg321 (with ALSA, which is how I've always tested the audio output) just doesn't work at all on any model; just complains about libao driver everywhere.

Meanwhile, ffmpeg (my backup) works happily on the 4 and 5, but just complains about buffer xrun errors on all the earlier models (and takes a bizarrely long time to respond to ctrl-C when it does).

However, aplay (ALSA's own userspace utility) works happily, at least on the 3B+ where I tested it, but only plays WAV or PCM, not MP3s, which just adds more complexity to the testing script. Still, that *suggests* ALSA's operating correctly and perhaps it's just ffmpeg trying to allocate a buffer that's too small to avoid overrun on the older platforms (and mpg321's presumably just broken on noble).

I'll leave this open for now, but I'd advise the kernel team to ignore it while I dig a bit deeper.

[Dave Jones (waveform)]

Another interesting data-point: apparently mpg321 *isn't* broken on noble. It works, but only with the headphone output (on those models that have it, i.e. everything prior to the Pi 5). Same goes with ffmpeg; no buffer xruns when outputting to the headphone socket.

Which leans me back towards "something iffy with vc4hdmi and ALSA"...

[Dominik Viererbe (dviererbe)]

Had the same issue on a Raspberry Pi 3 B

[Pragyansh Chaturvedi (r41k0u)]

I tried this on a 3B+ using the Noble .2 image. It looks like there is audio through HDMI now, but it is very choppy and slowed down (slowed tempo).

[Pragyansh Chaturvedi (r41k0u)]

This has been resolved now, at least for the ISO Tests.