[QCS6490/Linux] AArch64 build blocked by dynamic_resampler ARM32 archive + unclear USB offload path

[niver2002]

Summary

On Radxa Dragon Q6A (QCS6490, Linux/AArch64), we are seeing two blocking issues:

1. dynamic_resampler static library is ARM32-only, causing libspf.so link failure on AArch64.
2. USB offload path is not clear/functional on this platform with current AudioReach stack, while direct ALSA USB works.

Environment

• Board: Radxa Dragon Q6A (QCS6490)
• OS: Armbian Noble (AArch64)
• Kernel: 6.18.13-edge-qcs6490
• Repos in use: audioreach-engine, audioreach-graphservices, audioreach-graphmgr, audioreach-conf

Issue A: dynamic_resampler archive format mismatch on AArch64

What we checked

• Commit: 488dfcf62245350ab480ba72359865d01151c8ab updates:
  • modules/processing/resamplers/dynamic_resampler/bin/arm/libdynamic_resampler.a
• build/CMakeLists.txt still hardcodes:
  • STATIC_LIB_PATH "${LIB_ROOT}/bin/arm/libdynamic_resampler.a"
• The updated blob in that commit is:
  • sha: b8ca9b07515e5043ab9720df0642501776e67702
  • size: 662306
• Local file hash matches exactly (git hash-object = b8ca9b07515e5043ab9720df0642501776e67702), so this is not a corrupted download.
• file / readelf on archive members shows:
  • ELF 32-bit, ARM, EABI5

Build failure

When building audioreach-engine for Linux/AArch64:

• linker error:
  • /usr/bin/ld: .../bin/arm/libdynamic_resampler.a: error adding symbols: file in wrong format

Additional note

The parent commit (b8ad2d824e6a135d4daad853d840e5e5141ccb7d) also has ARM32 archive for the same module, so this is not newly introduced by 488dfcf..., but now it blocks AArch64 integration in our flow.

Issue B: USB offload path unclear on QCS6490 Linux

Runtime observations

• Strict dynamic path fails in graph init with:
  • gsl_do_spf_readiness_check ... GPR async send failed 19
  • No such module port (1) found in linked list
  • Session not found, returning
  • graph_init ... gsl_init failed error -19
• ACDB logs also show missing driver-data context for module IDs:
  • 0x2006, 0x2005
• Kernel has QDSP6/Q6APM-related modules loaded, but we do not see expected passthrough device nodes such as /dev/aud_pasthru_*.
• snd-usb-audio direct playback works.
• ADSP host capture -> userspace bridge -> snd-usb-audio playback works.
• But native USB offload path is still not reachable.

Questions / Requests

1. For Linux/AArch64 host builds, is dynamic_resampler expected to be shipped as ARM32 prebuilt only, or should an AArch64 variant be provided?
2. Is there a supported way to build dynamic_resampler from source for AArch64 (instead of linking prebuilt bin/arm/libdynamic_resampler.a)?
3. For QCS6490 + Linux (non-Android), what is the expected/official USB offload path with AudioReach (required kernel drivers, device nodes, and repo versions)?
4. For strict dynamic graph bring-up, what is the minimum required ACDB content for driver-data modules 0x2006/0x2005?
5. Could you share a known-good reference combo (kernel + ACDB + graphservices/graphmgr/engine commits) for QCS6490 where dynamic resampler and USB offload are both validated?

Repro (high level)

1. Build audioreach-engine on AArch64 Linux.
2. Link libspf.so with current dynamic_resampler module enabled.
3. Observe linker failure due to ARM32 static archive format.
4. On board, launch agm_server / graph service in strict dynamic mode and observe gsl_init=-19 with GPR session error.

If needed, I can provide full command logs (engine build log, agm_server journal) in follow-up comments.

[quic-aditrath]

Hi @niver2002

For Linux/AArch64 host builds, is dynamic_resampler expected to be shipped as ARM32 prebuilt only, or should an AArch64 variant be provided?

Yes, current dynamic resampler module is for architecture ARM32, we'll add AArch64 variant for dynamic resampler and keep this chat posted.

For strict dynamic graph bring-up, what is the minimum required ACDB content for driver-data modules 0x2006/0x2005?

ACDB logs also show missing driver-data context for module IDs: 0x2006, 0x2005

Could you share the exact error code you are observing?

Specifically, are you observing error code 1 (AR_EFAILED), for example:
AcdbCmdGetDriverData:3885 Error[1]: Unable to set database context using driver module(0x2005)

If so, this issue should be addressed by the following change:
AudioReach/audioreach-graphservices@cb6d445

With this update, when driver data is not present, the expected behavior is to return error code 19 (AR_ENOTEXIST), which is handled gracefully.