Add 32-bit signed PCM (“32bits”) output support (synth API + WASAPI)

[jimhen3ry]

Related discussion

Discussion #1734

Is your feature request related to a problem?

The Windows WASAPI driver in exclusive mode is unable to use the full resolution of a 24 bit DAC if the audio hardware does not accept samples in IEEE floating point format.

Describe the solution you'd like

This issue proposes adding end-to-end support for signed 32-bit linear PCM output in FluidSynth, exposed via audio.sample-format="32bits", with an initial focus on the WASAPI driver.

The goal is to allow the synth rendering API to deliver 32-bit integer PCM directly to drivers that can negotiate and transport this format (notably WASAPI exclusive mode), while preserving existing behavior for all other formats and drivers.

Describe alternatives you've considered

Allow the WASAPI driver to probe for and use hardware transport formats that support 24 bits or better when audio.sample-format is set to "float".

Additional context

The following tasks are proposed:

• Refactor integer output rendering to a shared C++11 templated implementation
  • Port the current fluid_synth_write_s16(_channels) implementation to C++ using the existing DSP carve-out pattern (C ABI wrappers + C++ implementation).
  • Preserve existing 16-bit behavior bit-for-bit, including dithering.
• Add fluid_synth_write_s32(_channels) to the public synth rendering API
  • Signed 32-bit PCM (int32_t)
  • round + clip conversion from internal floating-point samples
  • no dithering
  • API shape parallel to the existing s16 and float variants.
• Add support for audio.sample-format="32bits" in fluid_wasapi.c
  • Select the 32-bit PCM render path when requested.
  • Ensure correct format negotiation in shared and exclusive modes.
• Extend fluid_wasapi_device_enumerate.c to probe and report 32-bit PCM support
  • Probe 32-bit PCM formats where appropriate (notably in exclusive mode).
  • Reflect support in the device / format enumeration results.
• Confirm driver behavior for unrecognized audio.sample-format values
  • WASAPI: handled as part of tasks 3–4.
  • Android drivers: confirmed to fall back to 16-bit PCM; no behavior change proposed.
  • Other drivers: no action required.

[jimhen3ry]

Do you prefer to have the creation of a test broken out as a separate task or included with the task that uses the test? I am creating a test to confirm that the refactor preserves existing 16-bit behavior bit-for-bit, including dithering.

[derselbst]

A test sounds good. But no need for a separate task, it's part of the "Preserve existing 16-bit behavior bit-for-bit, including dithering".

[jimhen3ry]

Do you prefer to have everything related to this issue in one push or have the fluid_synth.c changes in one push and the fluid_wasapi.c changes in a second push?

[derselbst]

I'd say keep them in dedicated commits. We can squash them later if need be. (The "pushes" do not matter ;) )

[jimhen3ry]

Most modern audio APIs (e.g. WASAPI via WAVEFORMATEXTENSIBLE) represent 24-bit PCM as 24 valid bits left-aligned in a 32-bit container, with the lower 8 bits used as padding. Supplying non-zero data in those padding bits is outside the defined format contract and can lead to device- or driver-dependent behavior.

I propose adding explicit support for this 24-in-32 PCM format at the synth level. For configuration, should synth.sample-format = "24bits" be defined to mean 24-bit PCM left-aligned in 32 bits, or should a more explicit value (e.g. "24in32") be used?

[derselbst]

Ok, then make it synth.sample-format = "24bits". And there should probably be a dedicated fluid_synth_write_s24 public API function then, which under the hood calls the regular int32 rendering function, but with an extra flag to signal that the least sig. byte should be zeroed out.

[jimhen3ry]

What is your feeling about refactoring fluid_waspi.c to be C++ 11 before adding support for the new PCM formats? I don't have a strong feeling one way or the other.

[derselbst]

You don't need to port it to C++. Unless you really have a lot of fun and time to spare ;)

[jimhen3ry]

While working on the WASAPI 24/32-bit sample-format changes, I noticed a couple of possible CMake-related gotchas in CMakeLists.txt. These are likely out-of-scope for this issue, and may not affect the s24/s32 behavior itself — but I wanted to leave breadcrumbs in case others run into build/ABI/link oddities on Windows toolchains.

Possible CMake concerns

1. LIBFLUID_LIBS appears to be initialized before MATH_LIBRARY is set:

set ( LIBFLUID_LIBS ${MATH_LIBRARY} )
...
find_library ( HAS_LIBM NAMES "m" )
if ( HAS_LIBM )
  set ( MATH_LIBRARY "m" )
endif ( HAS_LIBM )

• If MATH_LIBRARY is set later, LIBFLUID_LIBS won’t automatically pick it up unless it’s reassigned afterward. This may be intentional depending on how MATH_LIBRARY is used later.

2. NOTICE message type and CMake 3.13 compatibility

NOTICE is not guaranteed with a minimum CMake of 3.13; this may be noisy or unsupported on older CMake versions, depending on policy/version behavior; STATUS/WARNING may be safer.. This is the affected line:
message ( NOTICE "Seems like libsndfile was compiled without OGG/Vorbis support." )

3. The following line may produce unnecessary configure output:

cmake_print_variables(SndFile_WITH_EXTERNAL_LIBS SndFile_WITH_MPEG)

4. Typo in GLIB2_MINUMUM_VERSION

Two places:
set ( GLIB2_MINUMUM_VERSION 2.6.5 )
find_package ( GLib2 ${GLIB2_MINUMUM_VERSION} REQUIRED )

• likely still works even with the typo

5. Global CMAKE_CXX_STANDARD is mutated in multiple option blocks

• Top-level sets CMAKE_CXX_STANDARD 11, but later blocks change it globally:
• osal STREQUAL "cpp11" sets CMAKE_CXX_STANDARD 17
• enable-native-dls sets CMAKE_CXX_STANDARD 17 + REQUIRED ON
• enable-oboe sets CMAKE_CXX_STANDARD 14 + REQUIRED ON
• Because these are global, they can silently change the C++ standard for all targets/files (including drivers), depending on option combos. If someone reports “works on my build but not yours” behavior, this could be a factor.
• Not proposing changes here; just pointing out that per-target target_compile_features() would avoid global standard drift.

6. WASAPI link libraries may be toolchain-sensitive

• Under enable-wasapi, Windows libs add ole32:

if ( enable-wasapi AND HAVE_WASAPI_HEADERS AND HAVE_OBJBASE_H)
  set ( WINDOWS_LIBS "${WINDOWS_LIBS};ole32" )
  set ( WASAPI_SUPPORT 1 )
endif ()

• For CYGWIN, there’s special handling for uuid; for other toolchains (e.g., MinGW variants) COM/GUID linkage can be more finicky depending on how GUIDs/IIDs/CLSIDs are defined/resolved.
• Something to look at if a “toolchain-specific COM symbol/linkage weirdness” class of issues is encountered.

7. Windows version detection may be brittle

• The windows-version logic uses if(CMAKE_SYSTEM_VERSION EQUAL 10) etc. On some generators, CMAKE_SYSTEM_VERSION can be a dotted string (10.0, 6.1, etc.), so equality tests may not always behave as intended.
• VERSION_GREATER_EQUAL or MATCHES might make the tests more robust.
• Probably fine in practice, but if someone encounters unexpected _WIN32_WINNT targeting (and thus API availability/behavior differences), this is one place to look.

Again: these may have no impact on the 24/32-bit sample-format issue itself — just a few CMake areas that seemed worth double-checking while we’re already in this neighborhood.

[derselbst]

Thanks for these findings! I've created a PR, which addresses most of them:

5. This would matter if fluidsynth's CMake project would be reference by another CMake project, e.g. via add_subdirectory(). Possible, yes, in which case it would mess up standard globally. So far nobody has complained and refactoring that is a bigger task, so I'll keep it for now. However, I've fixed a possible demote from C++17 to C++14 when oboe is active.
6. There's not much I can comment here, neither do I know how to fix this properly. I'd say, since we don't have a CI build for Cygwin, it's out of scope for the moment, until somebody complains.

[jimhen3ry]

I agree with the way you have handled these findings.