Clarify the current state of stream behaviour in docs and comments

This commit is contained in:
mitchmindtree 2019-12-31 16:02:08 +01:00
parent 39ade49347
commit 2afebb2806
2 changed files with 5 additions and 2 deletions

View File

@ -27,6 +27,8 @@ use UnknownTypeOutputBuffer;
pub struct Stream {
/// The high-priority audio processing thread calling callbacks.
/// Option used for moving out in destructor.
///
/// TODO: Actually set the thread priority.
thread: Option<JoinHandle<()>>,
// Commands processed by the `run()` method that is currently running.

View File

@ -80,8 +80,9 @@
//! > given callback is called by a dedicated, high-priority thread responsible for delivering
//! > audio data to the system's audio device in a timely manner. On older platforms that only
//! > provide a blocking API (e.g. ALSA), CPAL will create a thread in order to consistently
//! > provide non-blocking behaviour. *If this is an issue for your platform or design, please
//! > share your issue and use-case with the CPAL team on the github issue tracker for
//! > provide non-blocking behaviour (currently this is a thread per stream, but this may change to
//! > use a single thread for all streams). *If this is an issue for your platform or design,
//! > please share your issue and use-case with the CPAL team on the github issue tracker for
//! > consideration.*
//!
//! In this example, we simply fill the given output buffer with zeroes.