Skip to content
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

Are any OpenAL Soft extensions actually device dependant? #1096

Open
YanniZ06 opened this issue Jan 19, 2025 · 4 comments
Open

Are any OpenAL Soft extensions actually device dependant? #1096

YanniZ06 opened this issue Jan 19, 2025 · 4 comments

Comments

@YanniZ06
Copy link

This question might come off as weird, but as a matter of fact the API (more or less) states that querying alcGetProcAddress and alcIsExtensionPresent may require a device as an input to obtain proper results.

However I've asked myself in which situation (if at all) this would actually be the case, as checking for each individual extension for each new device you setup quickly becomes cumbersome.
I personally expected extension-functionality and support to be audio-card dependant, not directly output device dependant. What I could also see within reason would be querying for the entire soundcard using just one device as an input once (albeit strange it would not be nearly as annoying and somewhat make sense).

I couldn't find an answer to this anywhere online and it is something I have really been wanting to know for quite some time now, I'd very much thank you if you could get back to me on it whenever you have time :)

@kcat
Copy link
Owner

kcat commented Jan 20, 2025

As far as OpenAL Soft itself goes, no, all devices will support the same extensions. As a software-based implementation, it only relies on the device to output the audio, while all the mixing and effects are done without using any hardware capabilities.

If you're not on Windows (where there aren't hardware drivers or a router DLL), or if you are but are using OpenAL Soft directly without the router DLL, then extensions and functions will be the same across all devices and contexts. Individual drivers can make guarantees for the same extensions across all devices it makes available, but the OpenAL API itself can't make the assumption that all devices will always have the same features.

In particular, the router DLL on Windows manages access to multiple OpenAL drivers simultaneously through the one API. So you can have OpenAL Soft, Generic Software, Generic Hardware, Rapture3D, and Creative hardware drivers all accessible as different OpenAL devices to the program, all with their own feature set, with different drivers also able to use the same output (e.g. OpenAL Soft and Generic Software can output on the same hardware device, but provide their own features). Similarly, different drivers will have their own implementation of functions (e.g. the alGenEffects from wrap_oal.dll isn't the same as the one from soft_oal.dll, so if you get alGenEffects from the wrapper driver, but try to call it with an OpenAL Soft device/context, OpenAL Soft won't notice since it's not its function).

@YanniZ06
Copy link
Author

Thanks for the quick reply ! Makes a lot more sense this way. I was gonna assume that, since its a software implementation, the hardware of the user should be irrelevant, I just wasnt sure to which extent.

If I may add onto it, assuming i use the driver provided by oal_soft.dll, shouldnt all extensions (that are supported and documented on the openal soft site) be available no matter what hardware im running? Or are there still possible hardware complications that could somehow limit the software implementation? Does this carry over to extension properties (like max auxiliary sends on efx) too? And if I were to depend on a linux user to install the/any linux-openalsoft package could that same guarantee be kept or could they end up with a slightly different router?

@YanniZ06
Copy link
Author

Rereading this for the 5th time Im starting to think the first part of my question sounds stupid, as generally with drivers one driver always universally supports a certain set of functions. My linux related question stands though (as I find the way openal (soft) is handled there a tad bit confusing)

@kcat
Copy link
Owner

kcat commented Jan 20, 2025

If I may add onto it, assuming i use the driver provided by oal_soft.dll, shouldnt all extensions (that are supported and documented on the openal soft site) be available no matter what hardware im running? Or are there still possible hardware complications that could somehow limit the software implementation? Does this carry over to extension properties (like max auxiliary sends on efx) too? And if I were to depend on a linux user to install the/any linux-openalsoft package could that same guarantee be kept or could they end up with a slightly different router?

On Linux there is no router. At most, they may get a different OpenAL Soft version from their distro, but whatever they get will have the same features on all devices (so if you're relying on an extension, especially newer extensions, you should still check for it and handle the error gracefully, but if it's available on one device it should be available on all others). Extension properties are a little more flexible; something like the max auxiliary sends may be the same across devices, since it's not dependent on hardware capabilities for OpenAL Soft, but something like the output mode can support different modes on different devices (e.g. a stereo device may not allow setting ALC_SURROUND_7_1_SOFT, while a 7.1 surround sound device does) since it does depend on the device configuration/capabilities what OpenAL Soft can output. In such cases, you can still make the request, but you'll need to check the result of what got set for each device independently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants