Skip to content
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

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

Open
nanitaro opened this issue Apr 26, 2024 · 12 comments

Comments

@nanitaro
Copy link

nanitaro commented Apr 26, 2024

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.
setup-audio-device 0 9 90

@pedrolcl
Copy link
Contributor

pedrolcl commented Apr 26, 2024

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
Copy link
Author

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

@pedrolcl
Copy link
Contributor

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
Copy link
Owner

rncbc commented Apr 27, 2024

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

(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
Copy link
Contributor

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

(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
Copy link
Owner

rncbc commented Apr 27, 2024

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

@pedrolcl
Copy link
Contributor

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
Copy link
Owner

rncbc commented Apr 27, 2024

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
Copy link
Contributor

pedrolcl commented Apr 27, 2024

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:

audio_devices_renamed

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 :

imagen

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
Copy link
Owner

rncbc commented Apr 27, 2024

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

@pedrolcl
Copy link
Contributor

pedrolcl commented Apr 27, 2024

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
Copy link
Author

nanitaro commented Apr 27, 2024

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.

rncbc added a commit that referenced this issue Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants