use lower minimum Windows version for excluding Vesktop audio

[vocaldll]

Follow-up to #1294, enabling loopbackWithoutChrome on Windows 10 22H2 (build 19045). This prevents other call participants from hearing their own voices through the screenshare audio.

Thanks to @maxxeddd for reporting that this also works on build 19045.

Tested on Windows 10 22H2 build 19045, where screensharing with audio works as expected.

Also tested on Windows 10 build 19041.1415, where loopbackWithoutChrome does not work but normal loopback does, so older builds continue using the fallback.

[Vendicated]

Instead of hardcoding build number, it'd be better to check for support instead: navigator.mediaDevices.getSupportedConstraints().restrictOwnAudio

[vocaldll]

Instead of hardcoding build number, it'd be better to check for support instead: navigator.mediaDevices.getSupportedConstraints().restrictOwnAudio

I just tested navigator.mediaDevices.getSupportedConstraints().restrictOwnAudio on Windows 10 build 19041.1415 and it returns true, which caused Vesktop to select loopbackWithoutChrome, but screensharing with audio then fails.

So it looks like this only checks whether Chromium recognizes the feature, not whether the Windows version actually supports it. I don’t think it can be used here without breaking the fallback on older Windows builds.

[Vendicated]

Where are you getting these specific windows build numbers from? Why would they matter for a chromium feature?

[vocaldll]

Where are you getting these specific windows build numbers from? Why would they matter for a chromium feature?

I got 20348 from Microsoft: https://learn.microsoft.com/en-us/samples/microsoft/windows-classic-samples/applicationloopbackaudio-sample/, which says the API requires Windows 10 build 20348 or later, and that's what Chromium calls under the hood, see: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/media/audio/win/audio_low_latency_input_win.cc#1707

Obviously the documentation doesn't seem to be very accurate, as it worked on an older version than the documented 20348 (19045). Which also made me want to test it on an older Windows 10 version, (19041.1415), where it was not supported.

[ThaUnknown]

does something like

navigator.mediaDevices.getDisplayMedia({
  video: true,
  audio: {
    restrictOwnAudio: true
  }
})

fail inside chrome too?

[vocaldll]

does something like

navigator.mediaDevices.getDisplayMedia({
  video: true,
  audio: {
    restrictOwnAudio: true
  }
})

fail inside chrome too?

No, the call itself succeeds (on 19041.1415). Chrome silently ignores it though and falls back to regular loopback (see image). The returned track reports restrictOwnAudio: false, even though getSupportedConstraints() reports true.

[ThaUnknown]

this sounds fun, if if fails in a easy to catch way, then it might be worth to just always try lbwoc, and fallback to without if that fails