Which HRTF specifier does alcResetDeviceSOFT select when multiple datasets are present?

Question

Applications using the ALC_SOFT_HRTF extension can request binaural rendering, but the specification leaves the selection algorithm undefined when a device exposes several built-in HRTF presets or custom .mhr files. OpenAL Soft, for example, ships with multiple sample-rate-specific datasets, yet there is no standard query to list available identifiers or to discover which one the implementation will activate after a call to alcResetDeviceSOFT with ALC_HRTF_SOFT set to ALC_TRUE.

This ambiguity prevents reliable persistence of user preferences across sessions and makes cross-platform quality assurance difficult, because the active HRTF may differ between OpenAL Soft, proprietary drivers, and platform audio backends. The extension also falls back to stereo panning without error when HRTF is unavailable, so an application cannot distinguish between successful HRTF activation and silent degradation.

Given these constraints, the following questions remain unresolved:

Can an implementation legally choose any available HRTF dataset when the application does not supply an explicit specifier?
Is there a portable mechanism to enumerate or query the active HRTF identifier after device reset?
Does the specification intend for alcResetDeviceSOFT to preserve the previously active HRTF when the attribute list omits a specifier?

Tasadduq Burney · Answer

AnswerWhen alcResetDeviceSOFT is called with ALC_HRTF_SOFT set to ALC_TRUE and no ALC_HRTF_SPECIFIER_SOFT attribute is supplied, the function uses the implementation‑defined default HRTF. In OpenAL Soft this default is:The first HRTF specifier in the internal list (index 0) unless a dataset whose sample rate exactly matches the device’s output format is present.If such a sample‑rate‑matched dataset exists, that entry is chosen as the default instead of the first.Other OpenAL implementations that expose the ALC_SOFT_HRTF extension may follow the same rule, but the specification does not mandate a particular selection algorithm, so the exact specifier can vary between vendors.Confirmed factsThe OpenAL Soft source code selects the default by scanning the built‑in HRTF list and preferring a sample‑rate match; if none is found it falls back to the first entry.The OpenAL specification states that omitting the specifier results in “using the default HRTF for the device”, leaving the choice to the implementation.After a reset, querying alcGetStringiSOFT(device, ALC_HRTF_SPECIFIER_SOFT, 0) returns the specifier that was actually activated.Steps to verify the selected specifierEnumerate available HRTF specifiers with alcGetStringiSOFT(device, ALC_HRTF_SPECIFIER_SOFT, i) for i = 0 … count‑1.Call alcResetDeviceSOFT with an attribute list containing only ALC_HRTF_SOFT, ALC_TRUE (no specifier).Immediately after the reset, query the active specifier again with alcGetStringiSOFT(device, ALC_HRTF_SPECIFIER_SOFT, 0); the returned string should match the implementation’s default (first entry or sample‑rate‑matched entry).Repeat the test with a device whose output sample rate matches one of the datasets to confirm that the matching dataset is selected as the default.Missing diagnostic detailTo predict which specifier will be chosen without trial‑and‑error, you need to know the device’s output sample rate (or format). If that information is unavailable, the only reliable way is to query the active specifier after the reset as shown above.

Which HRTF specifier does alcResetDeviceSOFT select when multiple datasets are present?

1 answer

Answer

Confirmed facts

Steps to verify the selected specifier

Missing diagnostic detail

Your perspective belongs here.

0 question comments