Since the DTCM doesn't support caching, the problem can't be bad cache handling code.
But lacking barriers can still be an issue. And, while for SRAM lacking barrier instructions that can be solved by configuring the descriptor memory as a device memory type (but one still needs volatile qualifiers and/or compiler barriers), DTCM is always a normal memory type and therefore MPU configuration doesn't matter. Therefore with DTCM the proper usage of __DMB() macro is absolutely mandatory and there is no other way around it. The reworked drivers from ST are OK in this regard, but the older ones are broken. All of it is explained in my articles.
Other ongoing DMA traffic is Ethernet/SAI (more or less continuously) and 2 SPI-masters (sporadic burst transfers).
SPI can go up to 54 Mbps, which even with 1-byte DMA transfers turns into 6,75 MT/s. Doing 2/4-byte transfers reduces the load further. Ethernet can go up to 100 Mbps (12,5 MBps). As the ETH DMA does 4-byte transfers, it turns into 3,125 MT/s. Is SAI used for audio? Some standard stereo 48 kHz stream would load the bus with 96 kT/s, which is next to nothing. An 8-channel 192 kHz stream still loads the bus with just 1,536 MT/s. And the SAI has an 8 word deep FIFO. The DMA peripheral also has a 4 word deep FIFO.
All of it together sums up to 18,161 MT/s, which is just 8,4 % of the bus matrix's 216 MT/s bandwidth. So, even all of it simultaneously running at maximum speeds, is still very far from overloading the bus matrix.
