RustAudio
dropped frames - set scheduling priority?
On my old Windows surface, I'm hearing dropped frames even for the simple beep.rs compiled in release mode. CPU usage is kept really low as expected, so I'm thinking maybe the memory latency is the problem and the buffer size too low, but I'm a newb web guy. I'd love some help in nailing the cause down. I have not dug very much yet. As a first step I guess I should find out what backend is being used. I gather it could be either WASAPI or ALSA? I've found the buffer size to default to 441, whereas it grows to a multiple of that on frame drop. I have yet to try just copying in data instead of computing it, but tbh it's silly - it should be able to handle much more processing per frame imo. I could be conceptually off here as well though; any help is highly appreciated. My main goal atm is to just understand why this is happening and where the bottleneck is. I don't want a hacky workaround, much rather fixing the libs.
Two causes I can think of are:
- cpal uses Mutex during audio processing, which is obviously bad for realtime workload.
- We don't run the callback with elevated scheduling priority yet (planned for implementation).
Please try raising the process priority from task manager - if it makes a difference, I guess we would prioritize implementing number 2.
TYVM @ishitatsuyuki!
I'm firmly intent on testing and getting back with results, please bear with me while I long for a moment to do so!
So I think yeah, hiccups are actually a thing. The current WASAPI implementation uses the smallest buffer size the audio server supports, which is 10ms. Without priority scheduling at this buffer size it will soon start to glitch when CPU resources are contested.
:+1: I agree. Found some links for the windows side of things
The priority thing I'm referring to is MMCSS, which doesn't require elevation and has its own set of APIs. I plan to integrate this at some point.
There is a nice crate audio_thread_priority, used in firefox, implementing all the work for setting the priority.
It uses the MMCSS on windows, RealtimeKit daemon on linux and smth else on mac.
The priority thing I'm referring to is MMCSS, which doesn't require elevation and has its own set of APIs. I plan to integrate this at some point.
Any updates on this? I noticed that when you're on battery, frames start to drop because the callback takes too long with minimum processing (this doesn't happen when plugged in)
I'm using audio_thread_priority for WASAPI in https://github.com/jangler/cpal. For me it's a big improvement over THREAD_PRIORITY_TIME_CRITICAL (which is what cpal uses now for WASAPI). I haven't integrated it with other hosts since I haven't had audio thread priority issues with ALSA, JACK, or CoreAudio.
