[openal] Making OpenAL Soft more "portable"?
chris.kcat at gmail.com
Sat Jun 4 10:45:55 EDT 2016
On 06/04/2016 06:37 AM, Marvin -SShock wrote:
> It could be implemented as an OS-specific feature then, but I can
> understand if you hesitate to make OALS too platform-dependent this
It's a possibility. Typical Linux systems will have /proc/self/exe,
which is a symlink that can be used with stat() to get an executable
path. I think some other Unix-based systems may have something similar.
>> Unfortunately I don't think there's anything I can do from OpenAL
>> Soft. Even if it was a good idea to change the device's sample
>> rate, I don't think it can be changed by normal processes (it's a
>> system setting that only users with elevated or admin privileges
>> can change, I believe), and Windows' audio system doesn't support
>> resampling on its end, requiring the client to provide audio in the
>> native rate.
>> Ultimately it's better to advise users that they don't really need
>> to go above 44.1 or 48khz for normal audio playback. Unless they're
>> doing studio-grade work with studio-grade equipment, 96khz and up
>> won't gain anything except higher CPU use.
> That's a bummer. So some level of user internvetion is aloways
> required, then.
It is an option to use the DSound backend, which can handle mismatched
sample rates. Although it has limitations, and since it sits between
OpenAL and the audio server/service, it's adding to the amount of work
even if resampling isn't needed, with a bit more CPU use and probably
More information about the openal