For programming inside the library, it's best to use the these types: int64_t, uint32_t, int32_t, uint16_t, int16_t, uint8_t, int8_t. Even though this library is very specific to the Cortex-M4 processor, it's still good to use those names to specify exactly how many bits you want.
One minor complexity (well, perhaps not so minor) is using the M4's packed format. Two int16_t's can be packed into a single 32 bit variable, which is usually specified as uint32_t type. Generally it's best to write code first using ordinary variables and types and get it working and well tested, before piling on this extra complexity. But the packed format really helps speed things up, partly because you can bring 2 int16_t's into the processor as a single uint32_t read from memory, which is twice as fast as reading them separately.
I may or may not be quantizing well for AudioFilterBiquad, I expect I am but I see I come out with slightly different figures than derived the way you derived yours - I expect it amounts to very very similar filtering but I haven't means to test it properly yet.
When your board arrives, it's best to test the quantizing problems using a low pass filter with a low corner frequency.
It looks to me like AudioFilterBiquad does not make a copy of 'myFilterParameters' but instead refers to the original array giving me the impression it could be changed on the fly, please correct me if I misinterpreted that.
Yes, the filter coefficients can be changed on the fly.
If I am right about that I expect I am probably right that before changing them it would be best to 'cli()', change them, re-zero the other three elements of the array and finally 'sei()' again - am I very wrong here or not?
Yes. If interrupts are enabled, and your code is running in the main program, it's possible the update() function will run after you've changed some but not all the coefficients. That could produce 128 samples of very wrongly processed audio.
Within the library, use __disable_irq() and __enable_irq().
In the example sketches, normally you should use AudioNoInterrupts() and AudioInterrupts(). Users will copy the examples, so even if you know these aren't truly necessary for your specific example, they should still always be used in the example sketches.
The idea behind AudioNoInterrupts() is to allow the sketch to suspend audio updates, even when it calls to library functions that have __disable_irq() and __enable_irq(). The library's function can guarantee correct operation with __disable_irq() and then use __enable_irq(), but the audio library will remain disabled until the sketch completes a sequence of several such library calls and finally enables the library with AudioInterrupts().