dax: add an instance manager by checkupup · Pull Request #10688 · thesofproject/sof

checkupup · 2026-04-08T07:10:23Z

When multiple DAX components are running simultaneously, instance resources may be insufficient. In this case, DAX instance manager ensures that higher-priority DAX components are always granted instance resources. For DAX components that cannot obtain instance resources in a timely manner, dax_process will operate in pass-through mode.

sofci · 2026-04-08T07:12:16Z

Can one of the admins verify this patch?

reply test this please to run this test once

lgirdwood · 2026-04-13T12:13:31Z

test this please

lgirdwood

@checkupup are you able to add more inline comments describing the flow/mechanism and log when we have to fallback to pass through mode. How would priority be set by users, i.e. using topology tuples would mean same dax/sof binaries could be used but with different priorities depending on target.

checkupup · 2026-04-14T03:22:29Z

@checkupup are you able to add more inline comments describing the flow/mechanism and log when we have to fallback to pass through mode.

Sure, see my latest commit.

When multiple DAX components are running simultaneously, instance resources may be insufficient. In this case, DAX instance manager ensures that higher-priority DAX components are always granted instance resources. For DAX components that cannot obtain instance resources in a timely manner, `dax_process` will operate in pass-through mode. Signed-off-by: Jun Lai <jun.lai@dolby.com>

checkupup · 2026-04-15T07:24:36Z

To maintain code readability, I have extracted the entire instance resource handling logic into the file dax_instance_manager.c

checkupup · 2026-04-20T03:47:56Z

Code Logic:

Assume that instance 1 is created first.

While Instance 1 is running, Instance 2 requests to be created. If Instance 2 has a higher priority than Instance 1, then during Instance 1's process loop, check_priority_l evaluates to false, causing Instance 1 to voluntarily release its held memory resources. Instance 2 checks for available memory on each iteration of its process loop; if memory is available, it proceeds to create the instance. Since Instance 1 has already released its memory, Instance 2 is successfully created. At this point, Instance 1 operates in passthrough mode.

Once Instance 2 finishes its work and releases the memory, if Instance 1 is still active, check_priority_l in its process loop evaluates to true. Instance 1 then re-requests the memory resources. Upon successfully acquiring them, it exits passthrough mode and resumes actual audio effect processing.

Note: The speaker instance has a higher priority than the headphone instance.

kv2019i

Some comments inline.

kv2019i · 2026-04-20T14:37:45Z

+			if (inst_mgr.users[i].id != DAX_USER_ID_INVALID &&
+			    !inst_mgr.users[i].allocated) {
+				inst_mgr.available_inst_cnt++;
+			}


Hmm, is this a bit racy? Consider: A single DAX component registers, its first establish_instance call hits ENOMEM (e.g., tight memory). The code sets available_inst_cnt = 1 (one non-allocated user). On the next process loop, check_priority_l sees allocated_cnt=0 < available_inst_cnt=1, returns true, and the allocation is retried — on every call.

Oh, thanks, @kv2019i , the condition shoud be:

if (inst_mgr.users[i].id != DAX_USER_ID_INVALID && inst_mgr.users[i].allocated) {...}

That's my bad.

kv2019i · 2026-04-20T14:40:42Z

+ *
+ * @return 0 on success, negative error code on failure.
+ */
+int register_user(struct processing_module *mod);


Consider adding a "dax_" prefix. This is added to global namespace and "register_user" could coflict with other software modules.

Thanks, good ideas

kv2019i · 2026-04-20T14:40:48Z

+ *
+ * @return 0 on success, negative error code on failure.
+ */
+int unregister_user(struct processing_module *mod);


Ditto here.

kv2019i · 2026-04-20T14:40:58Z

+ *
+ * @return 0 on success, negative error code on failure.
+ */
+int check_and_update_instance(struct processing_module *mod);


kv2019i · 2026-04-20T14:45:46Z

+	 */
+	int32_t available_inst_cnt;
+
+	struct k_spinlock lock;


This is a more future-proofing type of comment and not blocking for the PR. We have multiple efforts ongoing to support running some of the audio modules in Zephyr user-space threads on future SOF platforms. We don't yet have documentation on the requirements to audio modules on this. But, but, spinlocks won't be available to user threads and currently the audio code is almost free of spinlock use (except for KPB and now potentially DAX). One practical alternative is mutexes (rtos/lock.h , wraps native Zephyr locks). But just a consideration, as said, this is purely a future-oriented comment.

Since a lock is acquired on every loop process, the context-switching overhead introduced by a mutex may not be efficient.

kv2019i · 2026-04-20T14:47:38Z

+		ret = establish_instance(mod);
+	else
+		ret = destroy_instance(mod);
+


As the lock is dropped here, it would be good to add a comment how the code handles the scenario where priority circumstances have changed. E.g. while running the blocking "establisb_instance()", the "has_priority" priority has become stale. Not necessarily a problem, but good to add a comment you've considered this.

The comment will be added:

/* This section of logic do not need lock protection because * it does not involve access to any shared resources. `has_priority` * may be stale when using in if condition but it is OK, `update_allocation_l` * will synchronize instance state which will be used in the next check phase. */

checkupup mentioned this pull request Apr 8, 2026

dax: sharing one instance across multiple dax adapters #10650

Closed

lgirdwood reviewed Apr 13, 2026

View reviewed changes

checkupup force-pushed the main_dax_user_priority branch from 5af4619 to a50b365 Compare April 14, 2026 03:19

checkupup force-pushed the main_dax_user_priority branch from a50b365 to 2b0800b Compare April 15, 2026 07:12

checkupup changed the title ~~dax: add a user priority mechanism~~ dax: add an instance manager Apr 15, 2026

checkupup marked this pull request as ready for review April 20, 2026 03:32

checkupup requested review from dbaluta, kv2019i, lbetlej, mmaka1, plbossart and ranj063 as code owners April 20, 2026 03:32

kv2019i requested changes Apr 20, 2026

View reviewed changes

Conversation

checkupup commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sofci commented Apr 8, 2026

Uh oh!

lgirdwood commented Apr 13, 2026

Uh oh!

lgirdwood left a comment

Choose a reason for hiding this comment

Uh oh!

checkupup commented Apr 14, 2026

Uh oh!

checkupup commented Apr 15, 2026

Uh oh!

checkupup commented Apr 20, 2026

Uh oh!

kv2019i left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

checkupup commented Apr 8, 2026 •

edited

Loading