Execute multiple actions at exactly the same time

[mgeier]

Currently, if a common start time that's far enough in the future (and allow_belated=False) is used for multiple actions, all those actions will start at exactly the given time (or not at all if they are too late).

Calculating an appropriate start time that's "as soon as possible" but still late enough to make sure none of the actions are late is basically impossible.

I would like to be able to start multiple actions at the same time, without having to come up with an appropriate start time.

I've already prepared for that in the callback function, which allows having linked lists of actions in the action queue, which are checked in this loop:

python-rtmixer/src/rtmixer.c

Lines 72 to 91 in 6147a3a

	do
	{
	struct action* next = new_action->next;
	if (new_action->type == CANCEL)
	{
	new_action->next = state->actions;
	state->actions = new_action;
	}
	else
	{
	new_action->next = NULL;
	while (*last_action_addr)
	{
	last_action_addr = &((*last_action_addr)->next);
	}
	*last_action_addr = new_action;
	}
	new_action = next;
	}
	while (new_action);

This guarantees that all actions in the same list are handled in the same invocation of the callback function. And if they have time=0 (or any time less than the current time) and allow_belated=True, they will all be guaranteed to start at the beginning of the same audio block (assuming the callback finishes in time).

So far so good, the problem is how to implement this on the Python side without duplicating a lot of code.

I imagine that for each action there would be a pair of Python methods, one that immediately enqueues the action (like the current methods), and one that only prepares the action and concatenates it with other actions that have been "prepared" before into a linked list.
When all desired actions have been "prepared", the user can then "trigger" all actions at once by enqueuing the whole list.

I think the first type of methods could be implemented in terms of the second type by immediately "triggering" at the end of the call.

Ideally, the current functionality should be unaffected by this.