Playing the same audio clip from multiple audio sources in 4.5

Hi y'all --

Seems that in the update to Unity 4.5 it's no longer possible to play the same audio clip from multiple sources in a scene (simultaneously). Has anyone else encountered this behavior? Whichever audio source was instantiated last plays, but all others which share a clip are stopped. This is true whether the objects are created in code or set up in the scene view.

One way we are able to work around it is by cloning the audio clip object at run time, like:

Code (csharp):

1. AudioClip secondClip = (AudioClip)Instantiate(firstClip);

But this only helps when setting up audio sources/clips at run time. We have some scenes where several audio sources in the scene play the same clip (humming streetlights, for example).

Any insight?

 

I noticed this today. I have an asset in the asset store that completely depends on playing the same clip in multiple channels. I would really like this fixed soon, obviously. I assume it's a bug.

 

I found a comment on a 2010 Unity Answers thread called What is the proper way to copy an audio clip? that sounds relevant:

But I've never run into this restriction before 4.5. Could it be a regression of something that was fixed between 2010 and now?

I'll send a report to Unity with a sample project. Just wanted to see if anyone here had any insight before we roll our project back to 4.3

 

I found the same issue.

To compare, take a version of my game compiled with 4.3:

http://www.pacogames.com/action/hard-point-tank/en

Now, check the problem at this version compiled with 4.5:

http://www.wooglie.com/games/Action/Hard.Point

I'm also sending a report.

 

I'm not sure anymore if it is a bug or intended behavior, but I find it slightly absurd to have to make multiple copies of the full audio data. It seems to me that multiple pointers is all that should be needed. Anyhow, I felt I had to update my asset to work with 4.5, so I did...

 

Must be a bug. In the past they made a big deal about how you DON'T have to duplicate audio clips to get this functionality. File a bug report.

 

Definitely a bug. Duplicating AudioClips is NOT a good idea, you'll flood your ram with useless data.

Bit of self promo here: G-Audio works directly with data ( AudioClips are dumped once loaded ), so our users are not impacted.

Cheers,

Gregzo

 

New findings: The bug only seems to occur with clips that have "Audio Format: Compressed (OGGVORBIS)" and "Load type: Compressed in memory".

 

Got the same issue.
For the "load type" : it works in the editor with the stream from disc option ( but doesn't work in a standalone build ). Compressed in memory doesn't work in the editor or a standalone build.

 

same issue , i thought the bug was only affecting PlayOneShot() cause is what i was using mostly on my whole project, so i rewrote the code to use Play() instead, and now i found that its happening the same problem, its a bug apparently related to some specific audio clips

i managed to get some sounds to work by reimporting all the sounds folder, i tested the ahem in editor and was ok , then i build and the standalone does not work , then i go back to editor and now is not working here as well ... ?!?!? nonsense, its a bug

is it possible to get back to 4.3 now that the whole project is "converted" to 4.5? no issues?

 

Just in case somebody read this thread in the future, the issue has been fixed in the 4.5.1p2 patch and the fix is present in Unity 4.5.2f1.

 

Hello, this is one hell of a big bump but I'm experiencing this bug both in Unity 2019.3.15f1 and Unity 2019.4.17f1 !
The exact same bug as described here:
- I have clips loaded dynamically as OGGVORBIS, but they're not compressed, only streamed from disk
- Only the last audiosource I play is actually playing, the other sources with the same clip just Stop() on their own.

Here's a video recording :

I have found no way to mitigate this so far.

Code (CSharp):

1.         Debug.Log(gameObject.name + " engine: " + engineSource?.isPlaying + " clip "+engineSource?.clip?.name);

 

Note for whoever reads this in the future:

This is due to the property DownloadHandlerAudioClip.StreamAudio ! It makes the loading of audio files lag-less, but also provides only one instance of a clip at a time. Putting this property to false on the sounds I want to play in parallel solves the problem.