On Windows, each DirectSoundCreate call returns an IDirectSound object with its own independent primary buffer. Wine reuses a single DirectSoundDevice for all IDirectSound objects targeting the same audio endpoint, causing them to share a primary buffer. This breaks games that create multiple IDirectSound objects with different primary buffer flags. For example, Star Wars Episode I Racer creates a primary buffer with DSBCAPS_CTRL3D for in-game audio, then its Smush video engine creates a separate IDirectSound and requests a primary buffer with DSBCAPS_CTRLVOLUME. On Wine, it gets back the existing buffer without CTRLVOLUME, GetVolume fails with DSERR_CONTROLUNAVAIL, and the cutscene audio path silently gives up. The device reuse was introduced in 2005 (commit a2f1fd3aca4) when dsound talked directly to waveOut, where opening the same hardware device twice would have caused conflicts. In 2011 (commit e786998daff) dsound was reimplemented on WASAPI, but the reuse was carried forward. Since Wine's dsound already uses WASAPI shared mode, which is designed for multiple audio clients on the same endpoint, the reuse is no longer necessary. Tested with Star Wars Episode I Racer, cutscene audio plays correctly with the fix applied. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41047 -- v6: dsound: Create independent devices for each DirectSoundCreate call. dsound/tests: Test primary buffer independence across IDirectSound objects. https://gitlab.winehq.org/wine/wine/-/merge_requests/10735