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

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?