Hey @JavascriptLibrary, would you mind sending me a rbxl of your setup? I can check it out to see if I spot anything – that diagram looks like it ought to work
2 Likes
Also bumping this, would be extremely useful to have volumetric audio support - bit of a let down this isn’t implemented already.
2 Likes
Looking over some of the returns and I am interested why GetConnectedWires doesn’t guarantee a return of Wires, rather than Instances. Is there a specific reason for this?
1 Like
This was probably an oversight; we can refine the type annotation
2 Likes
I’ve been using the new API for a fairly complex project and it’s working great.
@ReallyLongArms Just a small request: Is there any way we could have an API that would let us keep multiple sounds in sync more precisely? I’d like to layer multiple music stems over each other, that can be dynamically controlled based on gameplay, and the current system makes that impossible to do quite right (there are other threads complaining about this same issue with the old system going back some years).
The current approach I have is to keep track of my own time and then check if the stems are deviating from where I expect them to be by more than some threshold, and then re-sync them, but although this stops significant drift, it doesn’t really solve the problem. I believe a fundamental issue is that TimePosition is only updated once per frame, and that setting it probably is also only applied the next frame. This means that my attempts to keep sounds in sync will always fail as I can’t know how long the current frame is going to be.
Solutions could either be functions to get and set the current time that are immediately applied or perhaps some way to schedule a sound to start at a precise moment. Unity for example has AudioSource.PlayScheduled.
3 Likes
Hey @Ed_Win5000, you’re totally right – synchronization & sequencing are really challenging on the platform today, because most of our engine systems can only make property changes or call methods during certain time-windows of each frame.
We’ve thought about several approaches, and part of what makes this so tricky is that a satisfying solution needs to cover not just Play/Stop, but also any property whose effects can be heard/observed more often than the framerate (e.x. Volume, PlaybackSpeed, Pitch, DelayTime, WetLevel, TimePosition).
I can’t promise anything soon, but we’re very aware of the pain points here
4 Likes
any reason why AudioAnalyzers are limited to a 512 point fft? bit tricky making any accurate audio visualiser since all the low end is a lot more prominent as each point is 46hz. is it a performance limitation? with optimised enough code you can easily hook up an AudioAnalyzer to a visualiser and even throw some extra mumbo jumbo ontop of that and still render in <1.5ms
3 Likes
I get an error when connecting the Microphone to the Listener .
I’m unsure if this is a bug or if I am doing something wrong.
Relevant post: (solved but the Analyzer:GetSpectrum() is always empty)
Hey @deseriaIiser, we’ve discussed adding an AudioAnalyzer.WindowSize property before and might still do that; it’s not a performance issue
1 Like
awesome, hoping the plan goes through.
@ReallyLongArms Any word on when volumetric audio will be supported with the new AudioEmitter API? It’s severely disappointing not having support for it at the current moment. I was contemplating converting to the new system with my team to take advantage of the lovely new features, but not being able to make “stereo” audio in the 3D gameworld is a massive setback.
Are there any temporary solutions to volumetric audio with the current API? Any panning filters planned? etc.
I’d love to use the new system, but the lack of an ability to split up the L and R channels of a stereo file is really disappointing…
- Panzerv1
2 Likes
Hey @panzerv1, at the moment your best bet is probably dispersing emitters around the surface of a part; something like
local fader : AudioFader = script.AudioFader
local part : BasePart = script.Parent
local rng = Random.new()
local pointCount : number = script:GetAttribute("Points") or 500
local function getLocalPoint() : Vector3
local cframe = part.CFrame
local bounds = part.Size / 2
local radius = bounds.Magnitude
local vec = rng:NextUnitVector() * radius
vec = cframe:PointToWorldSpace(vec)
vec = part:GetClosestPointOnSurface(vec)
return cframe:PointToObjectSpace(vec)
end
local function wireUp(src : Instance, dst : Instance)
local wire = Instance.new("Wire", dst)
wire.SourceInstance = src
wire.TargetInstance = dst
end
for i = 1, pointCount do
local attachment = Instance.new("Attachment", part)
local cframe = part.CFrame
attachment.Position = getLocalPoint()
local emitter = Instance.new("AudioEmitter", attachment)
wireUp(fader, emitter)
end
emitters and listeners are just panners under the hood, so this should be pretty cheap, and it generalizes to any part shape!
We’ve discussed adding “Channel Splitter” or “Channel Combiner” instances so that you can split out channels and route them to particular emitters – the main complication is that we don’t want the API to behave differently depending on what output device you’re using, and there are a couple of effects that use a different number of channels depending on what your hardware supports.
1 Like
I understand that Surround sound such as 5.1 setups are very rare for the platform, but not having the ability to take one sound id instance and pan the channels of it in any way is a bit limiting. The core tools I need as a sound designer are volume, EQ, and panning. Without direct control of panning for even a stereo file is very limiting.
Stereo output is the most common speaker / headphone output in gaming.
I was talking with my boss (programmer) and we realized that multiple emitters are panning on one part because there was no phase cancellation.
Is there a possibility of at least L and R channel panning in the near future? My sound design in our game had to take a 6 year setback in terms of quality and it hurt. We were sounding like an up to date 2024 game, but now we have to go back to 2018.
I really appreciate the response so soon and I hope the future holds some improvements for the API because it has SO much good stuff.
Cheers,
- Panzerv1
1 Like
Is there a possibility of at least L and R channel panning in the near future?
This would be possible with a Channel Splitter instance – something that takes a single input stream and gives you the individual channels to be processed or modified as needed.
Currently, when you wire anything to an AudioEmitter, all of its channels get emitted from a single location, which makes it sound effectively mono.
We’re aware of the limitation and hope to solve it in a way that won’t design us into a corner long-term
1 Like
There is currently a limit when playing more than ~300 audio sources (regardless the number of audio emitters) which is really a bottleneck for my system. Adding more than 300 audio sources linked to emitters lead to some of them not playing at all.
I’ve tested in a number of ways, but for my application i use around 15-20 sounds per source emitted trough 6 speakers (each unit). The volume and other properties do get applied to the sources but the sound is not coming off from sources added after the ~300 ish limit i suppose.
Edit: For context all the emitters are not modulated at all, and there is only a reverb process done after the general audio is captured by the audio listner.
Hey @cellork1; this limitation is present with Sounds too, but we try to cull/drop the least audible audio files when too many are playing at once. AudioPlayer doesn’t correctly take audibility into account, which is why you might notice it more prominently with the new api.
We have a flag to fix that, but it caused some other issues and had to be disabled – hoping to get that re-enabled soon
5 Likes
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.
1 Like