Unifi G4 Doorbell Pro - there is no echo cancellation

[fredck]

Describe the bug
When speaking through a G4 Doorbell Pro, I can hear my own voice echoing back, which should not occur.

To Reproduce
Steps to reproduce the behavior:

1. Add a G4 Doorbell Pro camera using the UniFi Protect plugin.
2. Select the camera in the "Devices" list.
3. Click the camera preview to open the live stream.
4. Click the microphone icon to enable speaking through the doorbell.
5. Speak.

Expected behavior
I should not hear my voice echoing back. It should just be audible at the doorbell device itself.

Server (please complete the following information):

• OS: HassOS
• Installation Method: Home Assistant addon

Hardware Model (please complete the following information):

• Device: UniFi G4 Doorbell Pro

Client (please complete the following information, if applicable):

• Software: Chrome browser on MacOS

Additional context
This issue does not occur when using UniFi Protect directly.

The choice to use Scrypted over go2rtc is primarily due to its support for 2-way audio with UniFi devices. However, the echo problem significantly lowers the perceived quality of this solution.

I plan to purchase the NVR plugin primarily for its Home Assistant cards integration (I do not intend to use the NVR recording feature since I already have it in UniFi). I assume the integration in Home Assistant will be similar to what is seen directly in Scrypted (as described in step 3 of the reproduction steps) so I'm using that to evaluate the functionality of the Home Assistant card.

[koush]

There's no AEC support in the unofficial unifi protect API. Please refrain from opening issues for feature requests. Use the discussions tab.

[fredck]

@koush, I hope you don't mid if I leave my feedback:

• Unless you intentionally wanted to have echo, in the end user (me) pov this is a bug - a pretty annoying one, actually.
• I shouldn't need to have knowledge (or even care) about the technicalities to be able to classify it as a bug or not. The whole point of adopting your software is exactly to not be aware of such details.
• You pointing the technical reason is a good thing: it identifies to the reason that causes the bug - it doesn't justify it.
• It is more honest to simply classify a bug as "cant fix" if there is no foreaseable way to get it solved or even "wont fix" if there is no interest in fixing it.

Or ofc, it's your project... you can always go with the classic (I'm really just joking here):

Just add the "missing" word to it ;)

[koush]

How I choose to organize the discussions and the issue tracker is geared towards my productivity, and not reflective of any plans.