You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The new fluidsynth-2.2.0 was released last week including a new wasapi audio driver for Windows, which is a very welcome addition because it allows lower latency than the other alternatives. Both the new wasapi audio driver and dsound support now the new_fluid_audio_driver2() which enables the output peak level meters. Awesome!
With my hat of QSynth for Windows package provider, I'm testing a build of the current qsynth master branch, and observed:
The new wasapi driver calls CoInitializeEx(NULL, COINIT_MULTITHREADED) twice (MTA mode). One in new_fluid_wasapi_audio_driver2() and another in fluid_wasapi_foreach_device(). The problem is that the threads affected by this call do not {belong to, have not been created by} the fluidsynth library, and could already be initialized by the client application. Indeed, Qt initializes the UI thread in STA mode. And QSynth does call every Fluidsynth API function from the UI thread.
When the wasapi driver enumerates his audio devices, it tries to initialize the running thread as MTA and aborts the enumeration if he can't. The first time fails, and the list of audio devices becomes empty. Anyway, before exiting the function it calls CoUninitialize(). That also allows the next call to CoInitialize() to succeed, so the audio driver can be created, and it works! The price is payed by the UI thread reinitialized as MTA, and the consequences for Qt apps that I could observe are:
QSynth does not accept dropped files from the explorer anymore, so MIDI files can't be played this way.
Open/Save file dialogs do not work. Neither the open soundfont button, nor the import/export/save color themes can be used, and the UI freezes.
Possible solutions:
Move the affected API function calls to a background thread (I've already done this in my Drumstick fluidsynth backend).
Avoid the new driver or even the new version, until this issue is fixed in fluidsynth.
The text was updated successfully, but these errors were encountered:
The new fluidsynth-2.2.0 was released last week including a new wasapi audio driver for Windows, which is a very welcome addition because it allows lower latency than the other alternatives. Both the new wasapi audio driver and dsound support now the
new_fluid_audio_driver2()
which enables the output peak level meters. Awesome!With my hat of QSynth for Windows package provider, I'm testing a build of the current qsynth master branch, and observed:
audio.wasapi.exclusive-mode
0 = shared mode, 1 = exclusive mode
audio.wasapi.device
already working, more or less. See below...The new wasapi driver calls
CoInitializeEx(NULL, COINIT_MULTITHREADED)
twice (MTA mode). One innew_fluid_wasapi_audio_driver2()
and another influid_wasapi_foreach_device()
. The problem is that the threads affected by this call do not {belong to, have not been created by} the fluidsynth library, and could already be initialized by the client application. Indeed, Qt initializes the UI thread in STA mode. And QSynth does call every Fluidsynth API function from the UI thread.When the wasapi driver enumerates his audio devices, it tries to initialize the running thread as MTA and aborts the enumeration if he can't. The first time fails, and the list of audio devices becomes empty. Anyway, before exiting the function it calls
CoUninitialize()
. That also allows the next call toCoInitialize()
to succeed, so the audio driver can be created, and it works! The price is payed by the UI thread reinitialized as MTA, and the consequences for Qt apps that I could observe are:Possible solutions:
The text was updated successfully, but these errors were encountered: