The Mixed Reality Forums here are no longer being used or maintained.
There are a few other places we would like to direct you to for support, both from Microsoft and from the community.
The first way we want to connect with you is our mixed reality developer program, which you can sign up for at https://aka.ms/IWantMR.
For technical questions, please use Stack Overflow, and tag your questions using either hololens or windows-mixed-reality.
If you want to join in discussions, please do so in the HoloDevelopers Slack, which you can join by going to https://aka.ms/holodevelopers, or in our Microsoft Tech Communities forums at https://techcommunity.microsoft.com/t5/mixed-reality/ct-p/MicrosoftMixedReality.
And always feel free to hit us up on Twitter @MxdRealityDev.
AudioSource.PlayClipAtPoint
I tried using this method after configuring my project for spatial sound and it seems to work well. It also seems like a good method to use for generic sound effects such as selections and alert bells. Before I go peppering my code with calls to this method are there any notes that I should be aware of? Is the static method already configured for optimal spatialization? If not can I configure it to be?
Best Answer
-
DavidKlineMS
mod
Spatialization is controlled by your Audio (specifying MS HRTF Spatializer) and AudioSource (Spatialize == true, etc) settings, so using PlayClipAtPoint should not influence how optimal your spatialization is.
From your description, it sounds (no pun intended
) like you are playing sounds with no visible emitter. If that is the case, this API sounds like a good one to use for your scenario.For most other scenarios, I would recommend not using PlayClipAtPoint and instead attaching the AudioSource to a visible GameObject and using its location to determine the point at which the clip plays.
Hope this helps,
David7
Answers
Spatialization is controlled by your Audio (specifying MS HRTF Spatializer) and AudioSource (Spatialize == true, etc) settings, so using PlayClipAtPoint should not influence how optimal your spatialization is.
From your description, it sounds (no pun intended
) like you are playing sounds with no visible emitter. If that is the case, this API sounds like a good one to use for your scenario.
For most other scenarios, I would recommend not using PlayClipAtPoint and instead attaching the AudioSource to a visible GameObject and using its location to determine the point at which the clip plays.
Hope this helps,
David
It does -- thanks David!
FYI - the context I'm using the method in does include visible source emitters. For example, I created a generic behavior for moving objects with a snapping effect. For each `snap' I am playing an audio clip using AudioSource.PlayClipAtPoint. I architected it this way so that I could use a single instance of a editing controller to coordinate editing a multitude of objects. It seemed impractical to attach an AudioSource to each object or to manage a pool of AudioSources. I agree that the quality is just fine for this purpose - we will stick with instanced audio sources for higher quality effects.