Clarify source and location of ACDB data files

[slyon]

During Debian packaging of audioreach-conf I see that .acdb and .qwsp files are installed in "/etc". Those seem to be binary data-files rather than conffiles (i.e. not supposed to be edited by a human).

Please clarify how those binaries are being built (what's their source?).
And consider installing them to /usr/share, instead of /etc.

drwxr-xr-x root/root         0 2026-07-02 11:45 ./
drwxr-xr-x root/root         0 2026-07-02 11:45 ./etc/
drwxr-xr-x root/root         0 2026-07-02 11:45 ./etc/acdbdata/
drwxr-xr-x root/root         0 2026-07-02 11:45 ./etc/acdbdata/GLYMUR/
-rw-r--r-- root/root    154406 2026-07-02 11:45 ./etc/acdbdata/GLYMUR/acdb_cal.acdb
-rw-r--r-- root/root     92784 2026-07-02 11:45 ./etc/acdbdata/GLYMUR/workspaceFileXml.qwsp
drwxr-xr-x root/root         0 2026-07-02 11:45 ./etc/acdbdata/Kaanapali/
-rw-r--r-- root/root    154406 2026-07-02 11:45 ./etc/acdbdata/Kaanapali/acdb_cal.acdb
-rw-r--r-- root/root     92784 2026-07-02 11:45 ./etc/acdbdata/Kaanapali/workspaceFileXml.qwsp
drwxr-xr-x root/root         0 2026-07-02 11:45 ./etc/acdbdata/LEMANS_EVK/
-rw-r--r-- root/root    154070 2026-07-02 11:45 ./etc/acdbdata/LEMANS_EVK/acdb_cal.acdb
-rw-r--r-- root/root     88784 2026-07-02 11:45 ./etc/acdbdata/LEMANS_EVK/workspaceFileXml.qwsp
drwxr-xr-x root/root         0 2026-07-02 11:45 ./etc/acdbdata/MAHUA/
-rw-r--r-- root/root    154406 2026-07-02 11:45 ./etc/acdbdata/MAHUA/acdb_cal.acdb
-rw-r--r-- root/root     92784 2026-07-02 11:45 ./etc/acdbdata/MAHUA/workspaceFileXml.qwsp
drwxr-xr-x root/root         0 2026-07-02 11:45 ./etc/acdbdata/MONACO_EVK/
-rw-r--r-- root/root    154090 2026-07-02 11:45 ./etc/acdbdata/MONACO_EVK/acdb_cal.acdb
-rw-r--r-- root/root     93136 2026-07-02 11:45 ./etc/acdbdata/MONACO_EVK/workspaceFileXml.qwsp
drwxr-xr-x root/root         0 2026-07-02 11:45 ./etc/acdbdata/QCM6490_IDP/
-rw-r--r-- root/root    154406 2026-07-02 11:45 ./etc/acdbdata/QCM6490_IDP/acdb_cal.acdb
-rw-r--r-- root/root     92784 2026-07-02 11:45 ./etc/acdbdata/QCM6490_IDP/workspaceFileXml.qwsp
drwxr-xr-x root/root         0 2026-07-02 11:45 ./etc/acdbdata/QCS6490_RB3Gen2/
-rw-r--r-- root/root    154406 2026-07-02 11:45 ./etc/acdbdata/QCS6490_RB3Gen2/acdb_cal.acdb
-rw-r--r-- root/root     92784 2026-07-02 11:45 ./etc/acdbdata/QCS6490_RB3Gen2/workspaceFileXml.qwsp
drwxr-xr-x root/root         0 2026-07-02 11:45 ./etc/acdbdata/SM8750_MTP/
-rw-r--r-- root/root    154406 2026-07-02 11:45 ./etc/acdbdata/SM8750_MTP/acdb_cal.acdb
-rw-r--r-- root/root     92800 2026-07-02 11:45 ./etc/acdbdata/SM8750_MTP/workspaceFileXml.qwsp
drwxr-xr-x root/root         0 2026-07-02 11:45 ./etc/acdbdata/TALOS_EVK/
-rw-r--r-- root/root   2766958 2026-07-02 11:45 ./etc/acdbdata/TALOS_EVK/acdb_cal.acdb
-rw-r--r-- root/root    881632 2026-07-02 11:45 ./etc/acdbdata/TALOS_EVK/workspaceFileXml.qwsp
drwxr-xr-x root/root         0 2026-07-02 11:45 ./etc/acdbdata/X1E80100/
-rw-r--r-- root/root    154406 2026-07-02 11:45 ./etc/acdbdata/X1E80100/acdb_cal.acdb
-rw-r--r-- root/root     92784 2026-07-02 11:45 ./etc/acdbdata/X1E80100/workspaceFileXml.qwsp
drwxr-xr-x root/root         0 2026-07-02 11:45 ./etc/acdbdata/qcs8300/
-rw-r--r-- root/root    148986 2026-07-02 11:45 ./etc/acdbdata/qcs8300/acdb_cal.acdb
-rw-r--r-- root/root     89040 2026-07-02 11:45 ./etc/acdbdata/qcs8300/workspaceFileXml.qwsp
drwxr-xr-x root/root         0 2026-07-02 11:45 ./etc/acdbdata/qcs9100/
-rw-r--r-- root/root    175338 2026-07-02 11:45 ./etc/acdbdata/qcs9100/acdb_cal.acdb
-rw-r--r-- root/root     94768 2026-07-02 11:45 ./etc/acdbdata/qcs9100/workspaceFileXml.qwsp

[qti-sbojja]

Yes you are correct, need only Read permission.
These files are generated by the windows application QACT tool. Opensource tool ARC https://audioreach.github.io/design/arc_design.html.

Yeah sure will plan to maintain files under /use/share.

[slyon]

These files are generated by the windows application QACT tool. Opensource tool ARC https://audioreach.github.io/design/arc_design.html.

Great, thanks for the insights! Is there any kind of "source" file for that, or is the calibration data created "by hand" using the QACT tool?

[qti-sbojja]

These files are generated by the windows application QACT tool. Opensource tool ARC https://audioreach.github.io/design/arc_design.html.

Great, thanks for the insights! Is there any kind of "source" file for that, or is the calibration data created "by hand" using the QACT tool?

The calibration data in the .acdb files is created using the ARC (AudioReach Composer) tool the open-source successor to QACT. The tool provides a GUI where you configure audio topology, routing, and tuning parameters for a specific hardware platform (codec, amplifier, microphone layout, etc.), and then exports the binary .acdb calibration database and the .qwsp workspace file.

So the .qwsp file is effectively the "source" it is the ARC workspace that was used to generate the corresponding .acdb. Both are checked in together so that the calibration can be reproduced or modified by opening the .qwsp in ARC.

[slyon]

Understood, I think that should work for Debian: .qwsp (source) => .acdb (target)

Let's keep this issue open to track the move of the files to /usr/share/...

[aekoroglu]

@slyon : I'm working on distribution-friendly structure patch set, probably I'll send couple PR today

[basak-qcom]

So the .qwsp file is effectively the "source" it is the ARC workspace that was used to generate the corresponding .acdb. Both are checked in together so that the calibration can be reproduced or modified by opening the .qwsp in ARC.

Long term, would it be feasible/reasonable to package ARC, provide a CLI, and then do the .qwsp -> .acdb step at build time? Or are there other dependencies such as the actual hardware?

[slyon]

Long term, would it be feasible/reasonable to package ARC, provide a CLI, and then do the .qwsp -> .acdb step at build time? Or are there other dependencies such as the actual hardware?

In theory, yes. AFAIU the ARC tool is open source software, but currently only supported on the Windows platform. So it would need some extra work of porting it to Linux and potentially implementing a CLI.