[IDEA] Add Reset State to OpusCtlSetRequest enum

[MS-crew]

Goal Description

We will use that state in the Opus encoder for audio processing with Speaker Toys. Enum place to be added => VoiceChat.Codec.Enums.OpusCtlSetRequest ,
enum value is 4028 and enum name can be ResetState => https://github.com/xiph/opus/blob/2d862ea14b233e5a3f3afaf74d96050691af3cd5/include/opus_defines.h#L710

Notes

No response

[Axwabo]

What would this be used for exactly? Quickly switching from playing music to speech?

[MS-crew]

What would this be used for exactly? Quickly switching from playing music to speech?

Yeah exactly, anything about clearing the buffer. Like changing the source or seeking/skipping to a different timestamp.

[Axwabo]

Are there any noticeable artifacts if you don't reset the state? I don't think I've ever had issues with source switching or seeking

[MS-crew]

Are there any noticeable artifacts if you don't reset the state? I don't think I've ever had issues with source switching or seeking

Yeah, it's usually hard to catch since the packets are tiny. But sudden jumps can still cause a pop according to previous sound and subsequent sound data. It's a bit of a coin toss, but architecturally, it happens because leftover data gets trapped in the encoder buffer. Flushing it out is just the safest bet. All Northwood will do is add a single enum here

[Axwabo]

You should be able to cast the required int value to OpusCtlSetRequest and call the SetEncoderSetting method.
I'm not an Opus expert, but (from what I can think of) you're probably experiencing a pop when seeking because the waveform isn't "continuous" enough at the exact time of seeking (same effect when you cut off a stream).
Could you see if flushing the encoder's buffer actually fixes the issue? It would also be nice to have an example that can be used to reproduce this consistently.

[MS-crew]

You should be able to cast the required int value to OpusCtlSetRequest and call the SetEncoderSetting method. I'm not an Opus expert, but (from what I can think of) you're probably experiencing a pop when seeking because the waveform isn't "continuous" enough at the exact time of seeking (same effect when you cut off a stream). Could you see if flushing the encoder's buffer actually fixes the issue? It would also be nice to have an example that can be used to reproduce this consistently.

Im sorry i was wrong about the seeking. You are right, not resetting is better there because Opus does interpolation and makes it smooth. However, we absolutely must keep the ability to reset the encoder when we suddenly change to a completely different audio track because the encoder will triey to predict the new data using the history of the old data https://opus-codec.org/docs/opus_api-1.5/group__opus__genericctls.html#gadc74e4fa8bcdf9994187d52d92207337

I can't show this directly with a video because its unlikely, there will be two different audio, the other audio wont have any gaps in its starting data and will be different from the previous audio, and they will be processed in consecutive frames.

[Axwabo]

we absolutely must keep the ability to reset the encoder when we suddenly change to a completely different audio track

That I agree with.

As mentioned before, if you need it at the moment, the request can be called by just casting the documented value to the correct enum type.
This feature will mostly benefit audio API developers, as most plugin devs won't use this directly.