adamjford

Adam

@adamjford

log inask
adamjford
@adamjford
vogon
@vogon
Thew
@Thew

Playing audio with physical speed-of-sound simulation

still gotta make a nicer video for twitter but cohost gets the Real Behind The Scenes Shit

I did some Audio Programming and figured out how to account for the physical travel time between an audio source and a listener. This means you get accurate time delays for stuff like lightning/thunder, but more interestingly: actually-correct Doppler effects

Cool Stuff:

  • The colored rings are traveling at the speed of sound (343m/s in this case) with each pulse synced [approximately] to the BPM
  • This essentially visualizes the doppler effect. When the camera is flying towards the source the pitch increases, but if you watch when the rings pass the camera you can hear that the beats are still lining up
  • When the camera flies AWAY from the source (1:24 in the video), the pitch bends downwards as we accelerate, becoming completely silent when the speed matches the rings, and then the music starts playing BACKWARDS as the camera exceeds the speed of sound and starts OVERTAKING the wavefront

I originally had a cool art/game thing I wanted to make with this, but I ran into multiple "core unity functionality that has been broken since 2016" issues so I'm just gonna stop here lol

Music is Professor Kliq - Tachmania from the Trackmania 2 soundtrack (it rules)

You must log in to comment.

in reply to @Thew's post:

strangebroadcasts
@strangebroadcasts

This is very cool!

and then the music starts playing BACKWARDS as the camera exceeds the speed of sound and starts OVERTAKING the wavefront

How do you pull this off - are you keeping a buffer with the past audio samples, or setting the sound to play in reverse at the appropriate time?

login to reply
Thew
@Thew

There's no history or speed/reverse control, it's just pulling samples out of the music file at specifically-calculated positions and passing them along to the audio system

Given a fixed emitter position, a variable listener position, speed of sound, and the time that playback started, it's possible to just directly calculate which sample is currently hitting the listener's ears at any arbitrary time. The actual math is simple, basically just [time since playback started] - [time of flight]. If you do this correctly, all the doppler stuff just happens for free, inherently.

All the actual complexity is just implementation details. Dealing with the audio buffer, dealing with game logic and audio on separate threads, dealing with resampling, dealing with float precision, etc lol

login to reply