CommandQueue full error

[cybersoulK]

self.spatial_scene.add_emitter(position, emitter_settings)

I am getting a ton of CommandQueue full errors. i have about 10 sounds of 20 seconds length playing. Is there some kind of limit to the emitter?

ps: i am reusing the same StaticSoundData if that matters

[NiklasEi]

You can try to increase the capacities in your AudioManagerSettings.

[cybersoulK]

ah! so it's there. I wonder why it's queuing 128 in command_capacity?

I do this for maximum 10 sounds every frame (120 fps)

sound_handle.set_volume(...); emitter.set_position(...);

[cybersoulK]

ok, i found the issue, i am calling the following a lot, for no reason: sound_handle.stop(..);

[cybersoulK]

i am reopening because i am getting consistent CommandQueue Errors when connecting to headphones in the mac (bluetooth or wired).

When the device connects, is there something inside kira that triggers a bunch of commands? I already do:

let mut audio_settings = AudioManagerSettings::default();
audio_settings.capacities.command_capacity *= 4;

and i don't have anything in my app that responds to new devices being added

ps: i am using the 3d emitters if that matters.

[tesselode]

@cybersoulK my guess is that the command queue gets filled up while the audio device reconnects, since nothing consumes the messages from the gameplay thread to the audio thread in that time. I'd recommend not setting volumes and emitter positions every frame - maybe every 100ms or so? Or you can just ignore the errors - once the command queue gets emptied out you should be able to set volumes and emitter positions again without any issue.

[cybersoulK]

That's likely the reason!

Is there a big cost to pay for setting the position of each emitter every frame? And is the command buffer a hardware limit?

Even if i ignore error in positions and volumes, there are other parts that might error such as playing/stoping sounds, once it gets full.

And if i ignore everything, sounds will not play while they should, which is very evident for very long sounds. Or that or i would need to build a systems on top of kira to cache play/stop instructions and retried them if failed, which is unnecessarily complex.

[tesselode]

The length of the command buffer is determined by the Capacities you pass into AudioManager::new. You said you multiplied the length of the buffer by 4, so you'd end up with a length of 512 commands. Setting an emitter position is 1 command, so I can see that getting filled up pretty quickly if you're updating multiple emitters 120 times per second and the audio device gets disconnected.

There are a couple of things that could change in Kira to address your concerns:

1. The command queue could automatically grow as needed. I don't know how to implement this, but I believe oddio does something like that, so it must be possible. The downside is you may end up allocating more memory than you were expecting in cases like audio device disconnection.
2. Emitter positions could be set by changing an atomic value. This would mean it doesn't need to send a command through the command queue, but you wouldn't be able to specify a tween each time you set the position. This may be a worthwhile tradeoff if it's an important use case to update emitter positions every frame.