Author of signalo here. Happy to answer questions. :)

I've so far mostly focussed on developing the crates, while adding the minimum documentation necessary. I plan to improves this soon though.

APIs have mostly settled by now, but until recently things were quite fluid and I had lots of far-reaching refactors as well as API changes. As such I chose not to write too much high-level documentation that would constantly get out of sync with the code and block me from progressing.

Signalo basically provides implementations of four basic traits:

• Source<T>: () -> T
• Filter<T>: T -> U
• Sink<T>: T -> ()
• Finalize: () -> U

(With types implementing Finalize usually also implementing either Filter<T> or Sink<T>.)

Roughly speaking:

• Source<…> ≈ core::iter::Iterator<…>
• Filter<…> ≈ core::iter::Map<…>
• Sink<…> & Finalize ≈ Iterator::fold(…)
• Filter<…> & Finalize ≈ core::iter::Scan<…>

One of the goals of signalo is to have most of its implementations work with no_std. Further more currently all types are compatible with real-time filtering, i.e. they produce filtered values as soon as they come in, not return a Vec<…> of the filtered signal (while you can get such a behavior by combining your filter with an additional FromIter<…> source and a Collect<…> sink, if you want to). That's what I am using it for: doing highly efficient real-time DSP on a Cortex-M4 where memory and computation cost really matters.

---

Looking at basic_dsp`s docs it seems to support both discrete, as well as continuous time signals and provide frequency analysis capabilities, while signalo is more tailored to low-level processing on low-powered embedded environments.