Require `&mut self` for stream state controls

[LastExceed]

Allowing .start() / .pause() / .stop() to be called simultaneously by different threads seems like an anti-pattern, as it inevitably requires synchronization under the hood. .buffer_size() and .now() should be fine to stay as they are.

Note that this is does not affect the Send + Sync bound

[roderickvd]

Interesting. I think you've got a point, though for a different reason than "operating a stream from several threads is an anti-pattern". I can think of some use cases for that, like UI, audio and network threads all toggling play/pause, or a Ctrl-C handler stopping a stream. Arguably, though, an application should route those through one worker thread that receives commands.

The one-worker-model may be desirable because cpal currently:

• does not expose the stream state, so other threads can't reliably know it without extra plumbing
• can end up in an inconsistent state when start/pause/stop run concurrently, since some backends don't lock the whole sequence of steps

[LastExceed]

A one-worker-model seems needlessly restrictive:

an application should route those through one worker thread that receives commands

Or just wrap the stream handle in a mutex/rwlock

cpal currently does not expose the stream state, so other threads can't reliably know it without extra plumbing

Maybe we should change that then, adding a function to StreamTrait that returns the current state seems intuitive to me

inconsistent state when start/pause/stop run concurrently

That is precisely why I think it is an anti-pattern. Dealing with this problem in #1331 is what led me to creating this issue

[roderickvd]

A one-worker-model seems needlessly restrictive:

Sure, I was talking in the context of multi-thread stream operations.

cpal currently does not expose the stream state, so other threads can't reliably know it without extra plumbing

Maybe we should change that then, adding a function to StreamTrait that returns the current state seems intuitive to me

I agree.