We're going in circles here. If you set too low a latency, then you hear audio glitches instead, which is worse. So that is not a solution; it's something that works sometimes, only by chance.
As far as I gather, the situation is that there are three classes of devices:
1) Devices supporting low-latency audio and they say they support low-latency audio. These work fine.
2) Devices supporting low-latency audio that don't say they support low-latency audio. These have high latency, but could have low latency if the latency is manually reduced.
3) Devices which don't support low-latency audio and don't say they support low-latency audio. These have high latency and there is nothing that can be done about it. Manually reducing the latency will result in audio glitches.
The only opportunity for improvement is with type 2. However these devices are lying about their capabilities, and that's the real root cause of the problem here. How do you tell them apart from type 3? I don't see any easy way to do that at all. It seems like a really hard problem. Both type 2 and type 3 say they don't support low-latency audio, and if you mix them up, type 3 will start having audio glitches.
You can just leave it up to the user to configure the latency themselves, but most users won't bother, and they can also misconfigure it themselves, such as taking a type 1 device that works fine, and then breaking it.
I don't see any good path to take here: the real problem is Android manufacturers misconfiguring their devices. But it is too late for devices already released. And adding user-configurable settings results in equal or worse problems.
And even if the issue for type 2 devices is somehow fixed, there will still be type 3 devices out there with high latency, and there's nothing that can be done for them. So Android devices with high latency will continue to exist, even if the Chrome issue is fixed.