Would it Be Possible to Make the `AudioManager` `Sync + Send`?

[zicklag]

Hey there, I just wanted to open up the discussion as far as the possibility of making the AudioManager``Sync + Send.

I thought the issue might be related to the audio backend and possibly unavoidable, but then I saw that the CpalBackend is indeed Sync + Send.

The actual issue from the Rust error message seems to be that dyn Sound and dyn Modulator aren't necessarily Sync.

Would there be a way to add a feature flag maybe that additionally restricts Sound and Modulator to be Sync maybe?

[zicklag]

I just tested adding a Sync bound and to Sound and Modulator and it looks like that works.

[tesselode]

I'm not opposed to this in principle, but why do you need this?

[zicklag]

I need to be able to put the audio manager in an ECS resource that requires Sync + Send, so that it can be accessed across multiple threads.

[jaakkojakara]

This would likely be very useful for me too. I came across this issue while trying to figure out what is the best way to share the sound system between different contexts in different threads. In my use case it would be a game engine ui thread, and a game world thread, both of which need to play sounds. A simple solution would boil down to having an Arc<AudioManager> which could be cloned and given to both, but that would require the AudioManager to be Send + Sync.

Or is it just better to use multiple AudioManagers for this kind of thing? (Should you create multiple AudioManagers, does it work?)

[tesselode]

@jaakkojakara You can create multiple AudioManagers, but they can't share any resources, like clocks or tracks. You could use Arc<AudioManager>, but you won't be able to call a lot of the methods of AudioManager because they require &mut, so you should use Arc<Mutex<AudioManager>>.

[tesselode]

Resolved in v0.8.6.