tesselode / kira

Library for expressive game audio.
https://crates.io/crates/kira
Apache License 2.0
855 stars 43 forks source link

Remove command delay #70

Closed zeozeozeo closed 10 months ago

zeozeozeo commented 10 months ago

Fixes command delay by processing pending commands for each audio frame. Fixes https://github.com/tesselode/kira/issues/65 (and includes https://github.com/tesselode/kira/pull/69) This will fix issues such as volume commands not applying immediately and will remove the delay between the stream.play() call and the actual sound being played.

This shouldn't add much overhead (I haven't benchmarked it though). You can pass the process_command_interval option to set the amount of audio frames between on_start_processing calls. Currently set to 1 (NonZeroUsize), but it might be better to increase that value (needs benchmarking).

tesselode commented 10 months ago

Do you have a way to test the delay between the gameplay thread sending commands and the audio thread receiving them?

zeozeozeo commented 10 months ago

Do you have a way to test the delay between the gameplay thread sending commands and the audio thread receiving them?

I thought the command list was something like a vector under a Mutex, so it should have no delay between updating in the audio thread? I would think that the only delay that could be present is because that Kira only processes the command list once before it starts rendering the audio samples, so the next command is only processed in the next buffer given by cpal, which only starts processing when the previous buffer starts playing. This pull request will update the command list for every 1+ audio samples, so the commands that are added while a buffer is being filled are applied immediately. I can probably write a small program to test the delay tomorrow.

tesselode commented 10 months ago

I think you're going to find that your change doesn't change the latency much, since Kira processes all the samples in a buffer as fast as possible, so unless those samples are very CPU-intensive, they're all going to process in a short period of time, and then the thread will sleep until the next buffer period.

zeozeozeo commented 10 months ago

yeah, you're right, not sure how i didn't think about that