3 ms·
> Basically every application that uses microphone input will want to do this The OS doesn't have more information about this than applications and it's not th
by duped 2y ago
> Basically every application that uses microphone input will want to do this
The OS doesn't have more information about this than applications and it's not that obvious whether an application wants the OS to fuck around with the audio input it sees. Even in the applications where this might be the obvious default behavior, you're wrong - since most listeners don't use loudspeakers at all, and this is not a problem when they wear headphones. And detecting that (also, is the input a microphone at all?) is not straightforward.
Not all audio applications are phone calls.
- dheera 2y agoThe OS can have multiple sound input devices for the application to choose from, "raw" and "fuckarounded with"
- duped 2y agoThat doesn't make sense in the context of default devices. MacOS's AVKit (or is it CoreAudio?) APIs that configure the streams created on the device makes way more sense, since it's a property of the audio i/o stream and not the devices.
- deleted 2y ago[deleted]
- fsckboy 2y ago>The OS doesn't have more information about this than applications the OP pointed out that this only works if he uses a browser monoculture the OS does have more information than that, it can know what is being played by any/all apps, and what is being picked up by the mic
- duped 2y agoThe "OS" isn't special here, apps can listen to system audio. fwiw, you only need to know anything about outputs if you are doing AEC. Blind source separation doesn't have that problem and can just process the input stream.
- dolni 2y ago> The "OS" isn't special here, apps can listen to system audio. Even if this is true, it's easy to imagine such functionality being exploited by malicious apps as a security and/or privacy concern, particularly if the user needs a screen reader. It definitely makes sense for the operating system to provide this functionality.
- robertlagrant 2y agoAssuming this isn't parody, the OS doesn't have to do it automatically. Having an application grab a microphone stream and say to the OS "take this and cancel any audio out streams" might be pretty useful.
- duped 2y agoI agree with that, but the point I'm trying to make is that audio i/o handling is pretty complicated and application specific. The idea I'm challenging is that "any app that wants microphone input wants this" is dubious. I'd say it's only a small number of audio applications that care about mic input want background noise reduced - and it makes sense for this to be configured per-input stream. Really what would be nice is if every audio i/o backend supported multiplex i/o streams and you could configure whether or not to cancel audio based on that set of streams but not all output (because multi output-device audio gets tricky).
- Wowfunhappy 2y agoI'm honestly having trouble thinking of a case where I wouldn't want this. I'm sure there are some niche cases, but in those cases, the application can specifically request that the OS turn off audio isolation.
- swatcoder 2y agoThe technique introduces latency and distortion because it's subtracting an estimate of sound that's traveling/reflecting in the listening environment, which is imperfect and involves the speed of sound. That latency is within the tolerance that users are comfortable with for voice chat, and much less than video processing/transfer is introducing for video calls anyway, so it's a very obvious win there. Especially since those users are most interested in just picking out clear words using whatever random mic/speaker configuration happens to be most convenient. But musicians, for instance, are much more interested in minimizing the delay between their voice or instrument being captured and returned through a monitor, and they generally choose a hardware arrangement that avoids the problem in the first place. And that's not really a niche use case.