-
Notifications
You must be signed in to change notification settings - Fork 524
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add some option to hit an hotpath of the original router device selection #757
Comments
Spoofing this "properly" turns out to be a bit more difficult than anticipated. Adding a unique user-specified name to the enumeration lists isn't that hard, nor would it be hard to open the default device when trying to open it. However, if the spoofed name is opened, having that device report back that spoofed name as its name is a bit more involved. Another possibility would be an option to simply exclude the "OpenAL Soft on" part of the names, and return the full device list for basic and full enumeration. Essentially treating it as if each device on the system is provided by a hardware driver. This could be a problem if there's an actual hardware OpenAL driver also providing the device with a plain un-prefixed name too, though (and I wager if someone has an X-Fi or Audigy card, that would likely be the case). |
?
I'm getting lost here.
Yes, that's what I suggested in the first paragraph.
Perhaps "dll names" precedence would dictate the winner. @Kappa971 |
Right, but it's not that simple. The alternative would be to just pretend to be one or more hardware devices, and drop all references to being OpenAL Soft (in the device names, at least). |
Yes, that's actually what I was suggesting in the first scenario. In the second one instead
Lmao, I just noticed that my little hack didn't affect the second query, yet for my intents and purpose it was good enough. |
I have done some test in another discussion/issue. If I remember correctly, the OpenAL router looks for "X-Fi" in both the OpenAL device name and the system device name. In my case it is Another way is for the Windows device and the OpenAL device to have the exact same name, for example If none of the above is valid, the router checks for |
Yes, that's what we were wondering. But who wins eventually? And I imagine that you are getting two devices (with the same name) that you can hardly distinguish otherwise?
It's not like they can check what doesn't exist...
This idea got me cringing. The wrap_oal.dll entries weren't winning (in my last comment) because of some randomness. |
To know if the first two conditions are valid, I think the router actually checks if those names exist.
I can't give you a technical answer, but from what I understand, Creative's OpenAL router does certain checks:
If the name "Generic Hardware" causes no conflict, it would solve the problem. Otherwise uninstall Creative's OpenAL router and rename soft_oal.dll to OpenAL32.dll and paste it into System32/SysWOW64. I guess "Generic Hardware" is the name of the device in wrap_oal.dll using DirectSound3D. It is probably something dating back to Windows XP and with Sound Blaster cards not supporting OpenAL. On modern versions of Windows it would probably never be detected (perhaps forcing it with ALchemy and removing ct_oal/sens_oal or any other driver, but it wouldn't make sense). |
We have the source code of the router.. there isn't much to guess, only to be smart enough to comprehend it well. Here you can see the former (notice how "playback device name" based entries will always strictly win over the generic renderers) Lines 591 to 620 in 3bedb2b
And here's the later (set aside the first priority, and just focus on what that "all devices list" would mean for partial matching) Lines 689 to 706 in 3bedb2b
Of course every "XX device driver on YY playback device" is always gonna match the YY playback device name! This includes openal-soft unsurprisingly, but this time "Generics" are in here too. And the "Find Device" function is just a stupid for loop, that will break off on the first match. So.. uh, no. The "Generic Hardware" idea wouldn't help the slightest for our last problem of If not any if you don't want to tinker with the folders of every single game you install (full disclaimer: I don't really know of any one that employs this ~2007 extension as opposed to the old one, your opinion is welcome on whether we should even care then as a matter of principle or not) |
What is the point of this useless and long discussion? Neither is a programmer and arguing by making others seem to understand what you are talking about is ridiculous. I can notice that in ALC_ENUMERATE_ALL_EXT OpenAL Soft is already set as default device so I don't think there is anything to do here. |
The point, which I already stated, is just for people not having to manage every single game. You don't really need to touch the registry to change device name, but yes "Generic Hardware" could certainly avoid any extra bother once you assume Vista+ (my vagueness was just due to fact that I cannot hex edit such a long name, and thus I couldn't test it directly). But if |
Well, well, well.. I may have unduly blamed the router beforehand, but while fishing for A selected number of developers (I reckon those with new enough of an interest to look into openal after 2007) also did actually switch to using https://github.com/OpenMW/openmw/blob/openmw-0.47.0/apps/openmw/mwsound/openal_output.cpp But with all of this said then, not all is doom and gloom eventually. Lines 1860 to 1861 in 3bedb2b
The router itself is still relying on the default device from ALC_ENUMERATION_EXT for alcOpenDevice(NULL) calls.And IMHO games fancy enough to have incorporated the newer extension should also be fancy enough to still have somebody somewhere supporting them somewhat (hell, some recent ones even outright decided to just come built-in with openal-soft and screw everything else). So not all is lost for the ALSOFT_NAME camp, which I think is the best shoot at trying to eat one's cake of 100% simple compatibility and have it too with "Enumerate All" features (just remember for the string to be a strict superset of "Generic Hardware", to avoid the consequences of XP-drivers hate).
But the tentatively named |
Of note that (of course, duh) older OpenAL routers would only have Btw "Generic Hardware" may only be accepted if it's perfectly matching with the device name here (if it even works at all.. though again I cannot really be certain without actual testing). Meaning that we are kinda back to square one about any one solution being strictly better than the others. |
#1001 (comment) waveOutMessage((HWAVEOUT)0xffffffff,0x2015,(DWORD_PTR)&UStack_c,(DWORD_PTR)auStack_10);
waveOutGetDevCapsA(UStack_c,&tStack_48,0x34);
if (*(int *)(iStack_14 + 0x28) == 0) {
pFVar2 = GetProcAddress(*(HMODULE *)(iStack_14 + 4),"alcGetString");
*(FARPROC *)(iStack_14 + 0x28) = pFVar2;
}
_Str1 = (char *)(**(code **)(iStack_14 + 0x28))(*(undefined4 *)(iStack_14 + 0xfc),0x1004);
if (*(int *)(iStack_14 + 0x24) == 0) {
pFVar2 = GetProcAddress(*(HMODULE *)(iStack_14 + 4),"alcIsExtensionPresent");
*(FARPROC *)(iStack_14 + 0x24) = pFVar2;
if (pFVar2 != (FARPROC)0x0) goto LAB_0094e67e;
}
else {
LAB_0094e67e:
cVar1 = (**(code **)(iStack_14 + 0x24))(*(undefined4 *)(iStack_14 + 0xfc),"ALC_ENUMERATION_EXT")
;
cStack_5 = '\x01' - (cVar1 != '\x01');
if (cStack_5 != '\0') {
while( true ) {
if (_Str1 == (char *)0x0) {
return 0;
}
iVar3 = _strncmp(_Str1,tStack_48.szPname,0xff);
if (iVar3 == 0) break;
do {
pcVar4 = _Str1;
pcVar5 = pcVar4 + 1;
_Str1 = pcVar5;
} while (*pcVar4 != '\0');
_Str1 = pcVar4;
if ((*pcVar4 == '\0') && (_Str1 = pcVar5, *pcVar5 == '\0')) {
return 0;
}
}
if (_Str1 == (char *)0x0) {
return 0;
}
goto LAB_0094e710;
}
}
if ((_Str1 == (char *)0x0) || (iVar3 = _strncmp(_Str1,tStack_48.szPname,0xff), iVar3 != 0)) {
return 0;
}
LAB_0094e710:
_strncpy(param_1,_Str1,0x103);
param_1[0x103] = '\0';
return 1;
} Across as far as I could decompile from Just Cause (gamecoda 2) there are no further "generic" checks, there is no soundblaster or audigy partial matching - just presumably EDIT: of note that while that's pretty much exactly what the openal router was doing once upon a time, and god willing directsound shouldn't return different names, MMSYSTEM enumeration has MAXPNAMELEN which is only 32 characters long (31 once accounted for the null termination). And in this sense, I think it could be safely assumed this limitation is carried by at least all the older openal 1.0 software |
So, with that being the premise (an exact match being required), and with Windows not even allowing to rename audio devices enough (even if you tinker with And since you don't want switching between your monitor's speakers and your headphones to be a bother, it should be an automatic thing always tracking PKEY_Device_FriendlyName. And then maybe this could be also just one additional name to The only question I still have now, was for a decent name for it. * the openAL router actually seemed to be aware of this possible incongruence, but they completely forgot about it in the latest versions |
See #650 (comment).
In order to play nice with Creative's official OAL router (and yes, this seems the only loophole to avoid recurrent maintenance of either system or games folders) the device name is key.
openal-soft/alc/alc.cpp
Line 919 in b8d73a2
The best way to this aim, if not any because it would be entirely addressable within openal-soft, would be for its name to always match whatever the current default device in windows is (as per K971's observations). But AFAICT this would break total mayhem in
ALC_ENUMERATE_ALL_EXT
querying....unless perhaps the same knob also enabled "soundblaster-like behaviour" (i.e. only care about a single device, don't report "XX on YY")?
And so the next (and only other possible) solution would be to rely on the "partial name match" path.
I'm not 100% sure on how exactly they filter the list of the available implementations depending on the name of the current device.. but anyway long story short, if both the device and the openal driver have "X-Fi" or "Audigy" in the name they get more priority than the godawful "Generic Software" fallback.
And so, rather than just relying on some other kind of hardcoded strings, I thought that we could as well just use an environmental variable to arbitrarily change the name (so that you wouldn't have to include in the repo those names, or other awfully similar puns).
Of course the user would also have to be instructed to rename their playback device, but this is another matter.
p.s. I had originally started this feature request to just propose the second idea, but throughout the writing of the premise (and of the logical implications that would entail there aren't other ways to make OpenAL32.dll happy) the first oddball emerged too.
I'm not asking for both, or even one of them in particular.. but yeah. For the moment, after all this brainstorming I'd just like to receive a reality check if I haven't missed anything else.
EDIT: and it's ironic that they were the ones warning against "second guessing"
The text was updated successfully, but these errors were encountered: