pcaudiolib: fix CoInitialize to allow RPC_E_CHANGED_MODE

[mcarans]

XAudio2 requires Multi Threaded Apartment to work reliably. If it was pre-initialized as Single Threaded Apartment, an error code is returned RPC_E_CHANGED_MODE (0x80010106), but this can be safely ignored.

[mcarans]

Need to add check for uninitialising.

[mcarans]

Looks like packages are not being built for testing. I guess I need to make this "ready for review" to get test packages? I'll try.

[mcarans]

Ok just need to test artifact next time I'm on Windows

[mcarans]

I have tested the package and it is fine. I think this is ready to release @lazka.

[mcarans]

This is a small change that fixes a bug. Please let me know what needs to happen for it to be merged.
@striezel @MehdiChinoune

[striezel]

Please let me know what needs to happen for it to be merged.

First, pkgrel=1 needs to be bumped to pkgrel=2, because otherwise the package won't be recognized as new.

Second, I am not sure whether it is really OK to "ignore" a return code of CoInitializeEx() that indicates an error. That seems counter-intuitive and not like the right thing to do. Such things usually come back to bite you in unexpected ways. I cannot merge those changes in good conscience. Maybe someone who is more familiar with WinAPI than me can clear this up.

And finally, if that is a bug in pcaudiolib, then it should probably be reported upstream: https://github.com/espeak-ng/pcaudiolib Maybe the folks over there can clarify how to fix this.

[mcarans]

Please let me know what needs to happen for it to be merged.

First, pkgrel=1 needs to be bumped to pkgrel=2, because otherwise the package won't be recognized as new.

Second, I am not sure whether it is really OK to "ignore" a return code of CoInitializeEx() that indicates an error. That seems counter-intuitive and not like the right thing to do. Such things usually come back to bite you in unexpected ways. I cannot merge those changes in good conscience. Maybe someone who is more familiar with WinAPI than me can clear this up.

And finally, if that is a bug in pcaudiolib, then it should probably be reported upstream: https://github.com/espeak-ng/pcaudiolib Maybe the folks over there can clarify how to fix this.

Unfortunately on point 3, the espeak-ng/pcaudiolib devs have not responded to my original PR from when I first created the MSYS2 package: espeak-ng/pcaudiolib#34. They are essentially uninterested and unresponsive: espeak-ng/espeak-ng#2288 (comment)

Currently this change is required for espeak-ng to work properly with SDL3 audio to which the Oolite UCRT64 based game was recently upgraded. However after researching further, I think you may be right about the overall safety of such a change in the general case so I will close this PR.