Structs
Represents a bunch of min/max samples.
Usually copied from the MonitorProcessor thread
to the frontend if required.
The actual frontend API for the MonitorProcessor.
We start an extra thread for handling monitored signals from the
MonitorBackend, because we can’t guarantee that the UI thread
is actually started or working. Also because we want to be independent
of whether a UI is started at all.
This structure holds the output of the 6 cell inputs and outputs
that is currently being monitored by the frontend.
Implements the logic for min/maxing a single signal channel/line.
Coordinates the processing of incoming MonitorBufs.
Constants
Just some base to determine the monitor buffer sizes.
Maximum number of monitor buffers to hold in the backend.
Typically there are only 16-32ms of monitor content floating
around, as the monitor processing thread regularily
processes the monitor.
The number of audio samples over which to calculate
one min/max sample. Typically something around 750.
The length in seconds of the MONITOR_MINMAX_SAMPLES
The number of minmax samples to hold.
The sleep time of the thread that receives monitoring data
from the backend/audio thread.
It should be within the time of a frame of the UI thread for
smooth updates. The maximum is thus about 16ms.
The processing of the audio buffer is somewhere in the us
area.
3 inputs, 3 outputs of signal monitors.
Traits
A trait that represents any kind of monitorable sources
that provides at least MAX_BLOCK_SIZE samples.
Functions
Creates a pair of interconnected MonitorBackend and MonitorProcessor
instances, to be sent to different threads.
Type Definitions
Pointer type for the MonitorBuf