Adding the option to emulate sound propagation delay.

[Frostie314159]

Since there haven't been any updates for two years and due to a lack of an alternative in the area of spacial audio, I'd like to know if there is any interest in development left.

[mbillingr]

Hi, thanks for your interest in ambisonic!

It's not dead, yet... let's say it's sleeping instead.

I'm not currently using audio, that's why no new features are being added to this project at the moment. However, I'm happy to provide support or update dependencies if there is demand. Pull requests are welcome too :)

[Frostie314159]

Hi, thanks for the quick response! I might have something cooked up for a merge request! Hint: Speed of sound

[mbillingr]

Sounds interesting. Physical speed of sound, such as used for doppler effects or speed of playback?

[Frostie314159]

My idea was to add a toggle for a distance based delay for sound. This would require the user to set a scale.

On Tue, 3 Jan 2023, 19:59 mbillingr, @.***> wrote:

Sounds interesting. Physical speed of sound, such as used for doppler effects or speed of playback?

— Reply to this email directly, view it on GitHub https://github.com/mbillingr/ambisonic/issues/17#issuecomment-1369739006, or unsubscribe https://github.com/notifications/unsubscribe-auth/AT734OAFDJI577DFS5U6563WQQPBVANCNFSM6AAAAAATPQHM6U . You are receiving this because you authored the thread.Message ID: @.***>

[mbillingr]

This might come at a cost, though. In the general case a realistic simulation requires a variable-length buffer for each sound source. Maybe it's enough to avoid the buffer and simply delay the start of a sound. I don't know if that would be realistic enough.

What are your thoughts on how this could be implemented?

[Frostie314159]

So my idea was, just like you'd suggested, to give each positional sound a starting time and then start a second thread, that on a certain interval calculates the distance's to every object with this flag enabled. It would also check for every object if the calculated time, for when it should start playing, is greater then the system time and then plays the sound.

[Frostie314159]

I will probably commence work on this on Sunday. For now I will create a fork and a draft PR.

[Frostie314159]

I just created the fork and created the draft PR: #18. You are welcome.

[mbillingr]

For the doppler effect there is a speed of sound parameter. It would be nice if that could be used to determine the scale too.

[Frostie314159]

It probably shouldn't be used to determine the scale, rather the opposite. As far as I understand the code now just arbitrarily assumes 1v-unit=1m.

[Frostie314159]

I'm pretty sure, that this assumption will be false in 90% of cases.

[mbillingr]

Actually, most of the code does not need to make any assumptions about scale. The only place where it does matter for now is computing the doppler rate.

For a distance-based delay works similarly - twice the scale or half the speed of sound is the same thing.

Now here is where the current simple assumption starts to break down: Only the scale (but not the speed of sound) should matter for distance-based attenuation - but it doesn't (yet). In order to make that physically correctish a separate scale parameter will be needed anyway.

Sorry for the rant. In short: Right, please add a scale parameter. We'll just need to make sure it correctly interacts with the doppler effect.

[Frostie314159]

Might I suggest, that (maybe as a separate PR) we switch to using cgmath or some other lightweight vector library since it removes a lot of repetition from the code(see distance calculation).

[mbillingr]

While hesitant to add further dependencies (rodio alone is a nightmare to maintain) I'm not strictly opposed. This should go into a separate issue, though.

[Frostie314159]

Agreed