alcReopenDeviceSOFT fails with Creative router

[dbregman]

Is it expected behavior that alcReopenDeviceSOFT only works when using the OpenAL-Soft router dll?

Using the original router DLL from https://www.openal.org/downloads/, I create an OpenAL-Soft device: alcIsExtensionPresent(device, "ALC_SOFT_reopen_device") returns TRUE alcGetProcAddress(device, "alcReopenDeviceSOFT") succeeds. but alcReopenDeviceSOFT fails when called.

When using the OpenAL-Soft version of the router, everything works.

[kcat]

It's unfortunately a limitation with Creative's router, which wraps the ALCdevice (and ALCcontext) handles returned by OpenAL Soft and other drivers with its own, so the driver can't recognize the device handle the app passes to extension functions. OpenAL Soft's router does more to stay out of the way between the app and driver, so driver-specific extensions that rely on device and context handles like that will work. And using OpenAL Soft directly without any router will also work.

With newer versions of OpenAL Soft, there is a workaround. Basically follow the Direct Context extension example to "bootstrap" the device by using the driver functions directly, bypassing Creative's router. That extension basically exhibits the same issue, the ALCcontext handle from Creative's router won't be recognized by the Direct API functions, necessitating that workaround. You don't need to use the Direct API functions beyond alcGetProcAddress2 if you don't want to, but you will need to dynamically load the ALC and AL functions you want to use with that function.

[dbregman]

Thanks for explaining. I'm surprised this question wasn't asked before, at least it didn't come up in my search.

In theory could OpenAL-Soft detect the creative router and unwrap the device handles?

What are the pros and cons of using the bootstrapping vs just shipping the OpenAL-Soft router with my installer?