Experiment with 600 samples IC delay

[uvvpavel]

The latest release of py_ic has changed y channel delay. Before implementing the new control system @shuchitak and I decided to Implement the delay change and run all the tests since it is a significant change for the core IC. This work is now in progress in #318

[uvvpavel]

Initial tests show that the ic_spec moving-source test is failing consistently. After discussing this with @hughh-xmos and @athapapa we concluded that the moving-source test case does not make sense and can be disabled.

[hughhop]

for a bit of explanation... the failure was when the IC delay was lengthen to 600 samples, but it passed at 180 samples. the test failure is based on a requirement for 15 dB of attenuation to be achieved within 3 seconds. In the static cases both the 600 sample and 180 sample delay pass the test. for the moving source case, the left mic channel is shifted in time approx every 2 s.

If we analyse the output (see plot below) the 180 sample delay does achieve better attenuation in the first couple of frames. However, the rate of convergence is actually the same after that. at 2 s, the mic channel is delay shifted, causing both filters to be mismatched and the output is louder than the input (hence the stability requirement is already disabled for this test). In both cases the filter manages to reconverge. The 180 sample delay case managed to pass the test because the attenuation reached -15 dB in about 1.5 s, before any change to the microphone delay.

that last point is important. surely the point of the moving-source test case is to check the robustness of the filter to a moving source. However, the test was passing because the filter managed to converge before there was any "movement" of the source.

Perhaps a more useful requirement would be to avoid amplification of the signal after source movement, which could be achieved by reinstating the stability requirement of the test and disabling the convergence requirement. However, even this is not really that critical, what we actually want to ensure is that if the filter starts to amplify the signal (gets in a bad/mismatched state) that it recovers. this is tested in py_ic/tests/test_bad_state.py: https://github.com/xmos/py_ic/blob/754a860bc69742ec0141847c2849b2bd291a9d3a/tests/test_bad_state.py