Forum Discussion
Audio Device events not working
Hi,
I’m trying to use
the OVRManager.AudioOutChanged event to be notified when the audio
output device is changed in the devices settings (as described in
this post),
but the event never fires when switching between the different
options, or when changing the Windows default audio device while the
Use Windows Settings option is selected.
After some debugging, it looks like the
OVRPlugin.audioOutId value is never updated when the device is
changed.
I’m developing for
the Rift on Windows 10.0.17134 using Unity v2017.3.1f1, Oculus
Utilities v1.25.2, OVRPlugin v1.25.0, SDK v1.26.0.
I’ve
looked through the list of known issues, but didn’t see this issue
listed anywhere.
Any help in resolving this would be greatly
appreciated, as this feature is essential for providing a decent user
experience in my application.
5 Replies
Replies have been turned off for this discussion
- I also am having the exact same issue! It's due to `OVRP_1_1_0.ovrp_GetAudioOutId()` always returning the same value.
- After debugging, I found this behavior:
Once Unity starts, OVRPlugin.audioOutId never changes.
If you close Unity and reopen it, it will then change to whatever the setting is in the Oculus client. It then will retain that value until Unity is closed and reopened.
I still can't say what the behavior is outside of Unity though... - Thanks for the report! There is indeed a regression affecting the AudioIn/OutChanged events -- the plugin latches the audio devices at startup and is not correctly detecting audio device changes. This will be fixed for the 1.27 release.
Good to hear it will be fixed in the next update. Any idea when this update will be available?
kersk said:
Thanks for the report! There is indeed a regression affecting the AudioIn/OutChanged events -- the plugin latches the audio devices at startup and is not correctly detecting audio device changes. This will be fixed for the 1.27 release.- This fix unfortunately didn't make it into the 1.26 release, which is already locked down and will likely be out this week, so this fix will first be present in 1.27 with a current ETA of a mid/late June time frame.
