AudioOutputSPDIF3 can use the Teensy audio clock at 44.1kHz, OR, if an AudioInputSPDIF3 object (which derives its clock from the incoming audio stream) is instantiated, it can and must be synchronised to that. This approach allows a glitch-free system using SPDIF I/O only.

The design GUI has been modified to allow this combination to pass conflict checks; a better implementation may be required.

…0u5e/Audio into feature/sync-SPDIF-IO2

Was just passing audio through, which was not what was wanted at all!

This update feeds the Rx clock back through SAI1 MCLK[3], which seems to be the valid way to do it; SAI2 or SAI3 would also work. As yet untested is the concept that this will sync the entire audio system to the S/PDIF Rx clock, so it becomes possible to use the audio shield too. More clock trickery is probably needed...

Also copy across code which removes need for a dummy I²S object

I²S on SAI1 will now work with S/PDIF input as master clock

…0u5e/Audio into feature/sync-SPDIF-IO2

…0u5e/Audio into feature/sync-SPDIF-IO2

...all unsuccessful

Add offset to clock used by output_spdif3.cpp, which changes the interference rate
It looks like it's slipping 1 sample every so often, so if the SPDIF and PLL4 clocks
are e.g. 77Hz different then clicks occur at 77Hz

But why?!

Note the comment above the assignment of fs in AudioOutputSPDIF3::config_spdif3() (lines 231-236). For some reason the internal (PLL4-derived) clock has an audible effect, even if the system sample rate is supposedly being derived from the S/PDIF input. The effect seems fairly minor, with the occasional missing or extra samples rather than huge glitches, but it's not hi-fi, and I can't figure out the root cause!

…0u5e/Audio into feature/sync-SPDIF-IO2