Closed zeozeozeo closed 10 months ago
Do you have a way to test the delay between the gameplay thread sending commands and the audio thread receiving them?
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.
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.
yeah, you're right, not sure how i didn't think about that
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 betweenon_start_processing
calls. Currently set to 1 (NonZeroUsize), but it might be better to increase that value (needs benchmarking).