I have one last question about implementing a personal optimization procedure until you guys do your thing.
Lets say i have 300 sounds. The 301st sound, played, will not produce an output in this case. If i were to “:Stop()” the 300th sound, will that make the 301st sound produce an output again ? (like making room for it among the sounds that can be heard).
(Trying to purge trough audioplayers and “:Play()” / “:Stop()” only the ones that are close enough to the player.)
Yeah I imagine that would work – that said, ideally it’s not something you’d have to worry about doing manually! Sounds that are completely inaudible (e.x. their volume is 0, their emitters are really far away, etc) should not contribute to the total count, yet currently they do.
Do you have a ballpark number of concurrent audio files you’d need? We can up the cap to 400 until we land the audibility fix
If i were to really go overkill, 30 sounds per unit x20 will result around 500 sounds. But firstly I’ll try to implement my optimization, without making you risk breaking other engine functionalities.
I’ll get back with a reply once I’m done.
My conclusion: Its… weird… to say the least.
Playing and stopping sounds on the fly does and does not work at the same time. When first loading ~57 audios, not all of them produce an output. When purging them one by one by moving the camera randomly, some do not load. But when i get far enough to stop all of them, after i return to load the closest unit all the sounds caught do get played (and again moving the camera around them by loading/unloading randomly still doesn’t work until i unload everything).
Edit: Also i do experience lag spikes when loading/unloading the sounds. (nevermind, adding a task.wait() between executes seems to fix it)
This is a very great release! Although I do have a concern. AudioEmitters do not work with Volumetric Parts, meaning the origin of the audios basically start from nothing.
I am working on a game where I am composing an indoor ambience, and I am using Parts as the volume of the Sound. DistanceAttenuation does not respect the Part’s volume, and instead fades from its origin!
@aaxtatious This is a good point. FMOD (the underlying library Roblox uses) has a concept of “Sound Size” that I believe addresses this issue. This allows you to be ‘enveloped’ in the sound when you’re within a certain radius of the sound.
Taken literally, what you’re requesting could be addressed by setting the attenuation curve to start attenuation from a certain distance from the object rather than from 0, which may have some of the effect you desire? This wouldn’t have quite the same effect as the sound size option.
For the sake easy threading I wanted to connect your old feature request here to the release post 
Feedback is a real thing in the real world too where a microphone picks up a sound from a speaker and the speaker replays an amplified version of it into the microphone creating a loop, where every replay is louder
Yup! In some sense, emitters and listeners exhibit the same behavior as real-world speakers and microphones – but in reality, speakers & microphones can get blown or damaged – in the digital world, things can just keep getting louder 
(barring floating point shenanigans)
The documentation told me that if an AudioEmitter is not part of a BasePart, Attachment, Camera or PVInstance, it cannot make any noise.
AudioEmitter and AudioListener infer their CFrame (position & orientation) from their parent – if they don’t have a 3d position & orientation, the audio engine doesn’t know where to emit or listen from
This new Audio API opens up a ton of new possibilities like a hypothetical PSTN/landline or an intercom
Hey I’ve recently changed it to use my own Voice setup how do I change my volume? I can hear people from far away I’ve search it a little better I found SetDistanceAttenuation which controls how an audio emitter’s volume changes with distance I just dont know if this is the right thing I need to use
Hey @rivenrd – that would work!
The default distance attenuation curve that AudioEmitters use looks something like
volume = 1 / math.max(distance, 1)
which gets quieter as distance gets bigger – but doesn’t ever fully hit zero.
If you want to keep the same general shape but silence the emitter after a certain MAX distance, you could do something like
local curve = {}
for distance = 1, MAX do
curve[distance] = 1 / distance
end
curve[MAX] = 0
theEmitter:SetDistanceAttenuation(curve)
Hello, good morning/afternoon,
I’d like to report a bug with the new Audio API. I’m not sure if anyone has already noticed or mentioned it, but if so, I apologize in advance.
The issue happens with the AudioPlayer instance, specifically with the AssetId variable. When I input an ID, it doesn’t work because the rbxassetid:// prefix is missing. However, when I use the Sound instance, I can input the ID, and it automatically adds the rbxassetid:// prefix.
Could you let me know if you’re planning to bring this feature back, or if it’s supposed to work but is currently bugged?
Thank you, and have a great day!
For some reason, the sound instance is not being picked up on audio listeners, while audio players are being picked up. This can be seen in this video.
I’ve uploaded the place file here for further inspection.
soundtest.rbxl (115.5 KB)
How do I mix two audio sources?
This new audio API, coupled with the EditableImage API opens for some new interesting gameplay mechanics previously not feasible in Roblox
Hey @kepiblop_house – this is unfortunately intended.
Sound behaves like an AudioPlayer + AudioEmitter + AudioListener + AudioDeviceOutput all in one; it does everything from playing to spatializing & rendering a file, making it difficult to ‘intercept’ the signal flow without accidentally breaking something.
We would have liked to make this compatible with AudioListeners, but there are some subtle semantics especially when SoundEffects and SoundGroups are in the mix.
Currently, AudioListeners can only hear AudioEmitters
Setting the attenuation as a flat curve does not ‘envelop’ the listener the same way as the classic sound instance does when coming from a base part. This isn’t a work around for the original behavior, unfortunately.
I would love to use the new audio APIs but volumetric sound from parts is an absolute must. Most developers use volumetric sounds because we want an ‘ambient’ for a particular room or region in a map, and its a simple, no-code solution. To achieve something similiar with audio emitters/listeners, a no-code solution is imperfect and clunky. A scripted solution involving moving the emitter based on the listeners position relative to the basepart’s volume would work better but it just adds a lot of technical bloat to achieve a behavior that was already possible with the legacy sound instance.
I know you mentioned its technically tricky with the new audio system, but is there any hope of some form of volumetric sound being look at for the future? @ReallyLongArms Thanks, I appreciate all the hard work that went into this!