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
