The Tall Man

So 25.05 and 25.5 are the same version? That threw me off for a while...

True, it's not critical to compile the ideal kernel into the image as long as I get one that works, I can always update it later from within the image. But I do prefer to do things right the first time, and to be utilizing the version I think I am and intend to be using. Btw, I boot from grub as well. For my Orange PI 5 Plus, The edge kernel is the only one that's actually useful to me because the Vendor kernel has no GPU acceleration at all, the Mainline kernel has no video output to my DVI monitor, and all 3 kernel branches aren't correctly utilizing the ES8388 analog audio, which I need. The audio volume is barely audible even when all volume controls are maxed out. It's been that way in every operating system I've tried (except those with old barebones Vendor Kernels from Orange PI). So ultimately I want to compile the latest (relatively) stable edge kernel myself, so I can modify the source code in an attempt to fix the audio, and of course share the solution when / if I find it. I've already found that the ES8388 and ES8328 are compatible - hence the es8328 modules used in the kernel for the ES8388. And I've narrowed down where the issue most likely is: Directory: sound/soc/codecs Files: es8328.h, es8328.c, es8328-i2c.c

I've downloaded the latest stable Release of the source code: https://github.com/armbian/build/releases/tag/v25.8.1 When doing a Build, when it allows you to select the kernel branch: [vendor, mainline, edge], the only edge available for selection is the bleeding edge (i.e. latest trunk version). I've downloaded the 25.8.1 source code, and that's the edge version I want to compile. How do you build an image with the latest (relatively) stable edge kernel, as available in Armbian-Config? (i.e. currently v6.16.1-edge at Armbian 25.8.1)? Update #1 When compiling the image with the edge kernel, it downloaded it from the internet and it took roughly an hour to build. When compiling an otherwise identical image with the Vendor kernel, it did not seem to download it from the internet (although I wasn't watching it closely), and it took roughly less than half the time to build the image. The reason I compiled an image with the Vendor kernel is because something broke in the last 24 hours on the internet-supplied edge kernel. It compiled 24 hours ago, a few hours ago it didn't. This wouldn't be an issue if it was compiling the most recent release of v6.16.1-edge (25.8.1), as per my intention, instead of the ultra-latest. I also made some discoveries about version number inconsistencies (independent of the kernel branch selected). Things are confused. In Release 25.8.1, the version is 25.11.0.trunk. In Release 25.5.1, the version is 25.08.0-trunk.

Thanks!! 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. Hardware Datasheets / Schematics While these are likely more low-level and off the path than practically useful for the simple fix that's likely needed here, it's good to have the datasheets available in one's toolbox: Everest-Semi (ES) Hardware Datasheet For ES8388: http://www.everest-semi.com/pdf/ES8388 DS.pdf Orange PI 5 Plus Schematic: I don't see how the way they have this schematic formatted would be of much practical use to anyone, but the ES8388 is on page 29. I didn't find any interface between it and the RK3588 there or on any other pages. There's a link to the schematic on this page, under Official Resources: http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-5-plus-32GB.html

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.