System Workbench for STM32

Two issues could be there:
a) asynchronous audio clocks:
I assume, you receive digital audio via SPDIF RX and you forward the PCM code words to the onboard DAC, so that it comes out as analog on RCA connector.
Both audio 'systems' have their own clock: SPDIF Rx gets the clock with the signal from host, onboard DAC runs as a master and has its own clock (generated by PLL, onboard).
So, both clocks are not coupled, not synced or neither have the same frequency. Such independent free running clock 'domains' result in 'not enough data' or 'too much data', after a while. You get samples drops and it results in 'clicks' (potentially, an entire audio frame might be missing or an old one is repeated instead).
b) Double Buffering issues:
Actually, when using DMAs, they run 'endless' but using a Double Buffer mechanism: if one buffer half is full, the other half is used. You had to make sure to use for the audio forward, playback, the 'opposite' buffer: the buffer which is currently in use for a DMA from SPDIF Rx cannot be the same buffer you send (also via DMA) to the DAC. You had to make sure that the 'opposite' buffer is used (one for Rx, the other one for Tx).
Maybe, you need a mechanism to start SPDIF Rx as well as DAC Tx process quite at the same time (at least with minimal delay between both starts) and a logic to use the 'opposite' buffer.
Actually, there should be also a DMA complete interrupt. I use this one in order to 'flip' the buffer.

Solutions:
a) try to send a fix audio pattern, e.g. a sine wave, saw signal etc. Check the output with a scope (or try to trace and decode the audio buffer which goes to the DAC. Potentially you will see a 'jump' in the audio signal, periodically there is a short sequence of 'wrong' audio samples (potentially one SPDIF audio frame).
b) trim the audio clock: you can only fine tune the DAC audio clock, the clock for SPDIF Rx comes with the signal from the remote host. It does not solve the problem really, it makes just the period when the 'click' happens larger (or shorter).
Actually, a means is needed to 'follow' the SPDIF audio clock, to trim the DAC audio clock in relation to the SPDIF Rx clock. If you use a newer STM, e.g. a H7xx, they have PPLs with fractional divider settings and potentially you can trim a PLL 'on the fly' (but often other MCUs, boards - you had to stop PLL which makes it even worse).
c) check the buffer pointers, index etc. How are input and output buffer pointer moving? Do they start to 'overlap' (one process is faster and would hit the buffer in use for the other process).
Used this indication to trim the audio clock (make DAC audio clock a bit faster or slower).
You need a 'clock recovery' or a process to trim and sync (the audio clock frequency).
d) or, not sure if possible: try to bring the SPDIF Rx clock out on a pin (maybe possible, not sure). If you have such a clock signal coming out, run the DAC in slave mode, where it gets the clock from this pin.
Or maybe vice versa: try to get the DAC audio clock into, for the SPDIF Rx (but actually it does not help due to fact that the remote SPDIF Tx generates the transmission clock).

The 'best' solution is to have a 'word clock', a clock generator which provides the clock for the remote SPDIF Tx (host) as well as the SPDIF Rx receiver, your board, and the DAC on it).
Without such a 'system word clock' or a way for a 'clock recovery' (trim and feedback mechanism to hold clocks in sync) you will have always 'clicks', missing or too much audio samples due to a difference in the clock frequency.

Check first if the Double Buffer is properly working and how the 'buffer pointers' are moving and related to each other. Often there could be already an issue, e.g. you send the same buffer to DAC which is also in use to be filled by the SPDIF Rx. Or you hit the case where one process, one buffer, moves into the other one. This is just a criteria to 'handle' this 'audio corruption case'. Often, I decide to run the DAC output a bit slower so that I had to drop a frame if this happens (better to drop instead to send something 'unknown', old, when opposite case).
If the buffers 'overlap' each other, one process 'passes' the other one - this is very bad: you might send an entire internal buffer with wrong content (e.g. very old, from previous 'loop'). So, make sure, you have just the smallest drop of an audio frame (e.g. one SPDIF audio packet), not an entire internal buffer 'overrun' or 'underrun'.