Alternative ways to implement audio ducking

[gexgd0419]

Recently I attempted to submit an add-on: Audio Ducking Enabler.

Audio ducking is not usable in portable copies of NVDA because of the UIAccess requirement. My add-on uses Detours to hook the GetTokenInformation function, and when AccSetRunningUtilityState tries to verify UIAccess, make GetTokenInformation always return true, so that AccSetRunningUtilityState thinks that NVDA always has UIAccess, and audio ducking will always be usable.

However, there are concerns about security in this thread, and my add-on cannot pass VirusTotal checks, probably because of the use of Detours and API hooks.

So I found another way to implement audio ducking. The sound splitting feature works by adjusting the left and right channel volume of applications, so we can also lower the volume of other applications using a similar method to achieve audio ducking, and restore the volume afterwards.

So what are its pros and cons compared to the current AccSetRunningUtilityState method? Can we change to this implementation to make audio ducking work everywhere?

cc. @seanbudd @SaschaCowley @mltony @jcsteh

[josephsl]

Hi,

My two cents: let us limit this to Windows 8.1 and later, or better yet, to recent Windows 10 releases and later.

The audio ducking feature was introduced in Windows 8.0 precisely for use by screen readers and others needing to speak over other apps. I personally think the status quo is a bit better - sure, we can use sound splitting feature which can be used by portable copy users, but remember that the purposes and intended audience of portable versus installed copies of NVDA are different. Keep in mind also that sound splitting requires Windows Session Audio, and that, too, depends on willingness by parties such as speech engine developers to come on board with this proposal as well (also, remember that for effective audio ducking experience, one must lower and raise the system/app volume when speech stream comes in and ends, respectively). The reason for keeping the status quo is that audio ducking feature takes this into account and is implemented at the operating system level (in short, use something out there rather than reinvent unless a really strong justification comes in, and in my thinking, usage in portable nVDA is not strong).

Thanks.

[seanbudd]

We think the only real solution is to get Microsoft to fix the ducking API, and to expose that hidden API you previously mentioned.
We wouldn't accept either of these hacks into NVDA core.