With SMC I could write these audio channel constants into the code before executing the loop and save a lot of cycles for data fetching, and also save registers to keep more channel data in the registers.Why not keep these "audio channel constants" in EEPROM? Will reading them from EEPROM going to be any different than reading them from Flash?
That misses the point, constants compiled into the code are inserted into the actual instructions as immediate
constant fields, potentially. The read-decode-execute hardware is pipelined and costs as little as one cycle per
instruction, whereas accessing EEPROM takes many cycles.
Are these different sets so large and/or diverse that code for each set would be too big to fit yet quickly transferable blocks would not? SMC would have to pick and chose then write that along with the rest of the code to flash --which AVR's can do, just not with existing Arduino bootloader code, AVR-Forth certainly does run-time flash writes-- more efficiently than other ways? I really doubt it.
VLSI Solutions make DSP chips with built-in MCU and GPIO pins. Their programming code is free. Look into a VS1053 breakout board for example, lots of room for customizing and in quantity the chips are economic. You can shoehorn a project into something tight but that doesn't necessarily make the best product and certainly not the best use of development resources. Chances are they may have something that does the job or close and modifiable.
VLSI Solutions in a Finnish company BTW, with very good engineers and help.