Fix #122

[voidentente]

This is how I'd solve this. It uses locking, necessarily, but I made sure the lock isn't held for longer than necessary. It uses a secondary buffer to minimize this time and reuse allocations.

I didn't use a channel because this is polling behavior, and we don't need blocking i.e. notifiers etc.

[tesselode]

I might be OK with the non-realtime-safe code if the error rate was always low, but considering you were getting "errors" from JACK every time the buffer size changed, I'm not confident about that. I think I'd be more comfortable with the fixed ringbuffer + an atomic counter of how many errors were discarded.

[voidentente]

Got it :)

[tesselode]

Can you add a way to get the errors from the main thread?

[voidentente]

Can you add a way to get the errors from the main thread?

All StreamErrors or only BackendSpecificError?

EDIT: I assume by "main thread" you mean the AudioManager via a method on CpalBackend accessible via backend_mut. Exposing the errors also might create uncertainty about which errors Kira has already handled.

[voidentente]

There are two separate ringbuffers, one for internal use by kira (unhandled) and one for external use (handled). It wouldn't make sense to have the external use transport be unbounded, since it's likely that most applications won't poll kira for backend errors, thus inflating memory usage.

It might also make sense to invert the public-facing ringbuffer to only store the latest errors, not the oldest ones. I'm ambivalent to this policy, but I just wanted to point that out.

The Mutex is only there to make it Sync, it's not actually used for locking, similar to cpu_usage_consumer.