locked Possible work-around for NAudio's lack of .Net 5 audio port selection


TomK
 

Thanks for the fast work, Laurie, with the audio workaround - not to mention all else you do!

Too bad NAudio doesn’t support specific device selection. Especially with multiple apps fighting over device ports.
Using only “default audio port” can be confusing as to which apps are using a specific output audio port.

However, it may be possible to use Windows Advanced Audio settings panel to remap to a specific port - unbeknownst to the app's own port request.
To wit: Even if NAudio limits audio port to "Default", the Windows Advanced Audio panel can possibly remap to a specific port with its remapping feature.
I’d be happy to test the Beta in that scenario. 😊

Just another thought!
TomK / KT1TK / 73


HamApps Support (VK3AMA)
 

On 17/06/2021 3:33 pm, TomK wrote:
Thanks for the fast work, Laurie, with the audio workaround - not to mention all else you do!

Too bad NAudio doesn’t support specific device selection. Especially with multiple apps fighting over device ports.
Using only “default audio port” can be confusing as to which apps are using a specific output audio port.

However, it may be possible to use Windows Advanced Audio settings panel to remap to a specific port - unbeknownst to the app's own port request. 
To wit: Even if NAudio limits audio port to "Default", the Windows Advanced Audio panel can possibly remap to a specific port with its remapping feature.
I’d be happy to test the Beta in that scenario. 😊

Just another thought!
TomK / KT1TK / 73

Tom,

Sorry you have it wrong. NAudio does allow for playback device selection, that is one of the reasons I was using it. But it is broken with NET 5.0.7. The code introduced in 5.0.7 that triggers the NAudio issues has been reversed by the .NET devs, but it may be months before it makes it into a new NET release. As a result I have had to temporarily abandon using NAudio and rely instead on the inbuilt sound functions of WPF, which is the new code used to create JTAlert 2.50.x. It is those inbuilt sound routines that lack any ability to select an output device, all playback goes to the Windows default device.

de Laurie VK3AMA


Jim Cooper
 

On 17 Jun 2021 at 17:41, HamApps Support (VK3AMA)
wrote:

It is those inbuilt sound routines
that lack any ability to select an
output device, all playback goes to
the Windows default device.
I like the previously suggested concept
of locking out JTalert audio if the user
is using ONLY one sound device (default)
on the system. These days there is really
no reason at all not to add a $5 USB audio
device as a non-default audio -- esp. since
WSJT even specifically says it's not
recommended to use default audio for the
transmitted data signals.

w2jc


TomK
 

As always, thanks for your time, Laurie. 

Even so, the Windows Advanced Audio Remapping remains a key player in my Digital Zen workflow.

It should work with any paths that go to Windows default - be they  NAudio, LaurieMagic, or lesser players 😊

I use it now to redirect most of my Digital Zen audio paths – WSJT, Motu-Mics, general web audio, etc.

I’ll happily await your next magical iteration.

TomK 73                

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Thursday, June 17, 2021 3:41 AM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Possible work-around for NAudio's lack of .Net 5 audio port selection

 

On 17/06/2021 3:33 pm, TomK wrote:

Thanks for the fast work, Laurie, with the audio workaround - not to mention all else you do!
 
Too bad NAudio doesn’t support specific device selection. Especially with multiple apps fighting over device ports.
Using only “default audio port” can be confusing as to which apps are using a specific output audio port.
 
However, it may be possible to use Windows Advanced Audio settings panel to remap to a specific port - unbeknownst to the app's own port request. 
To wit: Even if NAudio limits audio port to "Default", the Windows Advanced Audio panel can possibly remap to a specific port with its remapping feature.
I’d be happy to test the Beta in that scenario. 😊
 
Just another thought!
TomK / KT1TK / 73


Tom,

Sorry you have it wrong. NAudio does allow for playback device selection, that is one of the reasons I was using it. But it is broken with NET 5.0.7. The code introduced in 5.0.7 that triggers the NAudio issues has been reversed by the .NET devs, but it may be months before it makes it into a new NET release. As a result I have had to temporarily abandon using NAudio and rely instead on the inbuilt sound functions of WPF, which is the new code used to create JTAlert 2.50.x. It is those inbuilt sound routines that lack any ability to select an output device, all playback goes to the Windows default device.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 18/06/2021 6:29 pm, TomK wrote:

As always, thanks for your time, Laurie. 

Even so, the Windows Advanced Audio Remapping remains a key player in my Digital Zen workflow.

It should work with any paths that go to Windows default - be they  NAudio, LaurieMagic, or lesser players 😊

I use it now to redirect most of my Digital Zen audio paths – WSJT, Motu-Mics, general web audio, etc.

I’ll happily await your next magical iteration.

TomK 73    


While Windows may offer a solution via Advanced Audio Remapping, which I have failed to find any mention of in my searches, if it requires an end user to make configuration changes to their system, that alone is enough to make it a non-starter IMO. If I can't get users to read simple release notes, getting them to make complicated (I am guessing here) configuration changes to their system would be a support nightmare.

All is not lost, earlier today a updated version of NAudio was released. That version doesn't suffer from the NET 5.0.7 induced sound playback failures. I reversed all the sound playback changes in the soon to be released JTAlert 2.50.2, bringing NAudio back into the code. A new build has been sent to the Test team. My own tests and the initial reports from the Test team all confirm that audio playback is now working correctly on systems running the latest NET 5.0.7 Desktop Runtime.

I had planned to ship JTAlert 2.50.2 on 21-June, but due to todays recoding/testing activity, I have pushed that out an extra day to 22-June.

de Laurie VK3AMA




TomK
 

Great news re NAudio as it allows your code to run like you want it too. Yeah!

That further obviates any need to understand the rest of this note (for JTA at least).
Feel free to close this message now! Most others should do just that 😊

 

…. All masochists, read at your own risk  …. It is nothing more than advanced tool ….

 

Nb. I had called the advanced option “Advanced Audio” when it is really “Advanced Sound”.  

 

Re Windows Audio Sound Settings.

The Advanced Sound option provides an easy way to set an app’s audio paths even if it doesn’t have audio selections.  
It acts just like an audio patch panel to reroute audio where you want it to go.
This is a Godsend since 95% of apps I know don’t have their own device selection and rely on the Windows default.

But, again, MOST USERS WILL NEVER NEED THIS!!!

  1. Re Advanced Settings hard to find.
    It took me a while to stumble over the obvious!  It’s hiding in plain sight.
    Alas, there are but a few hits searching for “Windows Advanced Sound Settings”
    In a nutshell, when you open Audio Settings, Advanced Sound is at the BOTTOM.
    For those interested, here’s how I navigate to it: I click Windows search and enter “Audio Settings”


    Sound Settings then appears at the top of my results ….


    The regular Sound Settings panel then opens …

    The option for Advance Sound appears at the very BOTTOM of that panel (green highlighter above)
    I click on that and get the Advanced Sound options as show below …


    My system has a VERY long list of apps. I edited out all those not pertinent to this crowd <laugh>.

    The very first mapping option is that of the Windows Default itself and also System Sounds.
    Most systems would have the Input/Output of those two set to their Microphone/Speakers

    In my nerdy audio setup, I set my default Mic/Speakers to be my virtual mixer, VoiceMeeter.
    Same idea, just different paths. 99% of  users should just leave them set to Mic/Speakers.
    The remapping magic happens with the individual entries for each running app.

    Note that I said “Running”. That is because only running apps will appear in the list.
    No worries. Even if you set an app’s paths then close that app, its remap is retained.
    So, be sure that the apps whose audio you want to remap are running so you can see and set them.

    In the above example, I have WSJT, JTA, and GridTracker running so I can alter their paths.
    Note:  JTA and GT are both set to “Default” (which itself is set at the very top).
    I left them as default since they both have their own device selection (now working).
    Note: FireFox’s output is remapped to “Cable C” which is an input to my virtual mixer.
    That way, I can control and/r mix the audio from Firefox as I see fit.
    Note: My mixer, VoiceMeeter, then maps back to Windows default after its mixing is done.

    Another case where this is handy is where JTA, WSJT and HDSDR are fighting for ports.
    My remapping to different paths (my mixer’s inputs in my case), the conflict is resolved.

    That’s about it. As I said, most people will never need this flexibility but its there and easy to use.

  2. Re funky changes to system?  Nope. Safe, simple, and transparent.
    The remapping is totally transparent and doesn’t alter anything deep under the covers.
    Win simply looks for any audio remaps of an app and reroutes audio accordingly. 
    It allows you to set the audio path for any of the currently active apps.  
    The app must be active to see it in the list and enter the remap.
    All apps default to the default path as specified at the top of the panel.
    You can then set the app’s desired audio in/out paths (Mic and Speaker).
    Prior to any remapping, each app defaults to the default paths which are set at the very top of that panel.

 

In  summary, the Advanced Sound options affords you the same flexibility as an app having its own path option – except it even works for all those apps that don’t have their own audio device option.  I think the order of precedence is app path then Win Remap.

 

KT1TK / TomK / 73

 

 

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Friday, June 18, 2021 4:57 AM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Possible work-around for NAudio's lack of .Net 5 audio port selection

 

On 18/06/2021 6:29 pm, TomK wrote:

As always, thanks for your time, Laurie. 

Even so, the Windows Advanced Audio Remapping remains a key player in my Digital Zen workflow.

It should work with any paths that go to Windows default - be they  NAudio, LaurieMagic, or lesser players 😊

I use it now to redirect most of my Digital Zen audio paths – WSJT, Motu-Mics, general web audio, etc.

I’ll happily await your next magical iteration.

TomK 73    


While Windows may offer a solution via Advanced Audio Remapping, which I have failed to find any mention of in my searches, if it requires an end user to make configuration changes to their system, that alone is enough to make it a non-starter IMO. If I can't get users to read simple release notes, getting them to make complicated (I am guessing here) configuration changes to their system would be a support nightmare.

All is not lost, earlier today a updated version of NAudio was released. That version doesn't suffer from the NET 5.0.7 induced sound playback failures. I reversed all the sound playback changes in the soon to be released JTAlert 2.50.2, bringing NAudio back into the code. A new build has been sent to the Test team. My own tests and the initial reports from the Test team all confirm that audio playback is now working correctly on systems running the latest NET 5.0.7 Desktop Runtime.

I had planned to ship JTAlert 2.50.2 on 21-June, but due to todays recoding/testing activity, I have pushed that out an extra day to 22-June.

de Laurie VK3AMA



Dave C
 

Tom,
Thanks for the detailed description of the Advanced Sound Options.  I stumbled on this some while back and have used it successfully.  However, I have the feeling that Microsoft sometimes tinkers with these settings at software updates.  It is not uncommon for me to have to revisit my Sound settings after a Windows update.

73,
Dave


TomK
 

Thanks for the good words.  I had worried about that, too!

Luckily, I have not seen that happen through 1.5 years of updates.

 

I was going to summarize some more things but that is protracting this thread, ha!

Unless replies deal with JTA and Win audio remapping, we should idle this thread.

 

Enjoy. TomK / KT1TK / 73

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Dave C
Sent: Saturday, June 19, 2021 2:57 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Possible work-around for NAudio's lack of .Net 5 audio port selection

 

Tom,
Thanks for the detailed description of the Advanced Sound Options.  I stumbled on this some while back and have used it successfully.  However, I have the feeling that Microsoft sometimes tinkers with these settings at software updates.  It is not uncommon for me to have to revisit my Sound settings after a Windows update.

73,
Dave