WWW.GetAudioClip() Freeze Bug And Possible Solutions Thread

Unity Engine
1

Pre-Existing Threads on this issue

- Streaming Music Hitch iOS
- Help With WWW GetAudioClip Freeze Please
- Multithreaded Web Requests In iOS
- External Audio Freeze
- Loading Screen Freeze
- Unity Freeze With OGV Streaming
- Problems Playing Audio For Streaming Video

So I’ve seen lots of other posts on the forum about this, and I was hoping this would be solved in Unity 5, but has anyone found a workaround or solution to this problem?

To summarize, the www GetAudioClip() function hitches when a stream is finished loading from the web, after accessing the www audioclip property (I assume that’s the moment when the bytes are transformed into an AudioClip). This hitch can completely freeze a device for multiple seconds, making it near unusable in a finished project.

According to my research, there are a few possible things to investigate to get around this bug, although I haven’t tested them myself yet, I’ll update this post if/when I do…

LoadLevelAdditive
Use LoadLevelAdditive to try to get the audio to stream from a background thread. Although this functionality wasn’t multi-threaded in Unity 4, so I’m not sure if this would solve the problem in Unity 5.

Investigate UniTunes and Veemix
Investigate how unity Asset Store assets apparently got an www audio stream to load SoundCloud music without hitching. This would involve delving into their assets and hoping that their code is accessible and that the solution is usable to normal Unity development.

UPDATE: Veemix responded in this thread, I’ve tested out his code solution with no change in performance.

UPDATE: I also integrated UniTunes into my application and I can confirm first hand that it works without a lag spike. Unfortunately UniTunes is only used for Sound Cloud links (MPEG) and not all AudioTypes. However the logic used to play the clips still uses AudioClip and is worth exploring further.

Only Allow Constant Bit Rate Files
Only allow audio files with a constant bit rate, which according to the linked thread, may possibly improve performance, although later posts say this doesn’t work.

I sent an email out to the original poster that said constant bit rate files should fix this. I’ll be testing this solution.

UPDATE: I tested the constant bit rate solution, and found that this had no change in performance.

Does anyone have any experience with this bug, or has anyone found a work around?

2

Hi Derrick,

We saw your email and figured it would be good to reply here for posterity. In the Asset Store version of Veemix, SoundCloud streams are loaded and played using an iOS native class, AVPlayer, not with WWW.GetAudioClip().

However, in the spirit of experimentation, I tried loading a SoundCloud stream using WWW.GetAudioClip() in a basic iOS 2D platformer game this morning, and it seems to load and play the stream without the hitches/lag that you are describing. Here is the implementation:

        public void LoadStream(){
      
            WWW www = new WWW (url); //url is the SoundCloud stream URL
            StartCoroutine (WaitForStream (www));

    }

       IEnumerator WaitForStream(WWW myStream)
    {
        yield return myStream;
      
        if (myStream.error == null) {

            AudioClip myClip = new AudioClip();

            this.myAudio.clip = myStream.GetAudioClip(false, true, AudioType.MPEG);
          
            this.myAudio.Play ();

          
        } else
        {
            Debug.Log("myStream error: " +myStream.error);
          
        }
      
    }

myAudio is just a public AudioSource, and I get a reference to it in Start() like so:

        this.myAudio = this.GetComponent<AudioSource>();

Alexander

3

Hey Veemix, thanks for the reply!

So I tried out your GetAudioClip() code with the same results. I’m going to spend tomorrow building a WebPlayer test and linking to it in this thread so I can show what the lag spike looks like.

4

Oh boy.

So to start, take a look at the following GetAudioClip() WebPlayer test…

Then try Copy+Pasting the following .ogg file from my server…
http://104.131.198.66/combu/BGM/BGM_Sanctuary_Monday_01.ogg

Spoiler Warning: It works perfectly without any hitches! So clearly the difference is somewhere outside of the GetAudioClip() logic. So I decided to profile benchmark the code in this stand alone application compared to what I was seeing in my app.

2052599--133497--1.PNG
2052599--133497--1.PNG1362×718 92 KB

Test App Profiler Results: 73B of Garbage Collection, 3.49ms to complete

2052599--133498--2.PNG
2052599--133498--2.PNG1363×721 69 KB

My App Profiler Results: 12.6KB of Garbage Collection, 2045ms to complete

The only difference I could think of, what that I was passing the www.audioClip that was downloaded into a success delegate, and sure enough, once I removed that (and any other unnecessary passing of variables) everything worked beautifully.

So for future people trying to fix this, for me the problem was with passing around unnecessary data that was being garbage collected!

Goes to show you how important profiling and creating small test builds can really be.

Thanks for everyone that responded via PM or on this thread for helping out!

5

Huzzah! Happy to see this got resolved.