Hey @CryBlania, audio assets are compressed, so under the hood, GetWaveformAsync has to
- seek to the beginning of the NumberRange
- decode a chunk of audio from the compressed representation
- write results into the table that it gives back to you
- repeat 2 & 3 until reaching the end of the NumberRange
All that is to say – the amount of time it takes to do 1 & 2 can vary depending on how the file was compressed, whether the file is short/long, and a bunch of other pretty random factors 
– this is the main reason it’s Async rather than instant.
The catalog assets might have got lucky in the compression lotto 
Regardless, I think there are a couple tweaks that could make the stuttering better:
In your script, I see you’re analyzing the waveform once-per-frame in RenderStepped, and requesting a 10-sample waveform for 100ms of audio at a time:
return audioPlayer:GetWaveformAsync(NumberRange.new(timePosition, timePosition + 0.1), 10)
it might take multiple frames for GetWaveformAsync to finish, which could be causing the stutters you’re seeing – to remedy this, you could take more samples, and re-use those samples across frames; something like
if previousWindow and timePosition < previousWindow.EndTime then
return previousWindow.Samples
end
local startTime = timePosition
local endTime = timePosition + 1000
local window = {
StartTime = startTime
EndTime = endTime
Samples = audioPlayer:GetWaveformAsync(NumberRange.new(startTime, endTime), 1000)
}
previousWindow = window
return window.Samples
since each GetWaveformAsync might take a while, this tries to make big batch requests instead of many tiny requests
Another thought: you could probably use AudioAnalyzer.RmsLevel instead of GetWaveformAsync here – AudioAnalyzer is not asynchronous, so it’s better suited for realtime analysis while an audio asset is actively playing – GetWaveformAsync is intended more for offline analysis while an asset is not playing
