[openal] Making OpenAL Soft more "portable"?

Chris Robinson 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
> way

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 
higher latency.


More information about the openal mailing list