I have absolutely no idea how to replicate this aside from just multiple random sets of play testing. It does not happen every single time, but happens frequently enough to be extremely frustrating. It happens both in game and in studio. This has likely been happening for a while but I’ve only actually noticed it myself about 3 days ago.
Multiple other players have reported this happening.
This issue happens with default character sounds that we don’t touch at all, too, so I’m fairly certain that this is some sort of engine issue.
For example:
All of these sounds will play only from where the character first initially spawned. If I move away from the spawn area, the sounds gets fainter and fainter. It’s like occasionally the sound engine bugs out and does not allow any sounds to follow the part that they’re parented to.
I stumbled upon this when trying to have sounds play from a moving vehicle. Most of the time it works with no issue at all, but occasionally the sound can only be heard from wherever the vehicle was first spawned into the workspace.
“Playing” on the sound will say true - everything looks fine. If I suddenly parent the sound to a folder or a sound group, I can suddenly hear it, but unfortunately that isn’t a solid workaround because then I can hear it from everywhere, not from object that I actually want the sound to emit from.
Some info that I think could potentially be relevant:
The place where this keeps happening has StreamingEnabled and set to Opportunistic. StreamingIntegrityMode is Default. ModelStreamingBehavior is also default. For SoundService, VolumetricAudio is disabled (we can’t enable it at the moment due to other issues).
Edit: Some more context - it seems to happen more frequently for some players than others. For me it’s maybe 1 in every 15 or 20 sessions. For the person I work with, it’s probably more like 1 in 3 sessions.
Hey Scriptos; thanks for reporting – to clarify, you can still hear the sound coming from the part’s original position? Or does it cut out completely? Either one seems unexpected, but they would likely have different root causes.
Whenever this happens, it seems the sound is coming from the part’s original position (where it was first inserted into the workspace).
We’d spawn a vehicle and the sound would play from where the vehicle was first spawned - and then I noticed that I couldn’t hear my player character sounds either, so I went to player spawn area and could suddenly hear my jumping sound (completely unmodified) coming from the spawn location spot.
And when it happens, it seemingly happens to every sound in the game for that session.
We don’t have a custom StarterCharacter, either. It’s just the default character with the default sounds scripts (of which none have PlayOnRemove set to true).
Edit: I think most, if not all, of the sounds are played locally for each client. As in we trigger the :Play() function in client scripts, and I believe the default humanoid sounds are already coded to play that way, too.
Does this occur in studio, or only live play sessions? I’m curious if you could try setting HumanoidRootPart’s Transparency to 0 when it happens with the default character sounds.
From there, we’d be able to see if the sound isn’t moving because the part isn’t moving, or because of a bug in Sound’s positioning logic
We’re actually having trouble replicating this now and haven’t heard anyone report it since maybe a few days after making this post, so it’s possible it was fixed? If not, it’s at least a lot more rare (but was already decently rare on my end). If we end up experiencing issue again then I’ll post with more info.
Just in case it isn’t actually fixed, though - I do know that when it was happening, I already checked the server and client views and saw that the character’s root part and everything else affected were all moving properly on both ends.
Edit: Realized I forgot to answer your first question after reading @sozzly’s reply. For me it was occurring in both studio and live play sessions.
Hi - I don’t know if this is related, but it sounds similar enough to reply.
For our game’s monorail, we have a part that emits a sound based on the train’s current state, because we don’t want to have multiple sounds playing for the train simultaneously. This part is positioned to the closest point on the train relative to the player’s root. We have streaming enabled on, ModelStreamingMode: Improved, StreamingMinRadius: 100, StreamingMaxRadius: 300, StreamOutBehavior: Opportunistic.
Upon observation, when the train is unloaded, the emitter is added/removed repeatedly into its original parent - I verified this by listening to .ChildAdded and it will spam the output while the train is unloaded - and it sounds exactly like Scriptos is describing. The sound will start emitting, then stop emitting, in a loop, at the initial point of where the train was when the server started until the train is loaded again. These sounds are only played on the client.
Interesting; that doesn’t seem intended – to clarify, the child being spam-added & removed is the Part that you’re repositioning based on the closest point calculation? Or is it the Sound itself?
What was its original parent, and does that differ from the new, intended parent?
@sozzly in the repro place you provided the position of the sound emitter is being set via a local script. This is causing a desync because from the client perspective the sound emitter part is far away and is then GC’d. From the server perspective the emitter is near the player and should be streamed, so it is resent again. Soon after the part arrives on the client it is positioned far away again by the local script, repeating the cycle.
I would recommend not creating a desync like this due to positioning parts via a local script. If you attach the emitter to the train via a physics connection, or reposition them via a server script you should not see this behavior.
I believe this is also why the audio sounds wonky in your example –
The Part has a child Sound, and when the part gets added on your client, the sound begins emitting from the part’s position immediately. A localscript moves the part far away, which causes the sound to catch up to its new position, but then it gets GC’d, causing the sound to cut out.
This would explain the “flickering” or “sputtering” effect, and why the Sound is temporarily coming from the original position during each respawn.
I am not sure if this is the same issue that @Scriptos was experiencing though
This part sounds the same as what I experienced, but we weren’t moving the characters locally or anything. We do something like that at some point, but the issue would occur sometimes immediately after respawning in, when nothing on our end would be affecting the character at all. And I know for certain that the objects affected (i.e., the vehicles, too) were in the same positions on the server and client, regardless. And then it seemed that whenever it would happen, it’d apply to literally every sound in the game.
I also had confirmation from multiple people (in studio and outside of it) that they were experiencing the same issue. None of us have replicated it again though, since about a week after making this post… yet. One tester even claims to experience it in other games, but I’m not completely sure on the validity of that. So at the moment it appears to not be a problem for us but is obviously still very curious.
It definitely doesn’t seem expected; from squinting at Sound’s internal 3d-positioning-logic, nothing is jumping out at me. If it happens again and you can capture some additional information that would be helpful – even video recordings may be illuminating (sometimes we can hear patterns that make debugging/root-causing easier)
