Failed to check format support error on startup

[hsdk123]

Hi, I have a project I've been using alsoft for a while, and all a sudden I'm getting this error on startup and crashing

[ALSOFT] (EE) Failed to check format support: 0x8000057

What might be the problem?

[kcat]

Looks like a generic winapi error, which correlates to ERROR_INVALID_PARAMETER. It's not WASAPI itself that's complaining, but something deeper down that WASAPI is just passing along. It seems to be IAudioClient::IsFormatSupported that's returning it, though it should then fall back to IAudioClient::GetMixFormat. Since you don't mention a followup error, I assume either that's what crashes, or it succeeds and the crash happens somewhere else.

Are you able to provide a full trace log? With MSVC, I believe it should print out the log with non-Release builds to the debug output panel/window. Or you can set the ALSOFT_LOGLEVEL environment variable to 3 when you run the app, and either redirect stderr to a file or set the ALSOFT_LOGFILE environment variable to a full path+filename to where you want it to write the log to (it will erase/overwrite existing files if you point it to an existing one).

[hsdk123]

Is it possible to set ALSOFT_LOGLEVEL through a function instead of an env variable?

[kcat]

Is it possible to set ALSOFT_LOGLEVEL through a function instead of an env variable?

Not currently. I've been thinking about making a config option, though it's a bit tricky since logging initializes at the start of library initialization prior to config loading, and logs the config loading process (so getting the logging parameters from the the config would be after logging has already started, and for a trace log it's useful to see what config options are getting loaded from where).

[hsdk123]

This is sadly a client PC and it doesn't seem they have the option to change environment variables. I handed them a debug version of the application and this seems to be the only logs that display:

core version: 13.8.0-t9d
extern compiled: 2.23.1
extern linked: 2.23.1
INFO: egl::Debug::insertMessage(462): EGL ERROR: eglBindAPI: Bad parameter.
Renderer: ANGLE (NVIDIA GeForce RTX 3060 Ti Direct3D11 vs_5_0 ps_5_0) by Google Inc.
OpenGL version: OpenGL ES 3.0.0 (ANGLE 2.1.0.invalid-hash)
Using optional features:
    GL_ANGLE_multi_draw
    GL_ANGLE_base_vertex_base_instance
    GL_EXT_texture_filter_anisotropic
    GL_EXT_robustness
    GL_EXT_draw_elements_base_vertex
    GL_KHR_debug
    GL_KHR_parallel_shader_compile
Using driver workarounds:
    angle-instanced-attributes-always-draw-instanced
    angle-chatty-shader-compiler
[ALSOFT] (WW) Failed to check format support: 0x80070057
Audio renderer: OpenAL Soft by OpenAL Community
OpenAL version: 1.1 ALSOFT 1.23.0
[==========] Running 183 tests from 59 test suites.

[hsdk123]

bit tricky since logging initializes at the start of library initialization prior to config loading, and logs the config loading process (so getting the logging parameters from the the config would be after logging has already started, and for a trace log it's useful to see what config options are getting loaded from where).

The trickiness sounds in adding the current environment variable in the config. Would it be possible to allow the dev to just set ex. a global variable (that isn't the config) through some function before initialising openal soft?

If variables for the logger are the only complication, just separating them out from the config sounds like the only logical option forward.

[kcat]

I handed them a debug version of the application and this seems to be the only logs that display:

If you're able to make a custom build of OpenAL Soft for them, you can change the default log level so it creates a trace log by default: https://github.com/kcat/openal-soft/blob/1.23.0/alc/alc.cpp#L164 Just change the initial value to LogLevel::Trace.

Would it be possible to allow the dev to just set ex. a global variable (that isn't the config) through some function before initialising openal soft?

Maybe. As long as traces aren't used in performance-sensitive code, which they're not currently, I may be able to add a bit more run-time control to them.

Honestly, there's a part of me that would like to be able to allow the app access to OpenAL Soft's logs (with severity info) so they can write it out with their own log. But that kind of thing would be easy to abuse, the app trying to parse the log itself and get details it's not supposed to know about, in turn causing failures if an OpenAL Soft update changes how or what it logs. Maybe a switch to disable external logging would be enough to work around instances of that occurring.

Though in either case, a more formal logging API akin to what OpenGL has with GL_KHR_debug would be nice, but has the same issue as the config option, only worse: it can only be set up once a device and context is active, which not only misses the early log, but can be impossible to use if there's a problem setting up a device or context. And I don't know how Vulkan deals with logging driver diagnostics. A more global design would be needed that doesn't rely on a context or device, since you can't always assume you can get a device handle. I always found the KHR debug API rather obtuse as well, with a number of things that don't make sense, so trying to model something after that doesn't seem appealing.