Running on CDSP

[anonymix007]

The only way to run this code is to use unsigned PDs on CDSP. Is this possible? If so, can you please help me with getting a minimal example to work?
I understand that it's meant for ADSP, but, unfortunately, it's simply not possible to use that on production devices.

Suppose I want to make use of this to offload Bluetooth audio encoding for Pipewire (let's assume the SBC codec). Since it uses libsbc, the simplest way would be to provide an ABI-compatible library which will make use of sbc_enc_module.so.1 instead of directly encoding SBC.

How should I approach this? It looks like I'd have to use AGM and PAL which probably aren't meant for CDSP. And also they look to be very cumbersome, I really want something very simple.

[quic-plai]

Hi,

Thanks for taking interest in AudioReach project. For your purpose, there is no need to involve AudioReach. What you are doing is to offload processing from ARM processor into CDSP directly. You might want to consult Qualcomm Linux documentation for reference code. https://docs.qualcomm.com/bundle/publicresource/topics/80-77512-1/hexagon-dsp-sdk-sample-apps.html?product=1601111740010422

[anonymix007]

Hi!

Thanks for your response. You're correct, it makes more sense to offload directly. However, I wanted to make use of the already existing Audioreach modules for audio encoding or decoding, so I'd rather not reimplement those from scratch.

It would be great if there was a simple example that will do the following:

1. dlopen the specified library
2. Initialize the module
3. Set some parameters or properties and maybe print them
4. Perform audio processing (read PCM samples from WAV, process and save to output file)
5. Deinitialize the module.

Such an example would be very useful for early module debugging in QEMU, for example.

[quic-plai]

Hi,

If you are referring to encoder(.so) which get loaded dynamically into ADSP during BT playback use case, they are written according to CAPI interfaces described in https://audioreach.github.io/dev/capi_mod_dev.html and run on top of AudioReach engine (SPF). Currently, spf has not been deployed onto CDSP. Though you may possibly write wrapper to invoke init, process, etc functions of encoder module, the module is likely going to invoke SPF utility and POSAL functions. Without SPF first running on CDSP, it is unlikely that encoder module can be loaded due to missing dependency symbols. Having said that, we do have roadmap feature to run AudioReach engine on CDSP but it will not be available immediately. Stay tune

[anonymix007]

Hi,

Yes, I was referring to those ADSP libraries.

I'm not quite sure how's the dynamic loading working on Hexagon. If I build this wrapper as a shared library which will expose those symbols and will dlopen these modules, will the symbol resolution be successful? Or will maybe patchelf --add-needed help?

Cool, running engine on CDSP is a nice feature indeed. Will it be usable on production devices without the need for firmware update?

EDIT: Looks like patchelf solution works on x86 with a similar setup (first library has undefined symbols, second one defines that symbol and dynamically loads it and the main executable which dynamically loads the second library), so maybe it's the way to go.

EDIT2: Looks like it's enough to use RTLD_GLOBAL flag for the wrapper. The question is, does the fastrpc shell use this flag then opening the *_skel libraries?

[quic-plai]

Hi,

I do not know enough about fastrpc to confirm what you suggested would work or not. Typically, audio use case wouldn't go through offloading from app processor to CDSP. on DSP, AudioReach engine(ARE) would perform dlopen when ARE encounters module which is yet to be loaded during use case graph setup (https://github.com/Audioreach/audioreach-engine/blob/master/fwk/spf/amdb/ext/src/amdb_dynamic_loading.c) Then, dlopen implementation in ADSP will notify fastrpc driver on Linux side to download .so from filesystem. Also, I am not familiar with the modules to figure out potential spf utility and posal dependencies. However, you can take a look at Hexagon SDK audio add-on. There are example modules and unit-test code which would give you idea how to invoke module through CAPI interfaces.

Regarding "production devices without the need for firmware update", the feature is intended for future products. I cannot be sure.