Feature: Implement voicing/DSP filters as a config file

[TooDissing]

I would like to implement a "config" file for defining the voicing/DSP filters needed to provide the proper tuning.

Have you already setup a generic config file or should I create a new one?

[TooDissing]

It should be read at runtime, so it can be updated without a recompile - just a restart (when several "tunings" are already installed)

[feelfreelinux]

Currently in progress, I am setting up berry bindings that will make it possible to generate a dsp preset.

What exact dsp features do you need?

[TooDissing]

With the current tuning of STRØM 1.0 there's a whole suite of filters needed. Including some for x-over. But mainly shelves and peaking/notch EQ

[TooDissing]

as a development workflow I have been using https://github.com/HEnquist/camilladsp on a labtop. To get a better insight on the filters you can find one tuning here: https://github.com/LydByDissing/stroem/blob/main/voicing/voicing-80hz-target.yaml

[feelfreelinux]

Initial support started in: https://github.com/feelfreelinux/euphonium/commit/05461a87623287ae6c230c80ffcc41d348e6043e

Currently implemented:

    var BIQUAD_TYPE_LOWPASS
    var BIQUAD_TYPE_HIGHPASS
    var BIQUAD_TYPE_NOTCH
    var BIQUAD_TYPE_PEAK
    var BIQUAD_TYPE_LOWSHELF
    var BIQUAD_TYPE_HIGHSHELF

Along with mono downmix function.

Draft API exposed as follows:

dsp.clear_chain() # clears entire current User-defined DSP chain
dsp.add_biquad(dsp.CHANNEL_LEFT, dsp.BIQUAD_TYPE_LOWPASS, { 'f': freq, 'g': gain, 'q': qPoint })
dsp.add_mono_downmix()

Api most likely subject to change, as it does not allow for change of EQ based on dynamic variables. Entire chain is being applied in a separate UserDSPProcessor, separate from internal EqualizerProcessor and SoftwareVolumeProcessor.

[TooDissing]

Initial support started in: 05461a8

Currently implemented:

    var BIQUAD_TYPE_LOWPASS
    var BIQUAD_TYPE_HIGHPASS
    var BIQUAD_TYPE_NOTCH
    var BIQUAD_TYPE_PEAK
    var BIQUAD_TYPE_LOWSHELF
    var BIQUAD_TYPE_HIGHSHELF

Along with mono downmix function.

Draft API exposed as follows:

dsp.clear_chain() # clears entire current User-defined DSP chain
dsp.add_biquad(dsp.CHANNEL_LEFT, dsp.BIQUAD_TYPE_LOWPASS, { 'f': freq, 'g': gain, 'q': qPoint })
dsp.add_mono_downmix()

Api most likely subject to change, as it does not allow for change of EQ based on dynamic variables. Entire chain is being applied in a separate UserDSPProcessor, separate from internal EqualizerProcessor and SoftwareVolumeProcessor.

This looks rather cool and super useful! Is there already an example filter implemented? Looking at euphonium/scripts/internal/dsp.be, but don't see any filters there.

A comment on the down mix. From what I can see in the code, the down mix is applied after all the filters. This will likely cause problems. Maybe it should be moved up as the first action? And any thoughts about crossover? I.e. one channel per driver (type) - fx left for the woofer and right for the tweeter.

[feelfreelinux]

Initial support started in: 05461a8 Currently implemented:

    var BIQUAD_TYPE_LOWPASS
    var BIQUAD_TYPE_HIGHPASS
    var BIQUAD_TYPE_NOTCH
    var BIQUAD_TYPE_PEAK
    var BIQUAD_TYPE_LOWSHELF
    var BIQUAD_TYPE_HIGHSHELF

Along with mono downmix function. Draft API exposed as follows:

dsp.clear_chain() # clears entire current User-defined DSP chain
dsp.add_biquad(dsp.CHANNEL_LEFT, dsp.BIQUAD_TYPE_LOWPASS, { 'f': freq, 'g': gain, 'q': qPoint })
dsp.add_mono_downmix()

Api most likely subject to change, as it does not allow for change of EQ based on dynamic variables. Entire chain is being applied in a separate UserDSPProcessor, separate from internal EqualizerProcessor and SoftwareVolumeProcessor.

This looks rather cool and super useful! Is there already an example filter implemented? Looking at euphonium/scripts/internal/dsp.be, but don't see any filters there.

A comment on the down mix. From what I can see in the code, the down mix is applied after all the filters. This will likely cause problems. Maybe it should be moved up as the first action? And any thoughts about crossover? I.e. one channel per driver (type) - fx left for the woofer and right for the tweeter.

Will push a sample to the repo in a few minutes :) Good point about the down mix being wrong in the chain - moved it up. About crossover - can't we technically achieve it with current API? Enable downmix, and then put different filters on both channels?

[TooDissing]

About crossover - can't we technically achieve it with current API? Enable downmix, and then put different filters on both channels?

Yes. This should work :-)

[feelfreelinux]

Notes from call:

• Implement SPL-dependent Biquad configuration
• Add missing filters
• Add dsp.CHANNEL_BOTH so we save up on CPU cycles

[feelfreelinux]

• Option to set default volume table
• Dynamic headroom based on filters

[feelfreelinux]

ESP-DSP performance metrics: https%3A//github.com/espressif/esp%2Ddsp/blob/07aa7b1c84637ac6621e2e460d4dd2cbe352385d/docs/esp%2Ddsp%2Dbenchmarks.rst

[TooDissing]

• Add missing filters

Unless we can control the filter order by Q directly, then we would need 1st and 2nd order (current) of the shelving filters and some higher order 4th/6th/8th of the high pass and lowpass filters. Then it is possible to make great driver protection.