Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[glynor]

6233638 has brought this up a few times, but usually "tacked on" to other more general posts about the WDM driver. I thought it would be more effective to give it a discreet post.

I do still think that making the whole WDM process to be far more descriptive rather than using confusing/cryptic names/terms for it would go a long way to making it easier for people to use.

Code: [Select]

JRiver Media Center 20  →  JRiver Virtual Audio Device
WDM Driver              →  JRiver Virtual Audio Device
Ipc                     →  System Audio Playback via JRiver Virtual Audio Device
And only replacing the driver when truly necessary, or finding a way to update the driver without resetting its configuration to the default 2ch 16/44 output would really improve the usability.
Every time a new version of MC is installed my configuration is reset to the default settings, the currently active sound device is changed, and the device itself often changes position in the device list meaning that some applications need reconfigured to output audio to the correct device.
It's very disruptive, and I understand why people find it confusing, or have given up on using it.

[glynor]

I have some comments and thoughts on this. First of all, I'll state at the outset, that I agree completely that the fact that the WDM Driver loses its settings each time you install a new build of MC (or reinstall your current build) is an issue.

I think there are some reasons, however, that maybe this issue hasn't been getting traction.  First of all, the WDM Driver is version 1.0.  JRiver puts some resources into features like this for each major revision, and then if the feature proves popular or useful, will spend more time on it in the "next round".  That's just how they develop features: Iteratively.  It keeps them from spending too much time going down a rabbit hole that might only be useful for a tiny sliver of their customer base, and I think the WDM Driver falls squarely in this category.  So, this might just be a thing of "patience grasshopper".

However, there might also be a problem of terminology, to a degree.  Most of the complaints I've seen around this, particularly from 6233638 (but probably others as well), focus on this:

And only replacing the driver when truly necessary

This is technically untrue, first of all.  The driver is included in the installer package with a "update if newer" flag, and is only replaced on disk if the actual version has incremented.  That's why when there was the buggy installer that didn't include the driver itself, it didn't impact some of us who already had the driver installed.

I'm not one of the developers, so I can only guess, but I bet my guess is very close to what is happening.  It isn't actually replacing the driver on disk with each install, but it is "activating it" (installing it into Windows) with each install, if the installer sees that Tools > Options > General > Features > WDM Driver is enabled.

Changing that is likely a non-starter for the developers, because it enforces consistency.  They can ensure that if that option is enabled, then the driver has been installed.  Even if the user manually uninstalls it via the Device Manager, then all they'd have to do to "fix" it would be reinstall their build of MC.  You won't get stuck in a state where MC thinks the driver is installed (because the relevant option is set) but the driver itself actually isn't installed (because the user did something to remove it).  It is a state tracking problem.

The problem is, of course, that each time you reinstall the driver into Windows, then Windows sets the driver to it's "lowest common denominator" setting.  This is true with physical audio device drivers too.  If I reinstall my craptastic Realtek drivers, they go back to 16-bit/44.1/2-channel as well.  There might be some way around this, but that is by no means guaranteed.  I've tried looking around on dev forums, and haven't found much other than "Windows does what it is going to do and too bad".

So, if going down that road is a non-starter, how else can you solve the issue?

Well, Windows sets the driver to its lowest-common-denominator settings whenever a new driver is installed.  However, JRiver can control what the driver says it supports when it is installed.  I have no idea how difficult this might be to accomplish, but if the driver told Windows, for example, that it was exclusively a 24-bit/96kHz/7.1 channel audio device, and provided no other choices, then Windows would use that.

So, perhaps the solution is simply to add these settings to MC's Options, and when you install the driver, instead of selecting the default audio properties through the Windows Sound Control Panel, you select them in MC.  JRiver can just select the best settings to make available, and let you choose from things that make sense with your Options > Audio setup.

[glynor]

This brings us to... What settings make sense for the WDM Driver?

I strongly suspect that changing the WDM Driver to anything other than 16-bit/44.1kHz or 16-bit/48kHz is counter productive from an audio quality perspective for most reasonable uses of the WDM Driver.

The primary goal of the WDM Driver is to allow you to use MC's audio engine with other applications, mostly web browsers, which are otherwise too incompetent to handle nice options on their own.

So, ignoring the WDM Driver itself entirely for a minute, what happens in most applications (those less competent with audio) when you set your default audio device in Windows to be, say, 24-bit/96kHz?  I mean, the audio is almost certainly not natively 96kHz coming out of the application!  Almost all the time the samples included in the application are probably 44.1kHz.  If it plays video, then the audio embedded in those videos is probably 48kHz.  Anything else basically never happens.

So, you're looking at some application (like Adobe Flash Player) which doesn't really give a hoot about audio quality and doesn't provide any settings, and the system tells it to give it audio in 24-bit/96kHz, but it only has 16-bit/44.1kHz native audio.  What does it do?

I don't know for sure, but I'd bet you $50 that for almost all of them, they are DirectSound players, which means that in order to get it to spit out the right sample rate, DirectSound resamples it for them. So, this means... For all but the rarest of circumstances, the only "correct" options to select, for sample rate, are 44.1kHz or maybe 48kHz.  Everything else is going to resample through the dumb Windows resamplers, and you're defeating yourself (it would be better to take it in native and then let MC resample it if needed or desired).

The speaker settings are something else entirely, but for sample rate, I strongly suspect that altering the defaults is more-often-than-not damaging sound quality slightly, not improving it in any way.  Because the whole point of the WDM Driver is to help with applications otherwise too incompetent to do WASAPI on their own.  Sure, you also get all the other fancy DSP (room correction, etc), but this is clearly designed for helping out "dumb" applications like Spotify and web browser audio.

So, there's that too.  I don't know what the proper settings should be, but any solution that solves the "reinstallation" issue, should think about this as well. If you let people select settings they don't understand, people will run into trouble, and then come here and we'll have to try to sort it out later.

Anyway, I'm not 100% positive about this last bit, but I thought it was definitely worth discussing.  And, like I said, I agree that the "reinstall means lose settings" issue is troublesome, and they should have some kind of plan to fix it, even if it is long-term (v2.0 later this year, or whatever).

[Awesome Donkey]

Being able to set fixed bit depth and sample rate at the highest hardware output available might be a bad idea. For example, it seems Google Chrome can't play the sound on YouTube HTML5 videos correctly when using a sample rate higher than 192kHz.

So I believe the default should always be 16-bit/44.1kHz or 16-bit/48kHz. However what MC should save between updates is the channels (which I guess could be added as a WDM driver option in MC).

[mwillems]

Glynor,

There's a lot of material there, but I wanted to offer a few additional data points.

1) I think you missed part of 623's argument about driver versioning/updating. His point is that the driver is reinstalled every build because the driver version number is incremented each build by the devs, whether or not changes have been made to the driver itself.  The driver itself may not change every build, so incrementing the version number every build basically forces a reinstall without there needing to be a reinstall.  

To be clear, I'm just summarizing his point, I don't know enough about development to know if his point is a fair one: e.g. I don't know how often the driver itself changes, but based on filesize comparison I would guess not every build (or not even every several builds).

2) I think if we're proposing different defaults/options, I think channel count is more important than sample rate/bitdepth.  I think having greater than 2-channel be something configurable/the default might be desirable. JRSS mixing will take care of any issues it might cause on the back end and with greater precision than the windows mixer.  

However what MC should save between updates is the channels (which I guess could be added as a WDM driver option in MC).

Agreed.

[glynor]

I've seen 6233638 make that argument before, regarding the builds, but I think he is wrong. If you look in the installer package, you can clearly see how the file itself is tagged, and it is set to "update if newer".

If it changes, it is because it uses shared code and they can't rebuild it without re-linking to the shared libraries.  But clearly (based on the missing driver in a few builds thing) it does NOT work that way.

It DOES seem to re-install it "into Windows" each time, which is something else.  As I mentioned, I don't know for sure why this is done, but I can guess.  That makes sense.

Either way, how or why it happens is irrelevant. The issue isn't updating the driver, the issue is losing the settings.

I agree about the channel count.  I think that, by far, is the biggest issue.  I don't think it much matters if the thing is locked and ONLY shows 44.1kHZ and 48kHz. You could just have a setting in Tools > Options > Audio: Optimize WDM Driver for:
* Audio
* Video

And call it done. Otherwise, leaving it at 44.1kHz seems to be the most reasonable setting for most audio applications (unless you use it mostly for Netflix or something).

The biggest issue is channels, by far.

[mwillems]

I've seen 6233638 make that argument before, regarding the builds, but I think he is wrong. If you look in the installer package, you can clearly see how the file itself is tagged, and it is set to "update if newer".

If it changes, it is because it uses shared code and they can't rebuild it without re-linking to the shared libraries.  But clearly (based on the missing driver in a few builds thing) it does NOT work that way.

It DOES seem to re-install it "into Windows" each time, which is something else.  As I mentioned, I don't know for sure why this is done, but I can guess.  That makes sense.

Either way, how or why it happens is irrelevant. The issue isn't updating the driver, the issue is losing the settings.

I'm not sure I agree it's irrelevant unless one of the settings you're talking about is the default audio device setting. Updating the driver changes the windows default device setting, un-defaulting the driver at each installation, which is a source of angst for several folks, including myself. I would like to reduce the number of driver reinstalls/re-registrations if at all possible for that reason as well, unless the changing-the-default-audio-device issue could be fixed (but signs point to that being not possible).

For me that setting-loss is a significantly more important issue than the channels or sample rate issues, and was identified in 623's post as well.

[6233638]

I'm going to chop up your post just to save this from being massive.

I have some comments and thoughts on this. First of all, I'll state at the outset, that I agree completely that the fact that the WDM Driver loses its settings each time you install a new build of MC (or reinstall your current build) is an issue.
[...]
I think there are some reasons, however, that maybe this issue hasn't been getting traction.  First of all, the WDM Driver is version 1.0.  JRiver puts some resources into features like this for each major revision, and then if the feature proves popular or useful, will spend more time on it in the "next round".  That's just how they develop features: Iteratively.  It keeps them from spending too much time going down a rabbit hole that might only be useful for a tiny sliver of their customer base, and I think the WDM Driver falls squarely in this category.  So, this might just be a thing of "patience grasshopper".
[...]
This is technically untrue, first of all.  The driver is included in the installer package with a "update if newer" flag, and is only replaced on disk if the actual version has incremented.

If I check the driver version, it is equal to the current version of Media Center. (C:\Windows\system32\drivers\JRiverWDMDriver.sys)
So as of MC 20.0.108, the driver version is listed as: 20.0.108.0
I believe it is the fact that they are incrementing the driver version every time which is the root cause of this issue.

As far as I am aware, there have not been any changes made to the driver for months. That is not a bad thing.
But incrementing the driver version each time means that every time you update MC it's a "new version" being installed, which seems to clear out the old settings.

Now perhaps there are ways to update the driver version without clearing the settings - and I'd like to see that if the driver ever hits "2.0" but that's not really my problem.
If it happens once every six months, I can deal with re-configuring the device and other applications on my system. I'd prefer not to, but it's not too much of a both.
If it's happening once a week or more, it's frustrating to say the least.

The problem is, of course, that each time you reinstall the driver into Windows, then Windows sets the driver to it's "lowest common denominator" setting.  This is true with physical audio device drivers too.  If I reinstall my craptastic Realtek drivers, they go back to 16-bit/44.1/2-channel as well.  There might be some way around this, but that is by no means guaranteed.  I've tried looking around on dev forums, and haven't found much other than "Windows does what it is going to do and too bad".

With my NVIDIA HDMI drivers, it seems to default to 16/48 not 16/44.
I'm not actually sure about the reason it uses 16/48 - it may be preserving my old setting (I'd have to test that to be sure) or detecting that it is the "optimal" format to send my display.
The display accepts 24-bit signals, but truncates them to 16-bit, so I'd be selecting 16/48 anyway.
But my point here is that it's not selecting the absolute lowest format available on a fresh install of the driver.

Well, Windows sets the driver to its lowest-common-denominator settings whenever a new driver is installed.  However, JRiver can control what the driver says it supports when it is installed.  I have no idea how difficult this might be to accomplish, but if the driver told Windows, for example, that it was exclusively a 24-bit/96kHz/7.1 channel audio device, and provided no other choices, then Windows would use that.

So, perhaps the solution is simply to add these settings to MC's Options, and when you install the driver, instead of selecting the default audio properties through the Windows Sound Control Panel, you select them in MC.  JRiver can just select the best settings to make available, and let you choose from things that make sense with your Options > Audio setup.

I suppose that might work, to have separate versions of the driver which only support one output format, and selecting that within MC itself would tell it which driver to install, or perhaps configure the device that way.
It seems like a bit of a hack, but if that's the only solution it may be better than nothing?
 

I strongly suspect that changing the WDM Driver to anything other than 16-bit/44.1kHz or 16-bit/48kHz is counter productive from an audio quality perspective for most reasonable uses of the WDM Driver.

I agree that using a sample rate other than 44.1kHz or 48kHz is probably a bad idea, since anything using higher sample rates than that likely supports an exclusive output and can set the device to that itself, or it would support the ASIO driver instead of using the WDM driver.
 
For music 44.1kHz would be ideal and for video/games 48kHz would be ideal.
I primarily use it for video playback and would prefer not to have the audio resampled to 44.1kHz and a low-pass filter applied by default.
 
Since the applications the device settings apply to would not be using an exclusive output, and Media Center may be used to further process the audio signal, I would definitely want to have the device set to 24-bit rather than 16-bit.
 
 
As for the speaker settings, well if you're wanting to use the WDM driver for games, or an application which outputs multichannel audio, then the device has to be manually configured as such.
I just tested it with some white noise, and it seems that the "full range" setting does nothing with the JRiver WDM driver.
The full bandwidth signal is being passed through regardless of whether it is enabled or disabled so that's one less thing to worry about.

[glynor]

I agree, and I left out the "set as default" discussion on purpose because I didn't have time to address it properly.

If I check the driver version, it is equal to the current version of Media Center. (C:\Windows\system32\drivers\JRiverWDMDriver.sys)
So as of MC 20.0.108, the driver version is listed as: 20.0.108.0
I believe it is the fact that they are incrementing the driver version every time which is the root cause of this issue.

You might be right on this, I'd have to check thoroughly.  I'd assume that it would match in 108 because they had to tweak it to fix the missing dll file issue. From the fact that the missing dll didn't cause issues, and the "update if newer" flag on the dll itself, I'd assume that it doesn't always change.  But that's a guess.  The only way I could know would be to systematically check the dll version after every install (and this assumes they aren't doing something else to cause driver version trickery).

As far as I am aware, there have not been any changes made to the driver for months.

We have absolutely no way to tell this.

If the driver is built linked against JRiver utility classes which increment, then it will re-build.  It must, or you end up with serious mismatched version issues and impossible to find bugs. JRiver has built their own entire framework (that's how we have a Mac and Linux version).

The only practical way to do this would be to totally isolate the driver from the rest of their framework, which means... Well, it almost certainly means it would never happen as a practical matter and we wouldn't have the driver at all. They'd have to copy/paste utility classes like "JRiver String" and all sorts of crazy low-level classes.  That isn't going to happen, and if it did, it'd be a terrible idea (because that old copypasted code would be orphaned).

If it happens once every six months, I can deal with re-configuring the device and other applications on my system.

Even assuming that they can isolate the driver from their frameworks somewhat, without this causing hard-to-track-down bugs, they would still need to "bump" it occasionally (I'd guess the 6-month estimate is quite optimistic).

You cannot install a driver and programmatically set it as the default.  I've looked.  There are (were) some hacks to do this under XP, but they would break with basically every service pack.  Hacking things like that, when the OS is actively against you, is a recipe for failure.

So, if you assume that when they do need to bump the version, that it will break the "set as default", this leaves you with a choice... Is it better for customers to:

1. Have a consistent experience where every time you install a new version there is a "next step" to re-set your default audio device, or...
2. For it to "randomly" break sometimes when you install a build, seemingly without cause.

Yes, for power users like you and me who watch the build notes closely and will notice the note that says "driver update, reset your thing", then #2 would be less annoying. For everybody else, consistency would be best, IMHO.

EDIT: And I meant to add, but got distracted... There is, as Jim has pointed out several times, a "solution" to this issue to make the need to fix it less frequent.  Set the auto-updater to Stable or Off.  The Stable push only happens a handful of times per year.  If you turn it off, you can update the systems where you use the WDM driver only when they have something you really need.

As I said, if they were able to fix the fact that it loses its settings, then resetting the default wouldn't be a huge deal (and it is unavoidable anyway).  I think the real issue is the combination of multiple factors... But, "not re-building the DLL" isn't very likely to be a solution. There has to be a different way.

[glynor]

I thought this was pretty clear before, but based on some PM conversations I've had, perhaps some of it got lost.

The reason I started this thread is because I agree that the status quo of losing settings each time you update to a new build of MC is not a great solution.  I'm hoping we can come up with suggestions to solve this. For the record, I've played with it a bunch, but I have not implemented the WDM Driver as the default audio device on my HTPC. The main reason I am not using it is this issue.  And, on the HTPC, I keep the auto-updater turned off, but it is still not quite worth it for me.

I do not think the solution is "simple", or it would have been solved already. Hendrik and Matt are well aware of the limitations here, and if it annoys people in the Latest build update channel, imagine how it annoys them!!

So, I'm with you that it is cruddy. I just don't think "don't update it except when you have to" is a likely solution (and, in some ways, that would be worse for some users).  But who knows, I could be wrong. Like I said, though, it isn't like Matt and Hendrik didn't notice this limitation.

At the very least, this thread can serve as a list of people who care about this particular limitation.

[RoderickGI]

I want to use the WDM Driver mainly as I want to use the MC DSP Room Correction rather than my receiver's room correction which is more difficult to set up and just isn't as good. I have all effects and DSP turned off on my receiver, and use MC for all DSP. Loosing the driver settings, and just having it not install correctly on a limited account is a non-starter for me. I used it for a while but stopped when problems arose, then tested it again at 108 and stopped again at 109, because despite being asked if I wanted to install it, the WDM didn't show up in the playback devices.

This is technically untrue, first of all.  The driver is included in the installer package with a "update if newer" flag, and is only replaced on disk if the actual version has incremented.  That's why when there was the buggy installer that didn't include the driver itself, it didn't impact some of us who already had the driver installed.

I don't believe you are correct here Glynor. See my attached images. It appears that the driver version information and the "JRiverWDMDriver.sys" file are changed with every MC update. I think that the decision to do this is the primary cause for all the problems with the WDM driver installation/setup. EDIT: I wrote this then read the rest of the thread. My position still holds.

There are many software applications that need drivers in order to work, and each version of those applications require a minimum driver version. If the current driver is too old when a new version of the application is installed, then at a minimum the user is offered the option to install the latest driver. It may get installed automatically for them. Usually driver settings will be read before these updates, and if possible (compatible) retained for the new version. I have seen more than one application installation process install a new driver, and then open the configuration dialogue for that driver so that the user can complete the process. (This may have changed with security concerns and windows UAC. I haven't been taking note.)

MC could easily use the same process, if each version of MC, and the installer, knew the minimum version of the WDM Driver that was required. The real current version of the driver is hidden, as far as I can tell. It may be 1.0, or it may be up to 1.09, I don't know. But I would be pretty sure that the driver isn't updated with every MC release, except for its apparent version number. After all, the inputs are not going to change for the WDM Driver; they are the Windows audio outputs. Also, the outputs of the WDM Driver would not change often; only when MC inputs change. If the inputs and outputs of the driver don't change, there is no need to update the driver, even if it was built on an earlier MC code base. Making this work is simply a software design choice.

Setting an audio driver to the default device is problematic, as it is a security issue. If malicious software could install a new audio driver and make it default, the driver could take over your system. So the installation package can't set the new driver as default. However, I suspect MC could when it was restarted after an update, if the WDM Driver setting was selected. Of course there would need to be elevated privileges, and hence another UAC prompt when MC was restarted.

As to the other WDM Driver settings, such as number of channels, sampling rate and bit depth, I'm not sure why they have to be set at all. I would prefer that the WDM Driver simply act as a conduit to accept the audio output of any Windows application, whatever the format is, and pass it as input to MC, which would then do any and all audio processing. Why can't the input format just be detected and passed through? I know that the Windows Driver Module protocols are difficult, and may restrict such an approach, but would it be impossible? That would get around the issue of Windows doing any resampling just to pass the audio to the WDM Driver.

[glynor]

I may very well be wrong about the updating on each version thing. I did not check. But I did see it was flagged as update if newer, and with the thing that happened with the missing driver in the installer, I suspected that it might not be every time.

So, sorry if I guessed wrong. They probably do link against utility classes and rebuild the driver with each install. Perhaps they can change it, but I suspect the guesses here are very uninformed about what it would take to do so.  I don't know, but I do know a little about it, and I strongly doubt it is as easy as some are making it seem.

and just having it not install correctly on a limited account is a non-starter for me.

This has been brought up twice. Please try to do what Hendrik suggested and report back in that thread if it doesn't work:

You could probably fix it by running MC itself as Admin, and then changing the setting there.

After that, there was a bunch of noise in that thread.  I think there's some misunderstanding, but it makes more sense to comment on that there (which I'd been meaning to do).  In any case, do what he said and it should fix you up. You only need to do it once.

There are many software applications that need drivers in order to work, and each version of those applications require a minimum driver version.

That's a wildly different thing. You're talking about applications requiring hardware drivers made by different vendors. This is a driver that does something within Media Center itself. It is part of Media Center.  Not the same thing and not relevant. I'd be shocked if you could find a true comparison to what is being done here by anyone else, and certainly not by a small indie software shop.

Unless we're looking at the code, or they tell us, we have no idea how complicated it is to extract the code bases from one another. If you've never written any C++ code at all using DLLs, then you really have no idea. So stop guessing.

As to the other WDM Driver settings, such as number of channels, sampling rate and bit depth, I'm not sure why they have to be set at all. I would prefer that the WDM Driver simply act as a conduit to accept the audio output of any Windows application, whatever the format is, and pass it as input to MC, which would then do any and all audio processing. Why can't the input format just be detected and passed through? I know that the Windows Driver Module protocols are difficult, and may restrict such an approach, but would it be impossible?

Yes. It is impossible because you can't control what the other applications are doing, by nature. They just play audio to the default audio framework in Windows. This sends it down the DirectSound audio chain, which does all the processing and hands it to the driver in the default format set in Windows (not by the driver).  The audio data gets to the driver last, after all that has happened.

Are there other ways the other applications can use the frameworks?  Sure. There's WASAPI.  But JRiver can't make all the other applications in the world not use what they want to use. Heck, even VLC player doesn't use WASAPI.  So, they have to be able to catch DirectSound and all the other "dumb" APIs, but they're at the end of the chain, and Windows has already converted it to the default format before it gets there.

Technically, could they maybe inject themselves in front of DirectSound and intercept the API calls and hijack them?  Perhaps, but again, for this feature?  That would probably take a mountain of engineering time, only to be broken with the next Windows Update. Not to mention that it might get you called "malware", is absolutely going to be fragile and flaky, and there's no way I'd ever install such a thing on my systems. Installing system hooks that hijack data is a tough road.

So... That brings us to:

1. The driver can control what audio formats it supports.
2. It can't control the default format selected by the user or by Windows itself.
3. It can't reliably guarantee that it has been picked as the default, and each time it updates itself (which it has to do occasionally, at least) this will probably get broken.

I don't know how to solve #3.  But, you can solve #2 by only reporting back one supported format for #1.  If there are any good suggestions for how to solve #3 with working code examples, I'm sure Hendrik would love to take a look.

[glynor]

I don't know how often the driver itself changes, but based on filesize comparison I would guess not every build (or not even every several builds).

FYI, file size tells you nothing about how the linking works internally. I'm sure the code inside the driver classes themselves is probably done and doesn't change much at all.

But code within the driver almost certainly calls other classes stored in JRTools.dll and other utility dlls that MC uses. The way you call code in dlls in C++ is generally by reference pointers. So, if JRTools.dll changes, then the compiler changes reference addresses within JRiverWDMDriver.sys to point to the altered code in those external dlls.

The references are the same size. The source code itself in the classes used to create JRiverWDMDriver.sys doesn't change. But the output from the compiler that is JRiverWDMDriver.sys does change. This could break each time you make any change to any external dll that it uses.

There might be a way around this using implicit linking, like you would when using a third-party library (and like they probably do when using lav or whatever).  But the driver is also very latency sensitive, so they probably want to use all the compiler optimizations they can. I don't know, but since they haven't done it this way, I don't think it is because they're too stupid or lazy to do it "right".  It is for a reason.

[glynor]

As far as the setting the default driver thing... Here's a good description of why they probably won't set the default audio device themselves.
http://stackoverflow.com/questions/2175318/how-to-change-default-sound-playback-device-programatically

There is no public API which allows you to change the default audio device, that is functionality that is considered to be under the users control. This has always been the case in Windows.

Having said that, if you search the web, there are a number of people who have reverse engineered the APIs that are used in Windows Vista to do this, but I'm not going to point you to them (the reverse engineered APIs are internal unsupported APIs and may change without notice from Microsoft). You use these solutions at your own peril.

You can do it. It looks like you basically just have to poke at some undocumented registry keys, but... There's no public API supported by Microsoft. Anything they do won't work on both XP and Vista/7/8, so they'd have to write the system twice. And there's no guarantee it won't break with the next Windows Update or not work on random people's systems in Taiwan, or whatever.  As the guy says in the stackoverflow answer, you do so at your own peril.

That said... You can find applications that will do it.  Flaky abandonware apps, mostly, but you can find stuff out there that does it via the undocumented API.  There was one called Vista Audio Changer that could do it with all sorts of fancy options, including monitoring for a particular process and switching the audio device when it saw it (used to set different settings when WinAmp or Foobar is launched, I'm sure).  But then you have to run an always-resident app from "some dude" to do this, and the project was last updated in 2013, and his website is offline and the domain name isn't registered anymore.

There are a bunch like that. I used to use a program called SoundSwitch to do it, but that guy switched to OSX quite a few years ago and said "sorry, I don't care, no more updates" on his project. I think it is broken now on Windows 8.

There's this:
https://github.com/sirWest/AudioSwitch

Which I've never used, but looks like someone ganked the code from SoundSwitch and modernized it a bit.  It, at least, looks like it is still somewhat active, and it seems to have command line options, so you should be able to script it.

There's also this:
http://www.nirsoft.net/utils/nircmd.html

Which seems to be from a still active programmer of some kind (he's still writing to his blog, anyway) and he has a command line tool in there that will do it.

So, I think you can easily script it.  You can probably script it to set it for you at every boot, or whatever you want.

Maybe JRiver would be willing to use some of this kind of code to do it themselves.  But, like the dude said in the StackOverflow article... There is no API, and Microsoft doesn't want you to do it.  So, you do so at your own peril.  If it was me writing it, I probably wouldn't.

[stewart_pk]

I don't know for sure, but I'd bet you $50 that for almost all of them, they are DirectSound players, which means that in order to get it to spit out the right sample rate, DirectSound resamples it for them. So, this means... For all but the rarest of circumstances, the only "correct" options to select, for sample rate, are 44.1kHz or maybe 48kHz.  Everything else is going to resample through the dumb Windows resamplers, and you're defeating yourself (it would be better to take it in native and then let MC resample it if needed or desired).

I use the WDM driver exclusively with PowerDVD to play 3D bluray discs. So audio is coming from PowerDVD at 48KHz and if I set the WDM device to 96Khz I get a huge amount of latency, like 1-2 seconds. With the WDM device set to 48KHz I get very low latency, it's good. So yes I've found it's best to match the WDM driver sample rate to the application.

Good thread by the way!

[RoderickGI]

On setting the default audio driver issue, it may be sufficient to launch the Windows Playback Devices dialogue, so that users can see which device is default and change it if they desire.

I'm not sure if there is still an API or method of launching that dialogue from an installation script, but I am fairly certain I have used Windows XP programs which had that capability.

[mwillems]

FYI, file size tells you nothing about how the linking works internally. I'm sure the code inside the driver classes themselves is probably done and doesn't change much at all.

But code within the driver almost certainly calls other classes stored in JRTools.dll and other utility dlls that MC uses. The way you call code in dlls in C++ is generally by reference pointers. So, if JRTools.dll changes, then the compiler changes reference addresses within JRiverWDMDriver.sys to point to the altered code in those external dlls.

The references are the same size. The source code itself in the classes used to create JRiverWDMDriver.sys doesn't change. But the output from the compiler that is JRiverWDMDriver.sys does change. This could break each time you make any change to any external dll that it uses.

There might be a way around this using implicit linking, like you would when using a third-party library (and like they probably do when using lav or whatever).  But the driver is also very latency sensitive, so they probably want to use all the compiler optimizations they can. I don't know, but since they haven't done it this way, I don't think it is because they're too stupid or lazy to do it "right".  It is for a reason.

Like I said in another context; I assume if the fix were easy, it would have already been done    

I'm not sure what that last bit of your response was in reference to, but I sincerely hope nothing I said could be read as impugning anyone's diligence or honesty.  I have great faith in the team, and always have.  The folks at JRiver have been very good to me over the years.  If I continue to complain about this issue, it is only because the de-defaulting issue continues to be a source of anxiety for me, and I hope there might be a solution somewhere.

My computer is hooked up directly to my amps, and the driver de-defaulting behavior often sets my actual sound card as the windows default, cutting JRiver out of the loop.  I have a maximum volume set in JRiver because my speakers will play very loud at maximum digital volume, and anything that auto-magically "defeats" using JRiver as my volume control/protection is a source of angst for me.  Before I figured out the issue, I had a few cases of unexpected >100dB system sounds or youtube videos, which is very bad for domestic tranquility.  Turning off auto-update on all my machines mostly solves it, along with double-checking everything after updates.  But it leaves me ill at ease for obvious reasons (I am an imperfect setting changer, and I'm dealing with four or five systems).

I try not to bring up this side of it too often as I don't want to spread FUD about an otherwise rock solid digital volume control system, but if I could have one wish in MC 21 (unconstrained by technical limitations), fixing this would be it.  I recognize it may not be possible, but I can dream  

[glynor]

I'm not sure what that last bit of your response was in reference to, but I sincerely hope nothing I said could be read as impugning anyone's diligence or honesty.

Not directed at you.  Not directed at anyone, really.  Just 2am and thinking out loud.  

On setting the default audio driver issue, it may be sufficient to launch the Windows Playback Devices dialogue, so that users can see which device is default and change it if they desire.

I'm not sure if there is still an API or method of launching that dialogue from an installation script, but I am fairly certain I have used Windows XP programs which had that capability.

Windows XP had a completely different audio API (which is why apps that could change the default audio device on XP don't work on Vista and newer).  But maybe!  Dunno.

It would seem like you could just run the application, I suppose.  It might be confusing if not explained.

There's also this:
http://www.nirsoft.net/utils/nircmd.html

Which seems to be from a still active programmer of some kind (he's still writing to his blog, anyway) and he has a command line tool in there that will do it.

So, I think you can easily script it.  You can probably script it to set it for you at every boot, or whatever you want.

I think one of you should try this out, as I think it would work and basically solve the problem.  Here's a tutorial on how to use the nircmd utility to make "quick-switch" shortcuts.  You could just as easily make a BAT or VBS script that runs at login, and make a shortcut to it in Start.

So after you install a new build, you'd just have to run a BAT file or reboot to get the default audio device back to MC.

That doesn't solve the settings saving, but I think they could solve that problem without getting into hacked, undocumented APIs.  Not as clean as something built-in, of course, but it could work.

[6233638]

As far as the setting the default driver thing... Here's a good description of why they probably won't set the default audio device themselves.

The issue for me is not that they aren't setting themselves as the default device, it's that the device is being removed/replaced with every MC update, which often changes its order in the device list.
I am not concerned about what is the default device in Windows, I am concerned that many applications select their audio device based on that list order, so when it changes position, sound is suddenly playing to the wrong device.
 

 
Yesterday, Media Center was device #0 on the list. A few days ago it was #4.
I have to launch this program from the command line in verbose mode to figure out what the current device numbers are so that I can send audio to the correct one.

There are a handful of applications on my system where this is an issue.
Audio either plays to the wrong device, I am forced to select a device again for anything to happen, or I will receive an error that the device is missing.
 
Changing the status of the default audio device in Windows upon installation of a new version of MC is not a major issue for me.

There's this:
https://github.com/sirWest/AudioSwitch

Which I've never used, but looks like someone ganked the code from SoundSwitch and modernized it a bit.  It, at least, looks like it is still somewhat active, and it seems to have command line options, so you should be able to script it.

I use AudioSwitch all the time. Because many applications (games in particular) don't have the option to set an output device and just play to the system default, I find it very useful so that I can send the audio to MC, to my headphones, to my 5.1 setup etc.

[RoderickGI]

Windows XP had a completely different audio API (which is why apps that could change the default audio device on XP don't work on Vista and newer).  But maybe!  Dunno.

It would seem like you could just run the application, I suppose.  It might be confusing if not explained.

I think one of you should try this out, as I think it would work and basically solve the problem.  Here's a tutorial on how to use the nircmd utility to make "quick-switch" shortcuts. 

Yeah, I was thinking of the installation processes on XP, rather than the audio API.

If the MC installation script checked the WDM setting and then did an install of the WDM, it could launch the Playback Device dialogue and retain an installation window explaining why this was done, then watch the Playback Device dialogue window so that when it is closed, installation completes and MC restarts. That would give users the prompt and instructions required. Whether a user just closes the dialogue with no changes, or changes the default, the installation would complete.

That may break automatic updates though, and doesn't solve 623's audio device sequence issue.

I have looked at and used the Nirsoft utilities before, and I'm just a little uncomfortable using them as a solution. The utility set is quite powerful and a bit closer to a set of hacks than I like. While many people love Nirsoft, they aren't really on my trusted supplier list. I would be happier to have the Playback Device dialogue pop up and prompt me to change the default device.