Skip to main content
This page is the cross-SDK configuration overview for streaming inference: when to stream, chunk sizes, aggregation policy, and quality gates.
For implementation APIs:

​
Streaming vs Batch

Use batch inference when full trials are already available and you are doing offline evaluation, model validation, or analytics. Use streaming inference when embedding or feature chunks arrive over time and the application needs low-latency updates before a complete trial has finished.

​
Core Configuration

Every streaming setup needs:
  • sampling_rate: acquisition rate in Hz.
  • chunk_size: number of samples per chunk.
  • paradigm: task type such as motor imagery, P300, or SSVEP.
  • feature_type: feature representation such as CSP, bandpower, or ERP amplitude.
  • n_features: feature count per chunk.
  • n_classes: number of output classes.
  • temporal_aggregation: how to reduce feature time structure when required.

​
Chunk Size Guidelines

Start with 0.5-1.0s chunks for motor imagery and adjust based on confidence, latency, and user experience.

​
Aggregation Methods

Streaming produces one posterior per chunk. Trial-level decisions combine those chunk posteriors.
Start with weighted_vote. Use posterior_mean for smoother probabilities, or max_confidence when the task has short high-signal windows.

​
Quality Gates

Streaming systems should monitor:
  • confidence (max posterior probability)
  • entropy (prediction uncertainty)
  • class balance over recent trials
  • rejection rate
  • per-chunk and per-trial latency
For Python rejection and quality APIs, see Python SDK API Reference. For end-to-end real-time setup, see Real-Time BCI Setup.

​
Next read

Python Streaming Inference

Python StreamingSession API and STS state handling

Julia Streaming Inference

Julia streaming API for local chunk processing

Real-Time BCI Setup

Hardware, LSL, BrainFlow, and acquisition loops

Batch Processing

Offline trial processing and diagnostics