When an AudioEmitter is unloaded by StreamingEnabled, the audio currently playing from the AudioEmitter will continue playing and will act like a ‘Sound’ that is not parented to any part (aka it plays without an origin location, destroying the ears of players)
Expected behavior
When AudioEmitter is unloaded by StreamingEnabled, audio is not audible by client.
Hey @cl0vermead0w – I wasn’t able to reproduce this exactly; I tried a few things:
First I tried attaching an AudioEmitter to a Part, and setting Workspace.StreamingTargetRadius to 64
After running away from the part, both the Part & AudioEmitter stream out, and the AudioPlayer wired to the emitter falls silent – which sounds like what you expected
Then I tried parenting the AudioEmitter to a Model that has a Part
with this setup, after running away from the part, it streams out, but the Model & AudioEmitter do not. So, audio continues emitting from the Model’s position; in this case, that’s inferred to be wherever the part used to be – maybe this is what you’re encountering?
If that’s the case, it’s possible to make the model also stream-out alongside any of its constituent Parts by setting ModelStreamingMode to Atomic
Do you have an rbxl that reproduces the bug? I can take a look
Unfortunately, I can only replicate this bug in a certain place and it is quite sensitive and large. We are setting up AudioEmitters via script, so maybe that could reproduce the issue? If not then I’ll just close this since if you aren’t able to reproduce I’m just assuming something is wrong with our configuration.
Are AudioEmitters parented to Models in your place?
If it’s caused by the default model-streaming behavior, you could try making those models Atomic so that their constituent parts always exist alongside the Model & Emitter
You could also try setting Workspace.ModelStreamingBehavior to Improved – this will cause Models to stream-out once all of their constituent parts have streamed-out
Thanks - I’ll give that a go;
I do also have users reporting that the sound doesn’t stop, even once they’ve turned down their volume to 0 via the Roblox escape menu, until the model loads again. Which suggests it maybe isn’t my configuration. I’ll give the ModelStreamingBehavor change a try and see if it solves the issue.
Still happening, can’t figure out why. Just going to set the affected models to Persistent and hope it helps.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
Hi there, reopened the thread in case anyone else is encountering this. Did switching to Persistent solve this issue for you?
I’m encountering this issue in a project I’m working on, with both StreamingEnabled and Improved ModelStreamingBehavior turned on. When a player first joins the game, assets begin to stream in. and during this time, it appears that some sounds are played before they are properly parented to model with a part/PrimaryPart. Due to this the audio behaves as if it was playing globally since it has no origin and comes across as unusually loud.
Thanks - to clarify, is this for Sound instances or the newer API components?
We have experienced it with both, the instruments in our game use the new API components whilst most of the combat SFX use the Sound instances.
After migrating to the new Audio API, we noticed that playing AudioPlayer instances while the game is still loading sounds produces, abnormally loud playback that sounds global. It only occurs once on game join and then the issue dissipates, additionally it seems to ignore the AudioInteractionGroup when the issue occurs, as the game does not have any listeners to the group but it still plays the sound. I have attached a place file that you can hopefully reproduce the issue.
Just hit play and hold W, if done correctly the first footstep sound should be significantly louder than it should be. Additionally, the AudioInteractionGroup is set to “SFX” and there is no listeners for it, so it should not even be heard.
LoudSoundIssue.rbxl (71.6 KB)
Hey @Star_Mades – thanks so much for the repro file. I’m able to hear the same result and will check it out
Another update on this – found the root cause (of the bug with AudioPlayer ignoring Wires) and put in a fix; the flag should go out in v685 (unfortunately missed the deadline for 684 next week)
Fantastic news! However, there’s seems to be a possibly related issue; if an AudioPlayer and AudioEmitter are parented to a part, then played and quickly destroyed, the sound becomes global and unnaturally loud (same as the previous bug), but additionally continues to play even though both instances were destroyed. It also contains the AudioInteractionGroup issue of the previous bug. This may occur during streaming as instances are destroyed/unparented when streamed out.
I have once again attached a place file so that you can reproduce the issue, simply hit play and wait a second or two. If successful the “Burning” sound should be heard globally and louder than expected despite the instances being destroyed.
DestroyedSoundIssue.rbxl (65.2 KB)
Hey @Star_Mades – thanks for the new file; I was able to reproduce that behavior as well, and the good news is that this is another version of the same bug – so it appears to be fixed by the same flag 
You said you were able to reproduce this with Sound as well – do you happen to have a file that encounters a similar issue there? These are super helpful in validating fixes
Unfortunately, I don’t have any repro place files using Sound instances. One of the main reasons we switched to the Audio API was to resolve that issue. I tried a few things to reproduce the global/loud audio behavior using Sound but was unsuccessful. Previously, it would occur simply by loading into the game with sounds already playing. If it happens again in our experience, I’ll investigate further and provide a repro place file.
