Add audio processing module

[ladvoc]

This PR adds support for the WebRTC audio processing module and enables AEC for microphone tracks.

[holofermes]

Hey all, I've been keeping an eye on this PR, and just give this a spin, and while this works on mac/windows, it fails on android arm64 ( I assume it would be the same for the other arm architectures ).

I think the latest android .so does is not up to date:

NullReferenceException: Object reference not set to an instance of an object.
 at LiveKit.AudioProcessingModule..ctor (System.Boolean echoCancellationEnabled, System.Boolean noiseSuppressionEnabled, System.Boolean highPassFilterEnabled, System.Boolean gainControllerEnabled) [0x00000] in <00000000000000000000000000000000>:0 
 at LiveKit.RtcAudioSource..ctor (System.Int32 channels, LiveKit.RtcAudioSourceType audioSourceType) [0x00000] in <00000000000000000000000000000000>:0 

I noticed the install.py does not have android listed in the platforms, but I manually downloaded and replaced the ffi-android-arm64/liblivekit_ffi.so and ran a build with it but that doesn't work either as it fails to load the .so, which I suspect this is why the install.py does not grab the android builds.

[ladvoc]

Hi @holofermes, thank you for reporting this. Android should definitely be included as one of the platforms in install.py. I will look into this and make the necessary changes in a separate PR.

[theomonnom]

I see the TASK_DELAY is 5ms. We're sending 10ms, this work because Rust will buffer, so maybe it's fine?

[ladvoc]

Hi @theomonnom, thank you for your feedback. Yes, there does appear to be a skew for longer room durations. I've moved the calls to the APM methods directly into the audio filter callbacks, however, this seems to introduce some audio artifacts that I haven't been able to explain yet. I think the issue is related to the forward stream being processed before the reverse stream, however, I need to do some more investigation to see if this is the case.

[theomonnom]

Hi @theomonnom, thank you for your feedback. Yes, there does appear to be a skew for longer room durations. I've moved the calls to the APM methods directly into the audio filter callbacks, however, this seems to introduce some audio artifacts that I haven't been able to explain yet. I think the issue is related to the forward stream being processed before the reverse stream, however, I need to do some more investigation to see if this is the case.

I think it's most likely because this function is too slow: https://github.com/livekit/client-sdk-unity/blob/89437aabac7b9db3ebf98d13e7478e85f525c336/Runtime/Scripts/RtcAudioSource.cs#L96

You could also try to increase the default DSP buffer of Unity