Audio Driver (with bounty!)


I have a really hard time to grasp how the whole audio topology works, and where all the pieces come from :/
Same for me... This is the reason why this is not a stroll but climbing Mt. Fuji :) And why it takes that long.
I just have started my PandaES to check how the working setup was built. And it turned out that v6.5-rc2 changed the device tree subdirectory structure (to the better) but that is not handled properly by my build scripts.
Why do I work on PandaES? Because it has one of the handsfree speaker drivers wired to a jumper. And it is easier to have a remote controllable setup than the Pyra. And, I have (had?) a working 3.15 AESS setup - but did not yet find the SD card.
 
Same for me... This is the reason why this is not a stroll but climbing Mt. Fuji :) And why it takes that long.
I see what you did there :D
I just have started my PandaES to check how the working setup was built. And it turned out that v6.5-rc2 changed the device tree subdirectory structure (to the better) but that is not handled properly by my build scripts.

Why do I work on PandaES? Because it has one of the handsfree speaker drivers wired to a jumper. And it is easier to have a remote controllable setup than the Pyra. And, I have (had?) a working 3.15 AESS setup - but did not yet find the SD card.
I got sound from the legacy interface with a Letux kernel and device tree I received from @hns. I still get "Invalid argument" when trying the AESS sound path, so not much progress. I'll try and replicate the kernel build in my own build environment.

On a related topic, I found this talk today:

They present a tool for producing firmware files for the Linux audio SoC subsystem. The tool is called "alsatplg" (ALSA topology) and is part of the official ALSA project. It comes bundled with alsa-utils on any modern Linux distro. The tool takes plaintext configuration files (and blobs) and produces a firmware file to be loaded by the Linux kernel. Support for the firmware format was merged in Linux-4.2, and considered stable in Linux-4.8. The current firmware ABI version is 5, but ABI version 4 is also compatible.

What's especially interesting in the talk is that they mention that the tool was initially developed by Liam Girdwood when he was working for TI and the OMAP processors. He later joined Intel and continued working on it. Liam Girdwood is also the name you find in most commits for the AESS firmware repositories. The official AESS firmware, released by TI for Linux-3.8, has firmware ABI version 1.

@hns has spent a considerable amount of time to update the AESS firmware repositories to produce an AESS firmware that can be loaded by mainline Linux. The only way to produce it is by compiling the tools and binary on a compatible board itself, and this compilation breaks from time to time when kernel headers change. Apart from that, the code for generating the firmware is quite bad and hard to understand IMHO. This is not really a good situation.

So, an idea took form: since the firmware @hns have converted can successfully be loaded by Linux, it should be compatible with firmware ABI version 4 or 5. What if we can use the alsatplg tool to decode it back into plaintext configuration files (and blobs)? Then we would have the firmware information in a much more readable format and a well-maintained tool for compiling it! Unfortunately, it wasn't that easy :(

Code:
$ alsatplg -d omap_aess-adfw.bin -o omap_aess-adfw.bin.decoded
ALSA lib decoder.c:98:(snd_tplg_decode) first block must be manifest (value 3)
failed to decode context omap_aess-adfw.bin: Invalid argument

The manifest block is actually described in the video above and shouldn't be that hard to inject into the binary, but I haven't tried yet.
Anyone feeling adventurous could have a try! :D

Since we already have a stable firmware binary, I will not focus that much on it for now. I'll focus on getting AESS support working (unless @hns beats me to it)
 
Great idea and good find for the alsatplg utility...really hope we find a way to finally enable and use the AESS.
Unfortunately on Pyra Alsautils (and maybe Alsa too) is too old and don't have the -d option to decompile a firmware.

On a side note...today i tested again the firmware you compiled on the bookworm image ( i know that kernel was not able to use...but still i tried)...an i noted a strange thing....when loaded the USB ports were disabled...and i noted this because the same thing happened on standard pyra os.
Maybe this are unrelated...but who knows.
 
What's especially interesting in the talk is that they mention that the tool was initially developed by Liam Girdwood when he was working for TI and the OMAP processors. He later joined Intel and continued working on it. Liam Girdwood is also the name you find in most commits for the AESS firmware repositories. The official AESS firmware, released by TI for Linux-3.8, has firmware ABI version 1.
Maybe you can get some help or pointings to the right direction from Liam Girdwood himself. Who knows, it costs nothing to ask... Maybe he's even pleased by your efforts...
 
Great idea and good find for the alsatplg utility...really hope we find a way to finally enable and use the AESS.
Unfortunately on Pyra Alsautils (and maybe Alsa too) is too old and don't have the -d option to decompile a firmware.
You don't have to decode the firmware on the Pyra. Any OS which can run alsatplg may do it. I tried it on Arch and got the error posted above.
On a side note...today i tested again the firmware you compiled on the bookworm image ( i know that kernel was not able to use...but still i tried)...an i noted a strange thing....when loaded the USB ports were disabled...and i noted this because the same thing happened on standard pyra os.
Maybe this are unrelated...but who knows.
Strange indeed :confused:
 
Great idea and good find for the alsatplg utility...really hope we find a way to finally enable and use the AESS.
Unfortunately on Pyra Alsautils (and maybe Alsa too) is too old and don't have the -d option to decompile a firmware.
You don't have to decode the firmware on the Pyra. Any OS which can run alsatplg may do it. I tried it on Arch and got the error posted above.
Decoding is only needed once in life of mankind either... As soon as it has been converted into a .conf file only the compile mode is needed to build the firmware from scratch. And there is nothing wrong using the binary format of the firmware.
Anyways this topology file conversion is not the road block. It is "cosmetics" to make future life easier.
The real roadblock is that the AES DSP isn't running properly yet. Hence we can use only the legacy mode (with the existing firmware files).
 
Back
Top