RFR: 8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library [v10]

[Alexey Ivanov]

On Wed, 4 Oct 2023 05:37:10 GMT, Renjith Kannath Pariyangad <duke at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Observations :
>> 1. Without com initialize if we access Mixer for recording, library loaded invalid GUID and clipped description in windows(ID not found in registry). With com initialization library load proper GUID (same as registry).
>> 2. For Play back device always loading proper device GUID irrespective of com Initialization.
>> 
>> Test:
>> Since screen lock and unlock workflow required for reproducing this issue, did coupe of iteration of manual testing post fix and confirmed its resolving the problem.
>> To reconfirm nothing is broken, executed all audio related test cases on test bench post fix and all are green.
>> 
>> Please review the changes and let me know your comments if any.
>> 
>> Regards,
>> Renjith.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   File permission updated

To clarify the situation and to eliminate any misunderstanding, there are three possible cases:

1. COM is not initialised. `CoInitializeEx(COINIT_MULTITHREADED)` returns `S_OK`. This is the ideal situation.
2. The app has already initialised COM on the thread with `CoInitializeEx(COINIT_MULTITHREADED)`. Thus, the second call to `CoInitializeEx` will return `S_FALSE`. This case is also fine.
3. The app has already initialised COM on the thread with `CoInitializeEx(COINIT_APARTMENTTHREADED)`. Thus, the second call inside Java to `CoInitializeEx(COINIT_MULTITHREADED)` will return `RPC_E_CHANGED_MODE` because the concurrency model is changed. Yet this case is fine as well.

In all the three cases, it is safe to proceed to call `DirectSoundEnumerate*` because the prerequisite—COM is initialised—is satisfied and because DirectSound APIs support both MTA and STA.

In the first two cases, we *must call* `CoUninitialize` when finished; in the third case, we *must **not** call* `CoUninitialize`.

If `CoInitializeEx` returns any other error, we must bail out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14898#issuecomment-1748967705