can fluidsynth initialize the COM library in the context of the synthesis thread instead of the caller's ?

[pedrolcl]

The wasapi driver included in fluidsynth 2.2.0 requests MTA COM thread initialization in the running thread with CoInitializeEx(NULL, COINIT_MULTITHREADED), which may fail if the thread has been initialized already in STA model:

fluidsynth: error: wasapi: cannot initialize COM. 0x80010106

The error code 0x80010106 means RPC_E_CHANGED_MODE which is defined in WinError.h:

#define RPC_E_CHANGED_MODE               _HRESULT_TYPEDEF_(0x80010106L)

See also this QSynth issue.

It is understandable that the drivers require some special threading conditions. It already happens with the realtime priority of the Unix drivers, but ...

Please, can fluidsynth initialize the COM library in the context of the synthesis thread instead of the caller's?

[derselbst]

Moving the CoInitializeEx to the synth worker thread would allow getting rid of init in new_fluid_audio_driver2. But there is a second init that we call whenever a settings object is created. I see no other chance than to perform all those COM calls in a worker. Which would be a bit ugly as well.

Is there a way to test whether COM has been initialized already? @chirs241097 Do you have any other idea on this?

[pedrolcl]

But in fluid_wasapi_foreach_device we do not share any COM interfaces with other threads. So in this case we could simply ignore a RPC_E_CHANGED_MODE and silently continue? (+avoiding the CoUninitialize call at the end)

And ignore the failure in the device enumeration? When the init fails, you get an empty list of available devices in the settings object, so only the "default" device would be offered to the user. If this is acceptable, then we can avoid calling fluid_wasapi_foreach_device entirely in fluid_wasapi_audio_driver_settings.

[derselbst]

No, from my understanding RPC_E_CHANGED_MODE indicates that COM is already inited and stays inited with the previous thread model. So it should be safe to continue with the device enumeration as COM stays inited. Currently, as I understand, the FAILED(ret) is responsible for cancelling the device enumeration. So I suggest to change it to

int com_was_inited = FALSE;
ret = CoInitializeEx(NULL, COINIT_MULTITHREADED);
if(ret == S_FALSE)
{
  goto cleanup;
}
else if(ret == RPC_E_CHANGED_MODE)
{
  com_was_inited = TRUE;
}

// ...dev enumeration...

if(!com_was_inited)
{
  CoUninitialize();
}

[pedrolcl]

The documentation says:

For each call to CoInitializeEx, a thread must also call CoUninitialize. In other words, calls to CoInitializeEx and CoUninitialize must be balanced.

In another remark it says:

A thread must call CoUninitialize once for each successful call it has made to the CoInitialize or CoInitializeEx function, including any call that returns S_FALSE.

So, my understanding is that only if SUCCEEDED(ret) we should call CoUninitialize.

Anyway, IMHO the problem is that a library should not mess with the threads that has not created, like the ones that belong to the client process.

[derselbst]

So, my understanding is that only if SUCCEEDED(ret) we should call CoUninitialize.

Yes, that's also my understanding and goes hand in hand with the CCoInitializer example class listed in your first doc link. My code example does basically the same. This is why I think we do not need another worker thread in fluid_wasapi_foreach_device.

My problem with worker threads is that you'll never know when they are done. You would probably wait for some quit event for a certain time. But who can tell the right value for such a timeout? If the timeout is too short, people like to call TerminateThread() while buying all the problems it may or may not bring. So whenever possible I would like to avoid this. And in this case it seems possible to avoid it at all.

[pedrolcl]

OK. I've tested the strategy discussed here, and it seems to work. You have a PR.

[chirs241097]

Well, I saw the latest commit already resolved the issue. And I skimmed through the changes, they do make a lot of sense.
Messing with the caller thread's COM concurrency model is definitely unacceptable. Thanks a lot for the fix!

(Sorry for the late response. Had to take a couple of weeks off from github for personal reasons.)

[pedrolcl]

Thanks to you too for implementing the driver!