Default device override not working for Battle.net games?

[pannal]

I'm trying this with this guide. Added the Battle.net folder to the SAR applications and tried Overwatch. It keeps playing back on the "Application" device, not the "Games" device.

Is this known? Do you need more technical details?

Thank you!

Edit: Windows 10 pro with ASIO4ALL

[pannal]

I think this is related: https://github.com/audiorouterdev/audio-router/issues/24

[eiz]

Not sure if related. SAR uses a very different method of overriding the default audio device than audio-router, but it's plausible that some anti-cheat software could break it. I don't have a copy of the game and haven't tested it.

Mind checking its handle list using Process Explorer? See if you see SarAsio.dll in its list of open files.

[pannal]

Yes it is (SarAsio_x64.dll).

[stkfd]

@pannal, you were saying you added the Battle.net folder to the SAR applications; could you share the exact expression you used? Adding whole folders only works by adding a regular expression that matches everything in it, maybe something went wrong with that expression.

I wrote that guide by the way ;)

[pannal]

Sure, but the regex is correct, as Hearthstone and other Battle.net games work in SAR. I was so desperate at one point, because I thought my regex was wrong, that I ended up using .+GAMES.+, which is the root folder for Steam and Battle.net.

[eiz]

This appears to have nothing to do with Overwatch specifically. The problem is that Overwatch is using the XAudio2 API, which appears to have some backdoor way of getting the default audio device. It only calls IMMDeviceEnumerator::GetDevice, never IMMDeviceEnumerator::GetDefaultAudioEndpoint. Same problem happens with the basic playback example from the XAudio2 SDK samples. I'll see if I can find a solution.

[pannal]

Awesome. I love the work you're doing here. Any news on a new beta?

[eiz]

Need to complete a few bug fixes first. Kind of slow going atm due to work related reasons.

I'm taking a closer look now and it appears that XAudio2 is creating its renderer by calling ActivateAudioInterfaceAsync with DEVINTERFACE_AUDIO_RENDER, which goes straight into MMDevAPI's internal endpoint lookup code. ActivateAudioInterfaceAsync is implemented by an undocumented coclass ActivateAudioInterfaceWorker (E2F7A62A-862B-40AE-BBC2-5C0CA9A5B7E1) which could be intercepted, albeit at the cost of introducing a dependency on an undocumented interface. Going to give it a shot.

For completeness, other options would include hijacking the export out of MMDevAPI (very intrusive) or hijacking the top level XAudio2 COM interface (less comprehensive, other code that uses ActivateAudioInterfaceAsync wouldn't be covered). I consider CreateRemoteThread type approaches (e.g. used by audiorouter) off the table.

[eiz]

This is now fixed in master. Doing some more local testing and will get a package up soon.

[pannal]

You're the best. Do you have DEV instructions laying around somewhere for me to follow? I could test the latest master by myself.

I'm a developer myself (although, more Python-focused), so I should get through it.

Something like: install these requirements, build using that toolchain, sign with test key, fire away.

[eiz]

Here is a build. This is not adequately tested for release. Should your machine catch fire, don't say I didn't warn you.

SynchronousAudioRouter_x64_0_13_debug_20170417.zip

Notes:

• Not tested on anything but win10 x64
• Contains a SAR NDIS driver for future networking support. Currently does nothing, should be harmless, but ymmv
• There's significant changes to the installer
• Debug logging is on, make sure your %APPDATA%\SynchronousAudioRouter\logs doesn't fill with too much spam
• Seriously, if it bugchecks, don't be surprised, I haven't even run this under Driver Verifier yet.

I don't have actual development instructions, but basically you need VS 2015 with all the C++ and ATL/COM stuff installed, the Windows Driver Kit, and WiX 3.10. Build defaults to test signing which you can Google how to enable loading test signed drivers. Debugging is best done with a 2 machine setup (I use a pair of Firewire cards for 1394 debugging).

[pannal]

I'll try it, haven't had the time yet, sorry.

[pannal]

Works. Also I don't have to quit reaper before going into sleep with the newest release (resulted in a bugcheck bluescreen).

Seems to work well for now.

[pannal]

Yep, runs well.

[pannal]

Ok, no issues since 3 days. Runs well, works with all games yet, and survives standby.

Great job!

[eiz]

Thanks for the feedback. I assume you were hitting the registry filter bugcheck I fixed. IRQL_NOT_LESS_OR_EQUAL or something to that effect?

Edit: actually I'm not sure you could have ever hit that. Do you have any files in C:\Windows\Minidump with the crash info? I could use that for verification purposes.

[pannal]

Exactly. I had to stop reaper before letting my PC go to standby before, otherwise I'd get exactly that bugcheck.

Edit: I had, yes. But that got cleaned up on the last cleanup run, I'm sorry.