dac_additive: Decouple the buffer length from the waveform length

[Nebuleon]

Description

In the additive DAC driver, I saw these two pieces of code:

qmk_firmware/platforms/chibios/drivers/audio_dac_additive.c

Lines 56 to 57 in 184c584

	static const dacsample_t dac_buffer_sine[AUDIO_DAC_BUFFER_SIZE] = {
	// 256 values, max 4095

qmk_firmware/platforms/chibios/drivers/audio_dac_additive.c

Line 87 in 184c584

static dacsample_t dac_buffer[AUDIO_DAC_BUFFER_SIZE];

To me, it made no sense to have the runtime audio buffer in that driver sized according to the number of entries in the sine wave table or require all waveform tables to be sized like the runtime audio buffer, especially because the runtime audio buffer gets filled from generated samples that come from a waveform table indirectly after calculations.

This PR makes the buffer size for both DAC drivers configurable, documents it and adds sane defaults depending on the sample rate. In dac_additive, I've also changed the waveform tables to remove the explicit size in the array definitions, and while I was at it, I also changed the square wave and the commented-out staircase wave to give them only 2 and 4 steps, respectively. In the future, the waveform tables may also be made more or less precise, as required, by adding or removing entries within them.

For users of the dac_additive driver, on default settings, this change reduces RAM usage by 384 bytes; for those who choose the square wave, the flash usage also gets reduced by 508 bytes.

For users of the dac_basic driver, on default settings, this change reduces flash usage by 768 bytes, because the square waves, which are also the runtime buffers, are stored in flash.

In either case, on default settings, this PR also reduces the latency to stop a note after the relevant input stops being applied (music mode, melody, MIDI, etc.) from a maximum of 15.6 ms to a maximum of 3.9 ms.

Tested on moonlander using dac_additive. Needs testing on keyboards using dac_basic.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).
  I do not have hardware to test all of the things I changed.

[Nebuleon]

Currently lint fails on the trapezoid wave, but I formatted it like the existing sine wave. Should I add a comment like in the sine wave array, or format it like the linter says?

[sigprof]

You may also add a trailing comma to make the formatting less horrible (the line length remains huge though).

[Nebuleon]

Adding a comma and rerunning qmk format-c did make the code look much better, in that it moved }; to the next line.

As for the huge lines, they are undeniably giving the least vertical space and visual attention possible to static data of this nature, i.e. just two lines (but give way for some gnarly horizontal scroll bars if not wrapping!). Since I'm in that code anyway, I might as well either reformat the arrays in rows of 8 entries, ending at column 60, or in rows of 16 entries, ending at column 116. But that fails linting, and qmk format-c brings either of those back to two lines of 128 entries, ending at column 900. I'll revert that.

[drashna]

Compiles and works properly, for me.

[Nebuleon]

Compiles and works properly, for me.

On what driver, dac_additive or dac_basic? Or both?

[drashna]

Compiles and works properly, for me.

On what driver, dac_additive or dac_basic? Or both?

dac_additive specifically.

[KarlK90]

LGTM, thank you!