sound_rs v0.2.2

11 · Reference

Guarantees

A library is trustworthy when its promises are written down and tested. This is the list, and the ones that are deliberately not on it.

Errors

Every failure is sound_rs.SoundRsError (a RuntimeError) with a stable .code:

CodeMeaning
ioThe file could not be opened or read.
formatThe container or codec was not understood, or no audio was decodable.
deviceNo output/input device, or the device refused to open.
stalledPlayback made no progress for two seconds; the device probably disappeared.
unsupportedThe build lacks a feature (NumPy) or hit a documented limit.
usageThe call order was wrong, for example feed() before begin_feed().

Codes are part of the API: renaming one is a breaking change.

No panics on bad input

Corrupt files return an error, they do not abort the interpreter. This is enforced in cargo test by mutating every committed fixture ~200 times per file (bit flips, truncation, appended noise) and by feeding random bytes; every case must return Ok with finite samples or a non-empty error.

Threads and the GIL

Determinism

Decoding is deterministic: the same file produces the same float32 samples on every run. Across CPUs the integer decoder's SIMD paths can differ by a bit, so the regression hashes are taken at 10⁻⁴ (about three LSB at 16-bit scale). tests/decode_regression.py pins a SHA-256 of the PCM for five fixtures; a decoder change that moves a single sample fails CI.

Memory

Audio quality

What is not promised