In Twilight Daycare, audio seems to often fail to load (but not always). In one day alone, we’ve had hundreds of thousands of errors related to some sounds:
Many of these sounds are under the Roblox account, such as this. And the sounds don’t always fail to load, so I don’t believe it is a permission error.
Expected behavior
Sounds shouldn’t be failing to load this often.
Hi there!
The 'error code 46' often means that the client had and issue with playing the audio;
Which may be caused from an alternative encoding:
To, even, copyright issues (even if the audios are uploaded by Roblox’ official account):
Moving on, in the case of the 'Failed to load sound: Unable to download sound data' error, there’re many possible causes. Among them:
Additionally, here are some other possible causes based on personal experience (they’re subjective and they may be the result of personal biases, so consider them with a grain of salt):
It can be very frustrating to face a problem that you don’t even know where it’s originating from, so I hope this information helps you solve your problem.
Good luck! 
Thanks for the reply,
It’s possible that it has something to do with the encoding or with copyright issues, but because it only happens sometimes to some audio, it makes me think it’s probably not those. Maybe an audio issue that only affects certain clients for some reason?
The accounts do have permission and it hasn’t been moderated so I don’t think those are the issue. Could be due to slow internet or memory usage or some other issue, and it could also be due to trying to load sounds too quickly.
You’re right, it may be due to all those possibilities.
I recommend you to try implementing workarounds to possible causes that are under your control, for instance, if the load of audios (and assets in general) is very abrupt, try adding prorating measures (this includes, but is not limited to, adding some task.wait()s).
The best of luck.
Hey jakedies, we’ve been looking into this, and there are a few different potential causes.
The Sounds that were failing to load with “Error code 46” are encountering issues after downloading – this could happen for a variety of reasons (e.x. wonky formatting), so we flipped a flag to log more descriptive error messages (so you shouldn’t be seeing much code 46 anymore).
After flipping that flag, we noticed a lot of “file not found” errors getting logged.
The total number of files we can open simultaneously varies by platform, but we tend to stream larger audio assets from disk so that we don’t use as much memory. So, if your experience loads lots of long audio assets (such as background music, long ambience loops, etc), we may be streaming most of it from disk, and running out of file handles!
We’ve implemented a fix to use fewer file handles, which should be rolling out in the coming release – but if you want to get a jump on the problem, :Destroying Sounds after you’re done with them can also help free up resources here.
Unfortunately, the Sounds that are failing with “Unable to download sound data” are a different class of errors that could also be occurring for a variety of reasons; Permissions are part of this, but moderation or general network instability can also play a role. We will keep investigating on that front; we’ve got a change queued up to log more descriptive error messages there as well.
Yeah we have a ton of sounds so that might be a cause. Is there a reason Roblox doesn’t unload old sounds when new sounds need to be played? I think it works like that for animations already but I could be mistaken.
Generally we don’t know when scripts might want to use a Sound – if the Sound is in the DataModel, a script could :Play it at any time, so unloading it might be inconvenient (the asset may have to be reloaded or even redownloaded, which would lead to playback lag)
Under extreme resource pressure (e.x. really high memory usage) we do actually start unloading the least-recently-used audio assets, but only as a load-shedding mechanism, it’s not something we want to be doing aggressively 
Thanks for letting me know! Should I apply this knowledge to other assets, like Animations, Decals/Textures, Meshes, and so on? Or is this just specific to sounds?
This frequently happens before launching our updates and nothing fixes it. Has been a major pain point for me. I have to make sure all audio is uploaded well in advance. Permissions being manually set doesn’t fix it either.
In general there shouldn’t be such strict permissions in Studio for sounds that I own. Especially since the main concern, sounds not being whitelisted to the experience, will play anyway. It’s backwards and no other asset type works this way.
It’s generally a good idea to delete unused assets when you’re done with them – this may not be strictly necessary to prevent crashes, but buildup of unused assets forces the engine to decide which ones to evict; sometimes that logic can get it wrong (e.x. unload an asset that you were about to use).
I mentioned earlier
We’ve implemented a fix to use fewer file handles
Which should address these file not found errors.
Unfortunately, I enabled the fix in December and everything looked fine for a few hours, but it led to increased crashes on iOS so we had to turn it off & re-investigate.
The revised fix is rolling out slowly now, but it’s only enabled on Mac so far.
