HDMI audio and analog audio do not work on Opi5Plus

[ずっと一人]

I have built and used it with the latest source and still HDMI audio and analog audio does not work.

Is there any way to get HDMI audio to work other than using the vendor kernel?

[Werner]

May work once rockchip64 has been bumped to 6.15

https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md

[Guest]

The hardware driver support listed at Collabora in the Linux kernel will have nothing to do with the Linux distro base, like Debian or Ubuntu?

[ずっと一人]

I built and tested it with the rc version of kernel 6.15 
it works.
Waiting for Armbian to support 6.15😄

[ricardo_brz]

Armbian already is!

 

uname -a
Linux orangepi5-plus 6.15.0-edge-rockchip64 #1 SMP PREEMPT Sun May 25 23:09:23 UTC 2025 aarch64 GNU/Linux

 

Itś on edge, but it's working fine here, apart from the analog audio...
 

[EricaLina]

That doesn't work then. The point is to get audio working. We still have a bit of a wait until a proper 6.15 kernel is there.

[Werner]

HDMI audio has been merged into 6.15. Board may need additional device tree nodes to make it work.

Analog audio should work already as well bug may also need additional nodes. Collabora sent for Rock5B and 5B+ only upstream.

https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md

[ricardo_brz]

I think I wasn't clear: HDMI audio is working, built-in audio is not. I'm using the latest edge image from Armbian that is 6.15.

 

It's strange that I can see in Gnome Config the audio ports correctly HDMI and Built-In.

 

 

 

 

Edited June 6 by ricardo_brz

[Igor]

19 minutes ago, ricardo_brz said:

built-in audio is not

I think this is handled with overlay "audio" "analogue" or something similar.

https://docs.armbian.com/User-Guide_Armbian-Config/System/#device-tree-overlays

[The Tall Man]

ES-8388 Analog Audio Works At Fractional Volume (a possible solution)

The issue of no ES-8388 analog audio output has been dragging on for months, and in all three kernel flavors  (vendor, mainline, edge).

 

I've discovered, at least with the latest edge kernel (as of Armbian 25.8.1 today), that the audio through the ES-8388 IS actually coming out, and the sound is clear. It's just that the volume that can be heard is extremely low and barely perceptible if all volume controls are maxed out and the audio file itself is at full volume range.

This Bug Is From The Kernel / Driver Development Before It Gets To Armbian

This is not new, I'd discovered this earlier and on other operating systems as well. So I know the issue is coming from the kernel / driver development, before it gets to Armbian.

 

My Thought: The Audio Is Bit-Shifted by 7 or 8 bits
I would venture an educated guess that the audio is 1/128 or 1/256 the correct levels (i.e. bit-shifted by 7 or 8 bits).
This could be caused by, for example, a 24-bit audio integer value being copied into a 32-bit integer buffer without bit-shifting by 8 bits to align the MSBs (most significant bytes). The sign bit could be why it may be 7 instead of 8.

 

The Easy Fix (for someone familiar w/ the source code)

If this is the case, then someone familiar with the source code, who knows where this is - it would be a real simple fix. On Fedora KDE, I was able to crank up the volume even beyond max settings to try to make it louder, and it got clamped instead. My thought is that this confirms that the issue is the final mix is going to the device, which would make sense.

Edited yesterday at 05:54 AM by The Tall Man

[Igor]

51 minutes ago, The Tall Man said:

on other operating systems as well

 

51 minutes ago, The Tall Man said:

Before It Gets To Armbian

 

Armbian is Debian or Ubuntu with focus into hardware support.

https://docs.armbian.com/#what-is-armbian
Many operating systems in this segment are derived or use Armbian kernel (development & support) maintained by our team and surrounding community. I do agree with your findings, but this is expected in this world. Achieving and keeping full functionality on custom hardware is hard without substantiation investments or big enough crowd of volunteers / random people that knows special stuff. Both is limited.

 

51 minutes ago, The Tall Man said:

I would venture an educated guess that the audio is 1/128 or 1/256 the correct levels

ALSA is a complex part of engineering that I only understand to some small degree. For most people, including me - is hard to comment. I hope your findings are valuable for someone that knows where to look.

 

51 minutes ago, The Tall Man said:

then someone familiar with the source code, who knows where this is - it would be a real simple fix

 

Isn't always like this?  Sadly, in most cases, problems are solved by investing time for research - code / structure complexity is often extreme, also for people that live source code. 

 

Welcome to Armbian forum!

[The Tall Man]

22 hours ago, Igor said:

Welcome to Armbian forum!

Thanks!!

 

22 hours ago, Igor said:

Armbian is Debian or Ubuntu with focus into hardware support.

https://docs.armbian.com/#what-is-armbian
Many operating systems in this segment are derived or use Armbian kernel (development & support) maintained by our team and surrounding community.

Thanks for the overview.

 

ES8388 Codec Driver

Something to add to my previous comment here (2 comments up).

 

I've noticed that, with the edge kernel, ALSA calls the ES8388 the 8328 instead. I've also seen the 8328 referenced in the devicetree .dtb file (via a hex viewer).

 

I happened across where it appears to be, in two repositories:
https://github.com/armbian/linux-rockchip/tree/rk-6.1-rkr5.1/sound/soc/codecs
https://github.com/torvalds/linux/tree/master/sound/soc/codecs
 

In both of those directories, there is an es8328.c, es8328.h and other es-... numbers in that range, but no es8388 file.  To any developer reading this, it might be worthwhile to create es8388.h and es8388.c as copies of their respective es8328 counterparts, then have the es8388 files used in the build and referenced in the devicetrees instead of the es8328. This would create the clear (and correct) workspace to make the necessary modification(s) to fix the issue (of the volume apparently being right-shifted by 7 or 8 bits - re my previous comment). I've noticed in the es8328.h file, there are several configuration constants defined. It could be as simple as modifying one of those in the es8388.h to match the actual es8388 codec.

 

Edited 14 hours ago by The Tall Man