add test for trailing audio after silence timeout

[glharper]

@rhurey Please take a look and see if this test matches what you'd expect for a trailing audio test

[rhurey]

Looking at the last speech.phrase message the JSON was:

{
"Id":"416a8ff33c7b4fccb516a0fadb695775",
"RecognitionStatus":"EndOfDictation",
"Offset":40000000,
"Duration":0,
"Channel":0
}

My claim was that offset should be 5s given the audio file.

I think the test needs a check of the offset property to ensure all the audio was processed correctly.

[rhurey]

I think this is the test we want:

    test.only("Multi-turn silence test", (done: jest.DoneCallback) => {
        console.info("Name: Multi-turn silence test");
        const s: sdk.SpeechConfig = BuildSpeechConfig();
        objsToClose.push(s);

        s.setProperty(sdk.PropertyId.SpeechServiceConnection_InitialSilenceTimeoutMs, "3000");

        let p:sdk.PushAudioInputStream = sdk.AudioInputStream.createPushStream();
        objsToClose.push(p);
        p.write(new ArrayBuffer(2*16000*5)); // 5 seconds of silence
        p.close();

        const r: sdk.SpeechRecognizer = new sdk.SpeechRecognizer(s, sdk.AudioConfig.fromStreamInput(p));
        objsToClose.push(r);

        let lastOffset:number = 0;

        r.speechEndDetected = (r: sdk.Recognizer, e: sdk.RecognitionEventArgs): void => {
            lastOffset = e.offset;
        };

        r.startContinuousRecognitionAsync();

        WaitForCondition(() => {
            return lastOffset == 50000000;
        }, done);

    });

Some key things, by sending only 5s of audio total it all fits in the fast lane and will likely be sent before the service can respond at all. (My random experiment makes that look true), and with a 1.5s delta between initial timeout and expected ending duration there should be no recognition that runs that far.

[glharper]

Some key things, by sending only 5s of audio total it all fits in the fast lane and will likely be sent before the service can respond at all. (My random experiment makes that look true), and with a 1.5s delta between initial timeout and expected ending duration there should be no recognition that runs that far.

@rhurey Thanks for writing that test up, it does indeed fail in my local testing. I'll take a look a fix.