Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: allow setting thread priority for stream threads #939

Open
Sorseg opened this issue Jan 18, 2025 · 5 comments
Open

proposal: allow setting thread priority for stream threads #939

Sorseg opened this issue Jan 18, 2025 · 5 comments

Comments

@Sorseg
Copy link

Sorseg commented Jan 18, 2025

When my CPU is under high load, the sound thread does not get enough compute time, which leads to buffer underruns and clicking.
Setting high priority on sound producing threads allows producing uninterrupted sound even with a high load, but this is not straightforward with the current API.

Do we want this to be configurable?

Maybe. There might be some environments where there should be limited number of realtime threads and stuttering sound is less of a priority.

If we do want to configure the priority, what is the API?

I see two paths:

  1. add an argument to the build_input_stream
  2. add another method build_input_stream_with_priority

Thank you for maintaining this library!

@edwloef
Copy link

edwloef commented Jan 20, 2025

Maybe CPAL should always set the audio thread to realtime via something like https://github.com/mozilla/audio_thread_priority, or make this at least be an option.

@Ralith
Copy link
Contributor

Ralith commented Jan 22, 2025

This should certainly be the default when cpal spawns a thread itself. A config option should not be added unless there's a clear use case for one.

@edwloef
Copy link

edwloef commented Jan 22, 2025

Looks like this is already done on WASAPI, but not on other platforms? I'm honestly not sure.

fn boost_current_thread_priority() {
unsafe {
let thread_id = Threading::GetCurrentThreadId();
let _ = Threading::SetThreadPriority(
HANDLE(thread_id as isize),
Threading::THREAD_PRIORITY_TIME_CRITICAL,
);
}
}

@Sorseg
Copy link
Author

Sorseg commented Jan 23, 2025

I am using ALSA host, which seems to just spawn a thread

cpal/src/host/alsa/mod.rs

Lines 942 to 960 in 4a8c9b8

let stream = inner.clone();
let thread = thread::Builder::new()
.name("cpal_alsa_in".to_owned())
.spawn(move || {
input_stream_worker(
rx,
&stream,
&mut data_callback,
&mut error_callback,
timeout,
);
})
.unwrap();
Stream {
thread: Some(thread),
inner,
trigger: tx,
}
}

@Sorseg
Copy link
Author

Sorseg commented Jan 23, 2025

One issue I discovered is that at least in my Ubuntu installation, user processes do not have permission to set both nice and rtprio thread priority. Setting rtprio up to 95 is granted to the audio group, which the user does not belong by default.

unsafe { libc::nice(-5) } = -1
unsafe { *libc::__errno_location() } = 1

(1 is EPERM)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants