Device initialization fails when audio driver is set to WASAPI and output destination is other than default.

[nanitaro]

By default, music can be generated without problems.
It fails no matter what sample rate or sample format is changed.
It fails even if set to 48000Hz,16bit.

The error message is as follows
Qsynth1: Failed to create the audio driver (wasapi). Cannot continue without it.
Other Drivers can be initialized without problems.

I thought the problem was that it is a Japanese environment,
All other Drivers can be initialized without any problem.

[pedrolcl]

If you want to help to better diagnose this issue, please:

• Open a terminal window (cmd.exe)
• at the system prompt ("C:>"), type: CHCP, and post the answer from the system.
• change to the QSynth directory. Probably...
  C:> cd "C:\Program Files\Qsynth"
• now, type the command:
  C:> fluidsynth.exe -a wasapi -Q
  and please post the results.

[nanitaro]

The results are collected.
It contains Japanese information and is encoded in UTF-8.
Qsynth.log

[pedrolcl]

Your system uses Code Page 932 which is customary for Japanese language. Fluidsynth retrieves the names of the audio devices from Windows, and stores these names in options/settings, encoded in cp932, so Windows native programs will work without any flaws.

The problem is that Qsynth is a Qt application, and the strings need to be encoded in Unicode for displaying. Qsynth is not taking this into account, so the audio device names in your screenshot appear garbled. Not only that, but it is storing these names into QStrings without proper conversion either, so the selection of audio devices do not work.

@rncbc : what do you think? this seems to me a serious bug.

[rncbc]

seems to me that a QString::fromUtf8() is needed in:

qsynth/src/qsynthSetupForm.cpp

Lines 166 to 167 in 936bedb

	(pData->pListItem)->setText(iCol++, pszCurrent);
	(pData->pListItem)->setText(iCol++, pszDefault);

like this?

 (pData->pListItem)->setText(iCol++, QString::fromUtf8(pszCurrent)); 
 (pData->pListItem)->setText(iCol++, QString::fromUtf8(pszDefault)); 

[pedrolcl]

seems to me that a QString::fromUtf8() is needed in:

qsynth/src/qsynthSetupForm.cpp

Lines 166 to 167 in 936bedb

	(pData->pListItem)->setText(iCol++, pszCurrent);
	(pData->pListItem)->setText(iCol++, pszDefault);

like this?

 (pData->pListItem)->setText(iCol++, QString::fromUtf8(pszCurrent)); 
 (pData->pListItem)->setText(iCol++, QString::fromUtf8(pszDefault)); 

Why fromUtf8() ? the problem is that Fluidsynth does not provide the option strings with any fixed or predictable encoding. See:

https://github.com/FluidSynth/fluidsynth/blob/cb8da1e1e2c0a5cff2bab6a419755b598b793384/src/drivers/fluid_wasapi.c#L789-L795

And this is the documentation for the function ' WideCharToMultiByte' :

https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte

Maps a UTF-16 (wide character) string to a new character string. The new character string is not necessarily from a multibyte character set.

where CP_ACP means:

The system default Windows ANSI code page.

Note This value can be different on different computers, even on the same network. It can be changed on the same computer, leading to stored data becoming irrecoverably corrupted. This value is only intended for temporary use and permanent storage should use UTF-16 or UTF-8 if possible.

[rncbc]

so it maybe a fluid_settings/windows blunder? does 1ec61bf behave any better?

[pedrolcl]

so it maybe a fluid_settings/windows blunder? does 1ec61bf behave any better?

I guess that your question is for @nanitaro but first you should ask him if he is able to build and test qsynth's git repository by himself.

I can test it in a Windows machine with a Spanish or English locale, but that is not the same problem.

[rncbc]

I now see that, perhaps my change will only work properly if WideCharToMultiByte would be called with CP_UTF8, instead of CP_ACP (on fluid_wasapi.c) :S

at least qsynth is now prepared; lest to say the ball is at fluidsynth's side, I guess :)

[pedrolcl]

I take that back. I can do some tests on my Windows box.

First, I've renamed my windows audio devices, to something very tricky:

This is the output of CHCP and fluidsynth.exe -a wasapi -Q (encoded in utf-8) My terminal is using cp1252:

wasapi_fluidsynth.txt

This is the result of your change 1ec61bf :

The garbage is similar in v0.9.90 but the important effect is that selecting any device name other than "default", the driver initialization fails with:

18:18:40.047 Qsynth1: Creating audio driver (wasapi)...
18:18:40.059 Qsynth1: Failed to create the audio driver (wasapi). Cannot continue without it.

[rncbc]

yeah right, but what if you change it to CP_UTF8 in fluidsynth's fluid_wasapi.c ?

[pedrolcl]

yeah right, but what if you change it to CP_UTF8 in fluidsynth's fluid_wasapi.c ?

That any and all other windows programs linking to libfluidsynth.dll, not expecting Unicode in Fluidsynth options, will break. Even the fluidsynth.exe CLI program will output garbage when using the arguments "-a wasapi -Q":

Available audio devices:
 default
 Áürïçularès (High Definition Audio Device)
 ├æ├í├®├¡├│├║├ç (HDMI) (2- High Definition Audio Device)

It is important for a library to keep backward compatibility, so in my opinion changing Fluidsynth can only be done very carefully, after analyzing all other options. For instance, having a new optional build switch to create some libfluidsynth-unicode.dll that would be friendly to downstream Qt projects.

But in this case, I guess that it can be a bug in Fluidsynth's Wasapi driver, because all other drivers use CP_UTF8.

[nanitaro]

Thank you for your response.

I guess that your question is for @nanitaro but first you should ask him if he is able to build and test qsynth's git repository by himself.

Sorry, I cannot build it myself.
I have MSYS2 installed but am not familiar with it.
However, since you seem to be able to reproduce the bug, please continue to investigate.