On 2020-07-15 4:37 PM, Pierre-Louis Bossart wrote:
On 7/15/20 4:37 AM, Piotr Maziarz wrote:
On 2020-07-14 17:40, Pierre-Louis Bossart wrote:
On 7/14/20 6:25 AM, Piotr Maziarz wrote:
Not checking _LAST format and rate, which are valid indexes in arrays, makes data loss while converting binary to standard ALSA configuration file.
I must be really thick on this one.
alsatplg converts from alsa-conf format to binary topology file. The binary topology file is used by drivers.
In which cases would you convert from binary to alsa-conf files? And what tool would you use?
./alsatplg --decode topology.bin --output decoded_topology.conf, This feature was added around the end of 2019. And why to use it? For binary topologies to which conf files are lost for example. It's easier to analyze and edit it in conf than directly in binary.
I must admit I completely missed this feature, thanks for the clarification.
In general, the idea is to be able to validate or debug (if necessary) topology binaries provided by users when access to FE file e.g. conf, or XML in our case, is not possible.
In perfect world one can do the following and receive the exact same results on each iteration:
(assume FE file in XML format and FE tool e.g. itt which allows for converting XML into conf)
XML -> itt -> UCM UCM -> alsatplg -> bin
bin -> alsatplg -> UCM UCM -> itt -> XML
Ability to compile and decompile was very handy in the Android world. We developed a simplified approach quite a while ago and finally decided to upstream the solution. Turned out Jaroslav pushed few commits lately that make a stub for the idea itself. Unfortunately, as you see in the series, there are several problems with the existing code rendering --decode unusable. Next step, after the fixes, is to allow for custom handlers to be provided (decompiling vendor's private data).
Czarek