|
| 1 | +# Module Implementing Interfaces (`module_adapter/module`) |
| 2 | + |
| 3 | +The `module` directory contains the concrete `module_interface` implementations that bridge the core SOF Component API with various audio processing algorithms. These adapters translate the generic initialization, parameter configuration, and process loop calls into the specific operational sequences required by different module frameworks. |
| 4 | + |
| 5 | +The directory primarily houses three distinct module adapters: |
| 6 | + |
| 7 | +1. **Generic Core Adapter (`generic.c`)** |
| 8 | +2. **Modules (IADK/Shim) Adapter (`modules.c`)** |
| 9 | +3. **Cadence DSP Codec Adapter (`cadence.c`, `cadence_ipc4.c`)** |
| 10 | + |
| 11 | +## 1. Generic Core Adapter (`generic.c`) |
| 12 | + |
| 13 | +The Generic adapter provides the default runtime container for typical native SOF processing modules (e.g., volume, eq, src). |
| 14 | + |
| 15 | +It implements the full `struct module_interface` contract: |
| 16 | + |
| 17 | +* **Memory Management**: It intercepts memory allocation mappings using `mod_balloc_align` and tracks memory requests in a module-specific resource pool (`module_resource`). When the module goes out of scope, the framework garbage-collects any leaked allocations automatically via `mod_free_all()`. |
| 18 | +* **Configuration Handling**: Manages large blob configuration messages across multiple IPC fragments (`module_set_configuration`). It allocates memory for `runtime_params` until the blob is fully assembled, then triggers the underlying algorithm with the completed struct. |
| 19 | +* **State Machine Enforcement**: It wraps `process_audio_stream` and `process_raw_data` calls to verify the module is in either `MODULE_IDLE` or `MODULE_PROCESSING` states before execution. |
| 20 | + |
| 21 | +## 2. Modules (IADK Shim) Adapter (`modules.c`) |
| 22 | + |
| 23 | +The `modules.c` base is an extension adapter designed specifically to run Intel Audio Development Kit (IADK) 3rd party algorithms. |
| 24 | + |
| 25 | +Unlike the generic modules, the IADK modules are object-oriented C++ architectures linked into a separate library (`module_adapter/iadk`). This file acts as the primary C entry point wrapper. |
| 26 | + |
| 27 | +* It utilizes the `iadk_wrapper_*` C-bridge functions to invoke methods on the C++ `intel_adsp::ProcessingModuleInterface` classes. |
| 28 | +* It exposes the standard `DECLARE_MODULE_ADAPTER(processing_module_adapter_interface)` that is bound to the SOF pipeline. |
| 29 | + |
| 30 | +## 3. Cadence Codec Adapter (`cadence.c`) |
| 31 | + |
| 32 | +This is a highly specialized adapter used for integrating Xtensa Audio (XA) codecs from Cadence (e.g., MP3, AAC, Vorbis, SBC, DAB). |
| 33 | + |
| 34 | +The `cadence.c` implementation maps the standard SOF pipeline controls into the Cadence memory buffer management and synchronous execution models. |
| 35 | + |
| 36 | +```mermaid |
| 37 | +graph TD |
| 38 | + subgraph SOF Initialization |
| 39 | + INIT["cadence_codec_init"] |
| 40 | + CONFIG["cadence_configure_codec_params"] |
| 41 | + RESOLVE["cadence_codec_resolve_api"] |
| 42 | + end |
| 43 | +
|
| 44 | + subgraph Cadence Library Init XA API |
| 45 | + MEMTABS["cadence_codec_init_memory_tables"] |
| 46 | + GETSIZE["XA_API_CMD_GET_MEM_INFO_SIZE"] |
| 47 | + SETPTR["XA_API_CMD_SET_MEM_PTR"] |
| 48 | + end |
| 49 | +
|
| 50 | + subgraph Data Processing Loop |
| 51 | + PROC["cadence_codec_process_data"] |
| 52 | + FILL["XA_API_CMD_SET_INPUT_BYTES"] |
| 53 | + EXEC["XA_API_CMD_EXECUTE"] |
| 54 | + GETOUT["XA_API_CMD_GET_OUTPUT_BYTES"] |
| 55 | + end |
| 56 | +
|
| 57 | + INIT --> RESOLVE |
| 58 | + RESOLVE --> CONFIG |
| 59 | + CONFIG --> MEMTABS |
| 60 | +
|
| 61 | + MEMTABS -. Iterates Memory Types .-> GETSIZE |
| 62 | + GETSIZE -. Assigns Buffers .-> SETPTR |
| 63 | +
|
| 64 | + SETPTR ==>|Pipeline Trigger| PROC |
| 65 | +
|
| 66 | + PROC --> FILL |
| 67 | + FILL --> EXEC |
| 68 | + EXEC --> GETOUT |
| 69 | +``` |
| 70 | + |
| 71 | +### Cadence Memory Tables |
| 72 | + |
| 73 | +Unlike standard modules that directly read from a `sof_source` API, Cadence codecs require their memory isolated exclusively into exact predefined chunks categorized by "type". `cadence_codec_init_memory_tables` iterates through the codec's hardware definition to construct these memory areas: |
| 74 | + |
| 75 | +* `XA_MEMTYPE_INPUT` |
| 76 | +* `XA_MEMTYPE_OUTPUT` |
| 77 | +* `XA_MEMTYPE_SCRATCH` |
| 78 | +* `XA_MEMTYPE_PERSIST` |
| 79 | + |
| 80 | +The SOF adapter allocates tracking structures via `mod_alloc_align` for each of these mandatory regions prior to audio playback. |
| 81 | + |
| 82 | +### Execution Wrapper |
| 83 | + |
| 84 | +During `cadence_codec_process()`, the adapter: |
| 85 | + |
| 86 | +1. Performs `source_get_data` and mechanically copies audio bytes into the isolated `XA_MEMTYPE_INPUT` buffer. |
| 87 | +2. Invokes the Xtensa Audio codec API (`XA_API_CMD_EXECUTE`). |
| 88 | +3. Reads the produced byte count and copies them back out from `XA_MEMTYPE_OUTPUT` into the `sof_sink`. |
0 commit comments