rncbc / qsynth

Qsynth - A fluidsynth Qt GUI Interface
https://qsynth.sourceforge.io
GNU General Public License v2.0
66 stars 17 forks source link

Problems integrating fluidsynth-2.2.0 with the new wasapi audio driver in windows #38

Closed pedrolcl closed 3 years ago

pedrolcl commented 3 years ago

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:

Possible solutions:

pedrolcl commented 3 years ago

see also:

https://github.com/FluidSynth/fluidsynth/discussions/833

pedrolcl commented 3 years ago

1 fixed in commit 6ec0036 2 fixed in FluidSynth/fluidsynth/pull/839 (we need to wait for a new Fluisynth release)