Sending refresh DTX packets every 400 ms independently of the encoded…
… frame size.
This pull request makes sure that refresh DTX packets are sent every 400 ms. When encoding with frame sizes different from 20 ms and using Silk (for example by forcing a low bitrate) the distance between refresh DTX packets was different from 400 ms. Specifically, for frames length equal to 60 ms, the packets were at 1.2 seconds distance.
As an example, the attached image compares a DTX region before and after the change proposed in this pull request. We can see that the upper image did not receive a refresh DTX packet for 1.2 second and, therefore, kept a high level of comfort noise for longer time. The bottom spectrogram was created with the proposed changes.

Just curious, does that fix or improve a particular behaviour. I was wondering whether 400 ms is still appropriate for longer packets or if we might want to make the delay larger -- on the assumption that bandwidth is tight. Just asking.
This change makes the Opus behavior a bit more consistent and fits better with the RFC specifications (https://tools.ietf.org/html/rfc6716#section-2.1.9).
This bug is not always happening and it depends on the configuration for Opus. For example, if the floating point code is disabled, this bug is not present. So, this change also makes the code more consistent over different Opus configurations.
Quality wise, I do not think this change has a large impact except for some corner cases like the one that I showed in the figure.
Merged in https://gitlab.xiph.org/xiph/opus/-/commit/16286a25fdd865c66a837a73b65fbaa7b25bf484
this has been merged and can be closed @mark4o