[openal] Making OpenAL Soft more "portable"?

[Luís Felipe Safady]

Hello, something just occurred to me and I need to ask.
How does OpenAl Soft handles mismatched sample rate frequencies on Windows
when using HRTF?
Windows will always resample automatically even when mismatched, so OpenAl
Soft doesn't even need to care what frequency the sound card is set as
everything will just work (maybe not when using WASAPI, but I believe
DirectSound is the only backend for Windows that is implemented).
The error that OpenAl Soft throws when the sample rate is mismatched makes
me think that it disables HRTF when it happens.

Also, for some reason the version 1.17.2 on Windows is outputting that
bsinc, sinc8, sinc4 are not supported as a resample algorithm on the log
for some reason, and this is strange as the code on line 230 in mixer.c
should be correct. Is the binary in the zip file the correct DLL? (I just
tested 64-bit)
I still need to compile OpenAl Soft myself to be sure.
Em 03/06/2016 21:06, "Chris Robinson" <chris.kcat at gmail.com> escreveu:

> On 06/03/2016 11:52 AM, Marvin -SShock wrote:
>
>> I really like your work and I'm currently interested in getting
>> OpenAL Soft with HRTF to work in Dark engine games, see here:
>> https://www.systemshock.org/index.php?topic=8371.0
>>
>
> Hi. Cool, thanks. :)
>
> One hurdle in getting more people to try OALS is the installation
>> process. To install OALS one has to have at least a basic
>> understanding of the OS which some users might lack.
>>
>
> Yes, unfortunately Windows installers isn't something I've learned how to
> do yet. It'd be nice to have an installer that'll automatically put the
> DLLs in the right place for all apps to see, install the config utility
> with a start menu entry (or wherever it would go these days), and install
> the HRTF data sets to where OpenAL Soft will find them.
>
> This is where
>> fanpatches can help. However, the user would still have to change the
>> OS sampling frequency to match the HRTF table, plus the author of the
>> SS2 fanpatch is against making his tool change files outside of the
>> game folder, possibly because of security concerns. Is it possible to
>> change OALS in such a way so as to use it as a drop-in, fully
>> portable replacement? Let's say the game is set up to recognize OALS,
>> this would require
>> a) having OALS look for the alsoft.ini inside the
>> game folder (it already does this for HRTF tables, so why not the
>> ini, too?)
>>
>
> The main issue is that the "game folder" isn't a particularly well-defined
> place. On Windows it's relatively easy to get (IIRC, there's a function
> call to get the full path to the process's executable), but on Linux, the
> idea of a game folder is actually pretty hazy since executables, data, and
> configs are installed in separate places -- and even in cases where the
> whole game is in a self-contained directory, there's no safe and portable
> way to get the full path to the executable, as far as I'm aware. On OSX, I
> don't know where to even start.
>
> b) being able to override the Windows sampling frequency
>> with the setting from alsoft.ini, i.e. having a "force sampling
>> frequency" option
>>
>
> 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.
>
> This would also enable anyone to use per-game settings instead of
>> relying on one single global configuration which might have to be
>> changed for each game.
>>
>> Is this possible? Or do you have doubts about it/not enough time?
>>
>
> Generally speaking, config settings are supposed to be for user- or
> system-specific options, rather than app-specific. Anything various apps
> would be interested in should instead be accessible through an OpenAL API
> extension.
>
> But in the case where different apps do actually need different config
> settings, the ALSOFT_CONF environment variable can be used to specify
> another config file with extra settings (which also allows it to be shared
> too, if you have multiple apps that need the same tweaks).
> _______________________________________________
> openal mailing list
> openal at openal.org
> http://openal.org/mailman/listinfo/openal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20160604/a3c2c7a9/attachment-0001.html>