@cujomalainey good to merge. Some conflicts though.

Negative, tests reported broken audio, working on debugging, just had to fight my tooling super hard this week

any performance difference with float api?

From what I understand, none, since the s16 is essentially a frontend for the f32 api

This is blocked by #8258. The AEC xruns the pipe on ll

Notes and nitpicks. I guess one thing to note somewhere is that this is going to be highly dependent on platforms with a working FPU/HiFi engine and attendant toolchain and OS.

I don't think this makes a difference since this is essentially a no-op as the conversion to FP was already done inside the lib, this just makes its easily handed for multiple formats outside.

No idea why github won't let me reply to #8237 (comment) but for some reason there is no reply box.

this is a question for @ShriramShastry and @singalsu

@andyross @cujomalainey @singalsu @nashif
If its true that Zephyr does not save HiFi registers in preemption, it is a huge gap and must be fixed, DP processing is designed as a set of threads with deadlines, preempting each other (and being preempted by LL tasks). Each of the threads may, and most likely will, use HiFi

As to slow float->int conversion, the answer is:

int16_t CONVERT(float data)
{
	const xtfloat ratio = 2 << 14;
	xtfloat x0 = data;
	xtfloat x1;
	int16_t x;

	x1 = XT_MUL_S(x0, ratio);
	x = XT_TRUNC_S(x1, 0);

	return x;
}

converting of 10ms of 4channel data from float to int16 took 1.1ms (!!!!) using Q_CONVERT_FLOAT, 120us using CONVERT as above
Q_CONVERT_QTOF, however, is quite fast, conversion from 10ms/4chanels fom int16 to float takes 140us

Regarding HiFi registers: I'm guessing @dcpleung might have some WIP on saving the SIMD registers, if not I can take a crack at it. It's not particularly difficult, though it does have some stack/performance tradeoffs to worry about (it's a ton of data to push on the stacks, but then stacks are cached where e.g. the thread struct can't be). And IIRC (i.e. I might be wrong, would have to look up) Xtensa doesn't have a way to lazy-evaluate (e.g. trap on use) the context switch, we'd likely pay the cost for every interrupt/switch.

And as far as how to implement it: my recommendation would be to stay away from the explicit TIE macros as they defeat the optimizer (and obviously aren't portable anyway). Checking quickly, the loop below (very roughly what the code in question is doing) already optimizes to a pleasingly unrolled loop over the scalar FPU with xcc 2021.6 on TGL. With xt-clang and the ACE config, it actually emits some pretty scarily optimized (but quite fast looking) well-bundled HiFi SIMD loops. The TIE macros are definitely in third place by my accounting (though still ahead of gcc: the Zephyr SDK for TGL won't emit FPU code at all and calls into libgcc -- pretty sure FPU support is supposed to work, might be a compiler build goof).

Checking quickly, the loop below [...]

Oops, forgot loop:

void f_to_s32(float *in, int *out, int n)
{
    for (int i = 0; i < n; i++)
        out[i] = in[i] * (1.0f / INT_MAX);
}

And IIRC (i.e. I might be wrong, would have to look up) Xtensa doesn't have a way to lazy-evaluate (e.g. trap on use) the context switch

I looked it up. It does. It gets complicated with SMP in the presence of SCHED_PIN_ONLY=n because you need to shoot down the state on another core when threads migrate, but that's not a SOF configuration so we can defer optimizing that case.

No idea why github won't let me reply to #8237 (comment) but for some reason there is no reply box.

this is a question for @ShriramShastry and @singalsu

Q_CONVERT_QTOF

Hi @cujomalainey ,

I think you can use 'Q_CONVERT_QTOF' without any problems for the time being. In cmocka wrappers, Q_CONVERT_QTOF is frequently utilized, and there is no appreciable loss of accuracy in terms of Total Harmonic Distortion or Unit in last place.

If performance is an issue, I'm not sure what the expectations are—what the cycle and benefit are expected to be, how long they will last, and so on.

Yes, it is true that the #define Q_CONVERT_QTOF(x, ny) ((float)(x) / ((int64_t)1 << (ny))) division operator may be an argument. In that case, the implementation might be made quickly for any compiler by introducing the inverse #define Q_CONVERT_QTOF(x, ny) ((float)(x) * inv((int64_t)1 << (ny))) and employing a leading-to-zeros technique with a LUT to prevent loops.

Thank you!

I'm finishing with DP venison of AEC and the loop looks like:

	for (int i = 0; i < cd->num_frames; i++) {
		for (channel = 0; channel < cd->num_capture_channels; channel++)
			cd->process_buffer_ptrs[channel][i] =
					Q_CONVERT_QTOF(src[channel], 15);

		src += cd->num_capture_channels;
		if (src >= src_buf_end)
			src = src_buf_start;
	}

execution time for the loop above - for 10ms 16bit 4 channels - 140us

please do not merge this commit - once DP version is stable - hopefully very soon - i'll put a new PR for this

I';m closing this PR,
all changes for 32bit are here: #8469