<div dir="ltr">Yes, good point. I added the checking of prev_mode for Silk DTX to avoid using stale data from the Silk state.<div>The PR is updated, and I'm attaching an updated patch.<br></div><div><br></div><div>/Gustaf</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 9 Apr 2019 at 12:42, Mark Harris <<a href="mailto:mark.hsj@gmail.com">mark.hsj@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2019-04-08 4:55, Gustaf Ullberg wrote:<br>
> Thank you Mark.<br>
> <br>
> I agree and have now updated the pull request with a new commit,<br>
> addressing your comments.<br>
> Please take a look.<br>
> <br>
> /Gustaf<br>
<br>
I think you will also need to check the mode of the previous frame<br>
(st->prev_mode) before using internal SILK encoder state.  It could have<br>
been in SILK DTX some time ago, but then switched to CELT.  Normally<br>
there would be at least one non-DTX SILK/Hybrid frame before it switches<br>
to CELT only, but it is possible to switch directly from SILK DTX to<br>
CELT only mode (for example, if the frame size is reduced to less than<br>
10 ms then it will have no choice but to switch to CELT immediately).<br>
If it ever switches back to SILK or Hybrid it will reset the SILK<br>
encoder state at that time, but until then the SILK encoder state may<br>
contain stale information.  Checking that st->prev_mode is<br>
MODE_SILK_ONLY or MODE_HYBRID will verify that the SILK encoder state<br>
corresponds to the previous frame.<br>
<br>
 - Mark<br>
</blockquote></div>