-
Notifications
You must be signed in to change notification settings - Fork 18
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
Comments
If you want to help to better diagnose this issue, please:
|
The results are collected. |
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. |
seems to me that a QString::fromUtf8() is needed in: qsynth/src/qsynthSetupForm.cpp Lines 166 to 167 in 936bedb
like this? (pData->pListItem)->setText(iCol++, QString::fromUtf8(pszCurrent));
(pData->pListItem)->setText(iCol++, QString::fromUtf8(pszDefault)); |
Why And this is the documentation for the function ' WideCharToMultiByte' : https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte
where
|
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. |
I now see that, perhaps my change will only work properly if at least qsynth is now prepared; lest to say the ball is at fluidsynth's side, I guess :) |
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 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:
|
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
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 But in this case, I guess that it can be a bug in Fluidsynth's Wasapi driver, because all other drivers use CP_UTF8. |
Thank you for your response.
Sorry, I cannot build it myself. |
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.
The text was updated successfully, but these errors were encountered: