Hi,
I have a lot of audio glitches with BABYLON.Sound in VR.
As soon as the sound has to be modified (the helmet moves or the sound source moves) glitches appear. I also have the problem when simulating WebXR with chrome.
I saw that it’s a quite old problem but it doesn’t seem to be solved.
Any idea ?
Bye
Adding @RaananW
What kind of audio glitches do you have? Does the sound cut completely?
1 Like
It’s more like “clicks” or “cracks” (I don’t know the correct english word).
I’m going to make a reproducer in a playground.
1 Like
would be wonderful if you can reproduce this. I never noticed any audio issues in XR, but it’s mroe than possible there are some 
I tried to make a simple reproducer in the playground, but I didn’t succeed (I used the violons11.wav file that is available in the playground).
Then I realized that there is no glitch in my app when I use this wav file.
I don’t understand why, but the glitches appear only with my wav files… even if the characteristics are exactly the same (wav, bitrate, sampling…) and even if the wav is correctly played when the source doesn’t move…
I have to investigate more and will come back to you when I’ve found the reason.
2 Likes
Ping me if you need any help with that. I hope you find the reason! And if it’s an interesting one, please share it with us
ping ! @RaananW
I made a reproducer :
https://playground.babylonjs.com/#9K3MRA#651
A sphere with a sound attached is moving around the camera.
2 samples are referenced in the playground, “violons11.wav” (from another playground) and one I made.
When the sphere is not moving (set speed to 0 in the script) both samples are played correctly.
When the speed is set to 10, my sample generates a lot of cracks, but the other sample is still played correctly.
Both sounds have the same characteristics (stereo, 44.1 kHz sampling, 16 bits depth, PCM encoding…).
I just don’t understand !
And all the sounds I’m creating have the same problems :-/
Any idea ?
PS: I’ve exagerated the speed of the sphere but problems appear also when the sphere is moving slowlier.
Very interesting. Hey much reproducable.
I’ll see what the issue might be and will keep you updated
1 Like
I tested with some reference audio file and it sounds OK.
Probably gliltches (digital clipping) relates to the way how your file was made.
One will have same problems when using low quality MP3 for spatial audio - because of low bitrate.
Are you sure that bitrate of your audio was always the same from the beginning and do you know if there was heavy audio compression/limiting applied to the original content?
1 Like
I thought first that it was a kind of encoding problem, but both files have exactly the same characteristics :
encoding : pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, stereo, s16, 1411 kb/s
And if it was an encoding problem, it could not explain why the sample is played correctly when the source is not moving…
I am really puzzled 
For example, if this wav file was converted from mp3 file, it has the same flows as the original mp3 file.
Or maybe because it was heavily processed with some limiters so we hear clicks when volume is changing quickly. Do you know the story of your wav file?
I’ve generated the file using the Nexus plugin within Logic Pro. Logic directly generated it in this wav format.
I can imagine that changing the volume quickly can generate clicks if it is done abruptly (I should try to simulate it), but maybe there is a way to smooth the volume changing ?
Otherwise I can try to also “smooth” the wav, but I’m not sure it is possible to do it without changing completely the sound.
I’m afraid that the method (algorithm) used to change the volume for the spatialization and movement of the sound prevents certain types of sound from being used.
@RaananW , ping again
This is not due to the encoding but to the pitch of the sounds.
Low sounds generate cracks.
I used a synth to generate 2 sounds : one is C1, the other is C4 (much higher pitched sound). The same encoding of the sound, the same synth preset.
A lot of cracks with C1, none with C4.
Here is the updated playground :
https://playground.babylonjs.com/#9K3MRA#664
Both are played correctly if the source is not moving.
It seems to be a signal processing problem, linked to the quick change of the volume of the sound.
It is annoying in VR because turning the head leads a quick change of the volume.
Hope my explanation helps
1 Like
I put there 60Hz reference .wav and glitches are even worse 
- https://playground.babylonjs.com/#9K3MRA#665
Also, when you switch to another tab, the sound freezes in it’s last position and then has some pauses.
1 Like
What may be interesting is that the same glitches appear at this example - Web Audio Spacialisation , especially for lower frequencies.
2 Likes
Yes, this does seem to be an issue with the AudioContext implementation.
We are internally using setOrientation on the AudioListener, which is deprecated byt still works. When I switch the implementation to the newer setting methods (like linearRampToValueAtTime), it did work well only when setting a 2 seconds ramp. I am still investigating if there is anything else we can do so I will keep this open. I’ll create a github issue to follow up on this. I do find it really werid that it only happens with specific files. Would you be able to try with the same file but exported as a mono wav file?
After researching further - this is a combination of the audio context deprecated function and our update interval. We don’t update on each frame, we update roughly twice every second. Set
scene.audioPositioningRefreshRate to 1 and it will click a lot less. If I switch to the linearClamp method instead of setOrientation the clicks are gone. I’ll submit a ticket to do the work and avoid using the deprecated methods.
1 Like