- Home /
Short sounds sometimes being missed
Hello everybody,
I recently noticed that the short WAV sounds I have attached to my game collectibles, are sometimes missed.
So I started investigating, and stripped all the unnecessary code, to see where the problem is. The result is the below test script.
It appears that short WAV files are sometimes not played. I have used the following script to test it (of course, an audio listener is attached to the camera):
public AudioClip sound;
float timeSinceLast = 0;
void Update () {
if( Time.time - timeSinceLast > 0.6f ) {
Debug.Log("Playing");
timeSinceLast = Time.time;
AudioSource.PlayClipAtPoint( sound, Camera.main.transform.position );
}
}
As you can see, it just plays the WAV file every 0.6 seconds. Every now and then, the file is not being played.
I am curious if anyone had any similar issue, and what could be the root of this evil.
I am also attaching the WAV file, in case someone wishes to see if they can replicate the problem.
Using Unity 3.5.6f4 on Windows XP
EDIT:
And here is a complete test project that I made, to make sure it is reproducible.
EDIT 2:
It is also happening with other short waves. I tried from different sources.
It happens both in the editor and web player.
If I artificially make the WAV file longer by adding silence at the end, it seems to be working fine. So did I catch a bug?
FWIW I'm having the same issue in Unity 4.6 with short AIFF clips. GarageBand had originally exported each sound with a bunch of extra silence on the end, which wasn't the end of the world (they played fine) but wasted memory (on iOS). So I trimmed off the silence, leaving very short AIF files. Now they sometimes won't play, or will play a tiny fraction but not the full sound. I'm going back to the needlessly-long versions: silent padding seems to prevent the problem, if anyone needs a workaround. (But that's wasteful.) This does seem like a bug to me. Will re-test some time un Unity 5.
Answer by Xarbrough · Jul 13, 2015 at 06:41 AM
Ok, here is my solution: Create an AudioSource manually and hook up the AudioClip via the inspector or through code. Then play the source like this:
using UnityEngine;
using System.Collections;
public class SoundTester : MonoBehaviour
{
public AudioClip sound;
public AudioSource source;
float timeSinceLast = 0;
void Start()
{
source.clip = sound;
}
void Update ()
{
if( Time.time - timeSinceLast > 0.6f )
{
Debug.Log("Playing");
timeSinceLast = Time.time;
// AudioSource.PlayClipAtPoint( sound, Camera.main.transform.position );
source.Play();
}
}
}
The "bug" is not really a bug. The static method PlayClipAtPoint creates an AudioSource automatically when it needs to play and disposes of it, once the clip is done. When playing a longer sound once, this is not a problem, but when you do it at a short interval, this will create and destroy this hidden AudioSource every time, causing hiccups in framerate. You can actually see the gameobject being created and destroyed in the hierarchy sometimes. Although most of the time the refresh is too slow to actually show it. However, this instantiating is very expensive and you really shouldn't be doing it this often. The actually drop out happens as soon as enough memory garbage has collected from destroying the implicit AudioSource and the Garbage Collector runs to get rid of those unused references.
Solution: Manually creating an AudioSource, assigning a clip and then playing it will not create any garbage and therefore runs smoothly.
However, it still may be a bug that the implicitly created AudioSource is creating so much garbage. One might expect it to be optimized better. So if you are going to submit it as a bug, better call it an optimization request, but probably not much chance of getting a fix on this. Just use the manual way. ;)
Will try that way--thanks!
In my case, though, it's a short click sound at the start and end of a drag-and-drop. So it's triggered with at least 1/4 second, usually several seconds, in between sounds. If that simple case fails so often (maybe half the time), that really does seem like a bug beyond optimization. And it's odd that simply adding silent padding to the end of the file makes it audible. (A clip of about half a second plays $$anonymous$$OST of the time. 1.5 second seem totally reliable. 1/5 second? Not so good. But it's all the same sound, with different amounts of empty padding on the end.)
Also of note: I have an iOS game that plays TONS of sounds constantly by PlayClipAtPoint (you can see the little speakers co$$anonymous$$g and going like popcorn in the Scene view). Never a problem—but they're all longer sounds.
I'll try your method and/or keep sounds longer than 1/2 second. But I do hope Unity 5 simply fixes the issue as well, once I make that leap.