search

tesselode / kira

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

Add a way to check the number of commands in the command queue, and to clear the command queue #13

Closed Bombfuse closed 3 years ago

Bombfuse commented 3 years ago

Currently having issues with commands seemingly getting stuck in the command queue because I'm seeing that it's getting full and crashing because of it. I'd like to be able to see how many commands are in queue at any point so that I can debug when/where the commands are getting stuck.

Is there a clean way to add this capability?

tesselode commented 3 years ago

Commands shouldn't get "stuck" ... at maximum, it should take one OS-audio-buffer-length for a command to be received by the audio thread. On my machine that's about 10ms. Are you starting a lot of sounds or using a lot of sequences at the same time? If so, you probably just need to increase the command capacity using AudioManagerSettings::num_commands.

Bombfuse commented 3 years ago

This is a good point, I did some more debugging and realized that it's because when I reset the volume in my engine, it iterates over all of the instances I've stored and resets all of their volumes, which overloads the command queue. I added a check to see if the instances state is InstanceState::Stopped but all of the instances act like they're still playing even though they aren't. I drop the instances from the HashMap if they're stopped, but because none of them ever say they're stopped it just keeps growing until the hashmap is larger than the command queue, which breaks when I iterate over them to set their volume. I'll do some more debugging today.

Bombfuse commented 3 years ago

Did some more testing, it seems the issue of the instances play state not being updated only happens when you play a large amount of the same sound at once. When playing only one instance of the same sound per frame, the instance states are updated properly and I can prune the stopped instances from my engine. This is such a niche bug that it probably doesn't need addressed, as I only discovered it under heavy load testing.

tesselode commented 3 years ago

By default, there's a cooldown after playing an instance before you can play it again. Right now, it'll silently not play the instance if the sound is still on cooldown - the library could probably use some better messaging when that happens.

I'm not really sure what this has to do with your command queue issue though...

Bombfuse commented 3 years ago

It was never a command queue issue, I just misunderstood the bug I was having at first. The real issue was that I had instances stored that constantly thought they were playing