New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wasapi driver outputs device names encoded in Windows ANSI default codepage #1322
Comments
I didn't had a deeper look into this. For the context, it originally was UTF8, but changed in the context of #984. |
It is an unfortunate regression. The command line arguments conversion to UTF-8 are correct, but on the other hand the console output should have been also declared as Unicode, instead of taking back the device names to the ANSI code page. @derselbst : We need a Fluidsynth declaration of Unicode allegiance. See also: https://learn.microsoft.com/en-us/windows/console/console-code-pages
|
Other windows driver needs to be converted to UTF8 as well:
And these drivers have already a _UNICODE macro to do the job, but there is no support in CMake for this symbol?
|
Sure, I'm all in favor of documenting that the device names of settings like |
Defining the symbol _UNICODE, fluidsynth doesn't compile anymore. This will be more work than I thought. |
FluidSynth version
Describe the bug
This comes from a Qsynth ticket: Device initialization fails when audio driver is set to WASAPI and output destination is other than default. rncbc/qsynth#82
The reporter includes a screenshot where the selection of audio devices appears corrupted, due to inconsistent character decoding.
When the users tries to select any audio device other than "default", the initialization of the audio driver fails with an error message:
Qsynth1: Failed to create the audio driver (wasapi). Cannot continue without it.
Expected behavior
The list of available audio devices is correctly presented to the user, and any device can be selected and initialized, if all other parameters are supported.
Steps to reproduce
The original reporter has a Japanese Windows 11 version, using codepage 932. I've been able to reproduce the issue renaming in my system (which uses codepage 1252) the audio devices to include some tricky characters.
Additional context
All other Fluidsynth MIDI and audio drivers report the audio devices as settings options encoded as UTF-8 except the Wasapi driver, that uses the default windows codepage.
WideCharToMultiByte() is a Win32 API function to convert Unicode strings (Wide Chars) used internally by Windows into multibyte encodings (or single byte, for what is worth). When using the first argument
CP_ACP
, its output is using the system default Windows ANSI code page. This is whatfluid_wasapi.c
is doing. All other windows drivers useCP_UTF8
as the first argument.The documentation for settings does not specify anything about the encoding for string options. This should be fixed as well.
And finally, the CLI
fluidsynth.exe
needs to be fixed as well to output readable text when processing the arguments-a wasapi -Q
, because it will output garbage to the terminal if the wasapi driver is fixed to useCP_UTF8
.The text was updated successfully, but these errors were encountered: