Just pulling out the flowchart from Bob’s answer, it would appear that as long as the software doing the decoding (decoder 1) inserts the DSP after the decoding but before sending to the DAC for its final hardware MQA voodoo (decoder 2), then everything should be good.
He mentions a side-chain API in his description of the flowchart (quoted below), no idea what that really means.
We are going to answer this question by describing the optimum structure for MQA in a surround processor (e.g. using upscaling, matrixing, room correction) or in an automobile or a DSP loudspeaker. Such processing may not be performed on the incoming MQA (as this would destroy the MQA data signals) and should not be performed on the final output to the DAC (as this would compromise the MQA decoder’s management of the DAC), introduce uncontrolled temporal blur and require a lot of resource to perform, e.g. room correction at 8x or higher DAC feed speeds. 12
The main decoder produces an intermediate signal and processing, such as multichannel up-mixing, room correction or crossover, etc. may be performed on this. A software decoder may include a side-chain API where such processing can be inserted, as it is already in mobile implementations.