when sound split is disabled, the feature as it is in NVDA core now interferes with everything else that changes channel volumes, whether an add-on or not.

[paulber19]

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Some add-ons allow you to modify application channel volumes individually.
Since the introduction of the "sound split" feature, NVDA systematically returns sound to both channels of applications to hear sound equally on both channels when "Disabled" mode is selected.
In this case, the modifications made by the add-ons are canceled

Describe alternatives you've considered

The "disabled" mode should mean that NVDA does nothing in this case and works as before the feature was introduced.

Additional context

This concerns alpha versions of NVDA.

[Adriani90]

Cc: @mltony

[paulber19]

Correction: it is not the applications that are centered, but only the system sounds. Le 10/03/2024 18:07, Adriani90 a écrit :

…

Cc: @mltony <https://github.com/mltony> — Reply to this email directly, view it on GitHub <#16287 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZLFFBEJVQLRQYB2C3WCFLYXSHLPAVCNFSM6AAAAABEPCS5N2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGI4TMNJUGA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[CyrilleB79]

@paulber19 could you indicate the names of these add-ons as examples? Thanks.

[mltony]

I implemented sound split in a generic enough way, so that add-on authors can reuse it to customize functionality - use audio.soundSplit.applyToAllAudioSessions function with a custom lambda. I think add-ons should go through this way, because pycaw is now included in NVDA and it's not a good idea to bring another version of pycaw in an add-on.

[XLTechie]

@mltony

I implemented sound split in a generic enough way, so that add-on authors can reuse it to customize functionality - use audio.soundSplit.applyToAllAudioSessions function with a custom lambda. I think add-ons should go through this way, because pycaw is now included in NVDA

Would this be worth documenting in the dev guide?

[paulber19]

Totally agree. However, to continue providing functionality in previous versions of NVDA, this is necessary. Le 11/03/2024 01:19, mltony a écrit :

…

I implemented sound split in a generic enough way, so that add-on authors can reuse it to customize functionality - use |audio.soundSplit.applyToAllAudioSessions| function with a custom lambda. I think add-ons should go through this way, because pycaw is now included in NVDA and it's not a good idea to bring another version of pycaw in an add-on. — Reply to this email directly, view it on GitHub <#16287 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZLFFFYCSEZF6MRAI2P7SLYXUBCRAVCNFSM6AAAAABEPCS5N2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGQZDSNBVHE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[paulber19]

NVDAExtensionGlobalPlugin With this add-on, it is possible to place nvda on one side and all applications on the other side, including system sounds. But, although NVDA's "sound split" feature mode is disabled, NVDA puts the system sounds in the center. Le 11/03/2024 00:24, Cyrille Bougot a écrit :

…

@paulber19 <https://github.com/paulber19> could you indicate the names of these add-ons as examples? Thanks. — Reply to this email directly, view it on GitHub <#16287 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZLFFDSX523VWMHGKPDW2TYXTTRNAVCNFSM6AAAAABEPCS5N2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGQYDOOBXGQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[CyrilleB79]

@paulber19
what you are describing just seems another sound split feature; am I correct?
If yes, there is no point in keeping it enabled in the add-on for NVDA 2024.2 since the feature is in core. You may though want to keep it in the add-on for older versions of NVDA though.

However, if @paulber19's add-on only uses functions in the API (i.e. public) for this feature, the introduction in NVDA core of Sound Split feature would be an API breaking change, what should not be allowed for 2024.2.
I did not check though which functions are used by the add-on.

@mltony do you know if the introduction of Sound Split feature in core has changed the behaviour of existing public functions?

[Adriani90]

An API breaking change can be allowed in 2024.3 though, is this correct?

cc: @gerald-hartig, in case sound split needs to be reverted and rescheduled to 2024.3 including documentation adjustments.

[paulber19]

what you are describing just seems another sound split feature; am I correct? Yes, but much finer. It is possible to do this pretty much like NVDA does, but also on an application by application basis or just for the application under focus. It is also possible to adjust the channel balance of NVDA or any other application including system sounds. So I won't say it's the same functionality. The difference in common with NVDA is that NVDA directs any new audio output according to the audio separation mode chosen. This is the problem because even in "Disabled" mode, any new output will be placed in the center by NVDA and therefore will cancel the choice made using the add-on. Let's take the "foobar2000" application as an example. With the add-on, the user can choose to put NVDA on one side and Foobar2000 on the other side without touching the other applications. And this was only done once. Until now, if foobar2000 was stopped then restarted, it found itself on the same side. It is Windows which memorizes the balance of applications. Now when the sound separation mode is "Disabled", foobar2000 is found on both channels. So this mode does not mean that NVDA does nothing, but that NVDA must put any new audio source on both channels. I hope I was clearer, even if it was a little long, For this functionality and so far, the add-on does not use any part of NVDA. Le 11/03/2024 16:14, Cyrille Bougot a écrit :

…

@paulber19 <https://github.com/paulber19> what you are describing just seems another sound split feature; am I correct? If yes, there is no point in keeping it enabled in the add-on for NVDA 2024.2 since the feature is in core. You may though want to keep it in the add-on for older versions of NVDA though. However, if @paulber19 <https://github.com/paulber19>'s add-on only uses functions in the API (i.e. public) for this feature, the introduction in NVDA core of Sound Split feature would be an API breaking change, what should not be allowed for 2024.2. I did not check though which functions are used by the add-on. @mltony <https://github.com/mltony> do you know if the introduction of Sound Split feature in core has changed the behaviour of existing public functions? — Reply to this email directly, view it on GitHub <#16287 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZLFFA2UAQTLFKLLEFNSR3YXXC5TAVCNFSM6AAAAABEPCS5N2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBYGY4DCMJWGU>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[mltony]

@paulber19,
so it seems that you can modify your add-on to make it to work with sound split by making use of applyToAllAudioSessions function - I don't understand why that's not enough.
@Adriani90 ,
I wouldn't call this API breaking change as sound split just inroduced some new API. The problem is that @paulber19 's addon had some functionality that is conflicting with sound split even back in the days when sound split was an add-on. I would argue that we shouldn't aim at the attitude of never breaking a single add-on, this attitude would be counterproductive, especially given the fact that there is no well-defined set of NVDA API that can be called addon API, so if we adopt that attitude, any change in nVDA core might be at risk. Any internal NVDA API might be used by an add-on. In this case, new API is not even the root cause. The root cause is that @paulber19 is using the same wasapi api as sound split. And this conflict can be resolved on the add-on side using the way I described above. So I guess the ultimate question is given such incompatibility between an add-on and a new feature, is that the responsibility of add-on or the author of new feature to resolve this? I would argue that addon author should resolve this - at least when my addons were broken by new features (like tab QuickNav command) - that was the case - I was expected to fix my addon. But LMK if you think otherwise.

[paulber19]

Sorry, but I don't understand either. There was never any question of API incompatibility. Both the add-on and NVDA work very well with their own API. But the operation of NVDA when the sound separation mode is "Disabled" means that NVDA cancels any modification made by the add-on since in this case, it systematically puts any new source back on both channels. This is only the subject of the request. And there is no way to prevent this from happening. Le 11/03/2024 19:40, mltony a écrit :

…

@paulber19 <https://github.com/paulber19>, so it seems that you can modify your add-on to make it to work with sound split by making use of |applyToAllAudioSessions| function - I don't understand why that's not enough. @Adriani90 <https://github.com/Adriani90> , I wouldn't call this API breaking change as sound split just inroduced some new API. The problem is that @paulber19 <https://github.com/paulber19> 's addon had some functionality that is conflicting with sound split even back in the days when sound split was an add-on. I would argue that we shouldn't aim at the attitude of never breaking a single add-on, this attitude would be counterproductive, especially given the fact that there is no well-defined set of NVDA API that can be called addon API, so if we adopt that attitude, any change in nVDA core might be at risk. Any internal NVDA API might be used by an add-on. In this case, new API is not even the root cause. The root cause is that @paulber19 <https://github.com/paulber19> is using the same wasapi api as sound split. And this conflict can be resolved on the add-on side using the way I described above. So I guess the ultimate question is given such incompatibility between an add-on and a new feature, is that the responsibility of add-on or the author of new feature to resolve this? I would argue that addon author should resolve this - at least when my addons were broken by new features (like tab QuickNav command) - that was the case - I was expected to fix my addon. But LMK if you think otherwise. — Reply to this email directly, view it on GitHub <#16287 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZLFFHOBA2PSJSWLGGQ3QTYXYCCRAVCNFSM6AAAAABEPCS5N2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBZGE4DIOJQGY>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[XLTechie]

@mltony I don't particularly care if one or two add-ons are broken by a new NVDA feature, if it doesn't actually change the definite public API. However, I would like to understand better why you consider @paulber19 to be wrong, in regards to NVDA forcing centering/reset to stereo, when set to disabled. I find that problematic if there is no workaround. Disabled should mean "don't touch".

[seanbudd]

Closing this issue for reasons @mltony outlined. This is just a consequence of NVDA development. As already discussed, the API hasn't changed here, just the nature of NVDA's behaviour.

[XLTechie]

@seanbudd I wonder if I might get clarification on my question before this issue is closed? My understanding of the issue, is that the implication has been made that the "disable" state is not being honored, that in fact NVDA is causing undocumented and, frankly, unexpected behavior when this feature is set to disabled. I for one would like to know if that is true, and why it should be the case. As I said above, disable is generally assumed to mean "do not touch". I.e. the behavior should be the same as if this feature did not exist at all, such as in 2023.3.4. If I'm wrong about what is being claimed here, then fine, but that was how I read the later comments.

[seanbudd]

@XLTechie Is the difference in expected behaviour just limited to interacting with add-ons? What has changed here is a new feature has been implemented to track and manage the state of stereo output. My understanding is that without add-ons, the disable state is identical to the "do not touch" case for users. Now that NVDA has an API for stereo manipulation, I think it is the responsibility of add-ons to utilise the API to maintain/respect the "disabled" state.

[cary-rowen]

I totally agree with @mltony regarding API and 3rd party add-on compatibility.

I wouldn't call this API breaking change as sound split just inroduced some new API. The problem is that @paulber19 's addon had some functionality that is conflicting with sound split even back in the days when sound split was an add-on. I would argue that we shouldn't aim at the attitude of never breaking a single add-on, this attitude would be counterproductive, especially given the fact that there is no well-defined set of NVDA API that can be called addon API, so if we adopt that attitude, any change in nVDA core might be at risk. Any internal NVDA API might be used by an add-on. In this case, new API is not even the root cause. The root cause is that @paulber19 is using the same wasapi api as sound split. And this conflict can be resolved on the add-on side using the way I described above. So I guess the ultimate question is given such incompatibility between an add-on and a new feature, is that the responsibility of add-on or the author of new feature to resolve this? I would argue that addon author should resolve this - at least when my addons were broken by new features (like tab QuickNav command) - that was the case - I was expected to fix my addon. But LMK if you think otherwise.

[paulber19]

the API hasn't changed here, just the nature of NVDA's behavior. And it's just this new behavior that was the subject of the issue: sound split is still active even in "Off" mode. The discussion drifted into an API issue and I don't know why. There are no API problem with the add-on. Le 12/03/2024 00:07, Sean Budd a écrit :

…

Closing this issue for reasons @mltony <https://github.com/mltony> outlined. This is just a consequence of NVDA development. As already discussed, the API hasn't changed here, just the nature of NVDA's behaviour. — Reply to this email directly, view it on GitHub <#16287 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZLFFH6ATSFHIS27PTTKX3YXY2KRAVCNFSM6AAAAABEPCS5N2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBZGYYTEOBQGY>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[cary-rowen]

Hi Paul,

Regarding the issues you mentioned:

sound split is still active even in "Off" mode.

This is already tracked by #16292.

The reason you find this discussion confusing is that I think you added to the confusion in your answer to @CyrilleB79's question.

Anyway, this issue has been closed, let us focus on the discussion of #16292.

Thanks
Cary

[LeonarddeR]

Reopening as per #16292 (comment)

[Adriani90]

@paulber19 can you not achieve what you want with the current API which is added in NVDA core now?
I mean, what i understand is that your add-on adds the application by application basis feature instead of affecting all applications.

Can you not just raise a pull request for making the core feature of sound split profile based? Then a user just needs to create a new profile for the app and it can adjust the sound split settings as needed. Is it not currently possible?

Also if you still want to preserve your add-on for older NVDA versions, you can do it by stating to the users which NVDA version they should use in order for the add-on to work.

[Adriani90]

In my view there is no add-on for this needed anymore, if people invest a bit of energy to enhance what we have already. In this case it is probably a very small change to achieve what your add-on already can do.
Installing an add-on just for this small change is an overkill in my view.

[LeonarddeR]

@Adriani90 I think the title of the current issue is a bit confusing. The underlying issue here is that Sound Split touches the channel volume of applications when the feature is disabled. This means that even when sound split is disabled, the feature as it is in NVDA core now interferes with everything else that changes channel volumes, whether an add-on or not.
@paulber19 could you please fix the title of this issue?

[paulber19]

Thank you Leonard for clarifying because I was unable to make myself understood. I used your last sentence as the title. Le 20/03/2024 16:11, Leonard de Ruijter a écrit :

…

@Adriani90 <https://github.com/Adriani90> I think the title of the current issue is a bit confusing. The underlying issue here is that Sound Split touches the channel volume of applications when the feature is disabled. This means that even when sound split is disabled, the feature as it is in NVDA core now interferes with everything else that changes channel volumes, whether an add-on or not. @paulber19 <https://github.com/paulber19> could you please fix the title of this issue? — Reply to this email directly, view it on GitHub <#16287 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZLFFDIKF4YNITIKDJADMLYZGRLHAVCNFSM6AAAAABEPCS5N2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBZHAYDQMBTHA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Adriani90]

Thanks @LeonarddeR I think I got the issue now.
@mltony what you introduced as "disabled" is actually rather enforcing "everything in both channels". I propose renaming the currently "disabled" state to "everything in both channels" and add an additional state called "disabled" which entirely disables this feature and sets the underlying API to "off".

So for example if I change my apps audio settings via an external tool such as eartrumpet
https://github.com/File-New-Project/EarTrumpet
, then the sound split feature of NVDA will not honor this when setting to disabled because it enforces its own both channels setting.

@seanbudd I think this needs a quite high priority to be fixed.

[mltony]

I stilll agree with Sean here.
When @LeonarddeR says this feature interferes with everything - that's confusing, since there are no known programs that adjust channel volume. So I hesitate to add unnecessary complexity for a completely imaginary (unless proven otherwise) use case. The only known program is @paulber19's add-on, which was incompatible with Tony's enhancements in the first place, and as I mentioned before, I provided API for @paulber19 to fix that on his side.

[LeonarddeR]

@mltony with respect, but do you really not want to understand what is going wrong here? Just because you are not aware of another program that adjusts channel volumes does not mean that NVDA is free to unnecessarily mess with channel volumes of third party applications without the end user's permission. If sound split is enabled, the end user explicitly chooses to do so. If sound split is disabled (default) the feature should simply be off as @Adriani90 explained in #16287 (comment) .
In fact, there is a similar audio mixer program created by Babbage (my former employee) that does similar things as sound split.

CC @seanbudd: Do you acknowledge that the sound split feature when in disabled state should not change channel volumes of other applications by any means?

[paulber19]

The only known program is @paulber19's add-on,

No and I already quoted it: soundVolumeView (Nirsoft) <https://www.nirsoft.net/utils/sound_volume_view.html> And even if it were the only one, it seems to me that it must be taken into account even if it is an add-on.

hich was incompatible with Tony's enhancements in the first place,

I would like to know what this adds to the discussion other than simply to denigrate the add-on. before, I provided API for @paulber19 to fix that on his side his sideThis also adds nothing to the discussion. It's not the add-on that is the problem. It works fine without this so-called API. Le 21/03/2024 18:28, mltony a écrit :

…

I stilll agree with Sean here. When @LeonarddeR <https://github.com/LeonarddeR> says this feature interferes with everything - that's confusing, since there are no known programs that adjust channel volume. So I hesitate to add unnecessary complexity for a completely imaginary (unless proven otherwise) use case. The only known program is @paulber19 <https://github.com/paulber19>'s add-on, which was incompatible with Tony's enhancements in the first place, and as I mentioned before, I provided API for @paulber19 <https://github.com/paulber19> to fix that on his side. — Reply to this email directly, view it on GitHub <#16287 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZLFFD2CJOFA5XXOULSXJDYZMKE5AVCNFSM6AAAAABEPCS5N2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJTGEZDSMZUHA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Adriani90]

@mltony are there any technical limitations that hold you back from introducing an additional state in the combo box called "disabled" which entirely disables this feature and the underlying API as I proposed above?
What is the reason not to do it? In general, any external tool that changes something in terms of audio on the system should be possible even while running NVDA. It is not an option to restrict external tools to make changes to the audio channels. If there are any technical limitations for implementing an additional "disabled" state, then this feature must be reverted unfortunately. The impact would be too negative for users if this makes it into the stable release.
If there is no technical limitation but it needs more discussion, then I propose to make this feature available only in the alpha releases and hold it back from stable or beta releases until a solution is found.

[XLTechie]

@mltony, @seanbudd, we should not need to prove this. Disabled should mean disabled. In this case it's false. We can not predict every user's situation, and just because there aren't real-world effected use cases in this (and the other) thread, only means that the limited number of people following this issue, don't have specific use cases. Disabled *HAS TO* mean disabled. Otherwise the word needs to change, and we need to warn in the userguide that NVDA *WILL* absolutely be changing the audio performance of your computer, even if most users don't care. To do otherwise is irresponsible.