proposal: allow setting thread priority for stream threads

[Sorseg]

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]

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]

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]

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

cpal/src/host/wasapi/stream.rs

Lines 325 to 334 in 4a8c9b8

	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]

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]

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)

[jangler]

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

In a way it is, but I get much more reliable WASAPI performance using the audio_thread_priority crate than with THREAD_PRIORITY_TIME_CRITICAL.

[est31]

Done in #955