Clarify the current state of stream behaviour in docs and comments
This commit is contained in:
parent
39ade49347
commit
2afebb2806
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
Loading…
Reference in New Issue