http://bugs.winehq.org/show_bug.cgi?id=59047 Matteo Bruni <matteo.mystral@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Matteo Bruni <matteo.mystral@gmail.com> --- Thanks Infinite Loop for the bug report and thanks Gijs for the CC, I didn't notice it earlier. VRChat uses IMFMediaEngine and, at some point while loading the video, it calls SetVolume(0.0) on it. That's effectively implemented as IMFSimpleAudioVolume::SetMasterVolume() -> ISimpleAudioVolume::SetMasterVolume() on the whole audio session, which for VRChat turns out to be the default GUID_NULL one. That's the case both before and after the regressive commit. The commit breaks the application because now that IMFMediaEngine::SetVolume() call can actually affect the volume of all the audio clients in the default session. The short version is: media_engine_apply_volume() gets a IMFSimpleAudioVolume from SAR, which in turn eventually gets it from IAudioClient::GetService(). Before the commit in question, that IAudioClient would be created on a different session from any other client. I suspect that this is effectively a mfmediaengine bug exposed by the commit. I'm still investigating, but my current hypothesis is that IMFMediaEngine_SetVolume() should not map to IMFSimpleAudioVolume_SetMasterVolume(). It looks like mfmediaengine is used by the "normal" player, while AVPro directly uses the various media foundation pieces. So VRChat sets the media engine volume to 0 to "disable" it but doesn't expect that to set the volume to 0 to the whole audio session. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.