S/PDIF input underflow in clockgen

[danielpieczko]

Seen with both 216 and 316 MCABs, running 2AMi10o10xssxxx or 2ASi10o10xssxxx configs. Only on MacOS because we don't have S/PDIF input tests on Windows yet. This is only seen at 176.4kHz.

Sequence:

1. xrun the DUT
2. start the spdif_test config of sw_audio_analyzer and set to 176400 via xscope_controller
3. xsig 176400 120000 mc_digital_input_8ch.json

It happens about once every two minutes. The error from xsig looks like this:

Channel 8: discontinuity (samples -1710391, -1710706 do not differ by 5 but by -315) (sample 18417902)
Channel 9: discontinuity (samples -4316339, -4315898 do not differ by -7 but by 441) (sample 18417902)

USB protocol capture
Key points:

1. index 65 offset 0x098: data 9xF1BC6A90 (this will reappear later...)
2. ramp is fine at this point
3. index 82 offset 0x368: data 0xF1BDA090 (expected sample)
4. index 89 offset 0x020: data 0xF1BDA590 (expected sample)
5. index 89 offset 0x048: data 0xF1BC6A90 (repeat of sample from 1)
6. each S/PDIF channel then receives 31 samples of zero (so no S/PDIF preamble or metadata)
7. the ramp continues with the next that was expected two samples after 3 - so it is as though a single sample was replaced with an earlier sample and 31 zeros

WAV generated from the USB trace
From this WAV, we can see that the eight analogue channels are unaffected when the zeros appear on the S/PDIF channels.

[danielpieczko]

Since I've been looking at a similar error while adding S/PDIF input tests on Windows, I've just realised that this is an underflow in the S/PDIF buffer in clockgen (hence why the analogue channels are unaffected). The repeated sample was an error on entry to the underflow state which has been fixed in lib_xua xmos/lib_xua#359.

[xross]

This would indicate that the mclk is not properly locked to the incoming S/PDIF stream (it it hasnt locked yet).