Try to optimise OPAL

[maks]

As part of trying to improve performance for #283 this PR does some basic optimisation for the OPAL audio rendering code. The main optimisation in the OPAL code is removing function calls from the tight loop by creating a new method for generating samples together for a whole buffer and then further removing more function calls by inlining several small functions. At the cost of 200bytes of ram, the constant LUTs are also forced to be in ram all the time.

For a release builds takes rendering time for 1 Render() method call at default bpm and default OPAL instrument settings from:

Render took: 3838 (0 ts)[268860620]
Render took: 3820 (0 ts)[268860620]
Render took: 3813 (0 ts)[268860620]
Render took: 3764 (0 ts)[268860620]
Render took: 3800 (0 ts)[268860620]
Render took: 3811 (0 ts)[268860620]
Render took: 3822 (0 ts)[268860620]
Render took: 3802 (0 ts)[268860620]
Render took: 3773 (0 ts)[268860620]
Render took: 3827 (0 ts)[268860620]

to:

[OPALINSTRUMENT] Render took: 2832 us [799])
[OPALINSTRUMENT] Render took: 2812 us [799])
[OPALINSTRUMENT] Render took: 2783 us [799])
[OPALINSTRUMENT] Render took: 2829 us [799])
[OPALINSTRUMENT] Render took: 2827 us [799])
[OPALINSTRUMENT] Render took: 2805 us [798])
[OPALINSTRUMENT] Render took: 2786 us [799])
[OPALINSTRUMENT] Render took: 2792 us [799])
[OPALINSTRUMENT] Render took: 2813 us [799])
[OPALINSTRUMENT] Render took: 2840 us [799])
[OPALINSTRUMENT] Render took: 2814 us [799])

so from around avg of 3.8ms to 2.8ms which is a decent if not stellar improvement.

[democloid]

Very nice!

Wouldn't inlining Sample and Output methods in the current code achieve the same results?

Do you have a sense on how much of this gain is due to the method change vs putting that data in memory? (BTW, wouldn't you achieve not being in flash by not defining it const?)

[maks]

Very nice!

Wouldn't inlining Sample and Output methods in the current code achieve the same results?

Unfortunately no as the linker complains if you try to call an inline function, in the this case Sample() from another compilation object, which sort of makes sense because the compiler has removed it as its already been inlined (ie. deleted) from its own compilation object.

Do you have a sense on how much of this gain is due to the method change vs putting that data in memory? (BTW, wouldn't you achieve not being in flash by not defining it const?)

Good question! I just reran test with the force into ram macro removed from the LUTs and I get:

[OPALINSTRUMENT] Render took: 3306 us [799])
[OPALINSTRUMENT] Render took: 3292 us [799])
[OPALINSTRUMENT] Render took: 3249 us [799])
[OPALINSTRUMENT] Render took: 3310 us [799])
[OPALINSTRUMENT] Render took: 3337 us [799])
[OPALINSTRUMENT] Render took: 3304 us [799])
[OPALINSTRUMENT] Render took: 3280 us [799])

so moving the LUT data into ram is what gives approx half the performance improvement.

[maks]

Wouldn't inlining Sample and Output methods in the current code achieve the same results?

Oops! sorry I see what you mean now, make them inline and then call them from the new SampleBuffer function instead.
Yes that works and just tested gives same perf improvement 👍🏻