I figured out where the extra CPU was coming from in my previous PR (#10) with threadpools: an active rodio::OutputStream will constantly service callback requests for data from CoreAudio, and the more threads that have an active context, the more CPU usage we'll use. So to tackle that:
I found that the threadpool (with more than one thread) was unnecessary in the first place, because using rodio::Sinks enables queuing up multiple sounds on a single OutputStream.
In addition, because CoreAudio itself uses a lot of CPU when you have any contexts open at a single time, then I implemented logic to terminate the worker thread (and discard it's rodio context) after 20 seconds of inactivity and start it up again fresh the next time the user pushes a key.
I figured out where the extra CPU was coming from in my previous PR (#10) with threadpools: an active
rodio::OutputStream
will constantly service callback requests for data from CoreAudio, and the more threads that have an active context, the more CPU usage we'll use. So to tackle that:rodio::Sink
s enables queuing up multiple sounds on a singleOutputStream
.CoreAudio
itself uses a lot of CPU when you have any contexts open at a single time, then I implemented logic to terminate the worker thread (and discard it's rodio context) after 20 seconds of inactivity and start it up again fresh the next time the user pushes a key.