27 lines
1 KiB
Markdown
27 lines
1 KiB
Markdown
|
# Audio engine requirements
|
||
|
|
|
||
|
|
## Real-time callback rules
|
||
|
|
|
||
|
|
The callback must not allocate/free memory, lock blocking mutexes, perform
|
||
|
|
filesystem/network/console I/O, log, load plugins or samples, call GUI APIs,
|
||
|
|
or wait for another thread.
|
||
|
|
|
||
|
|
Use preallocated buffers and bounded work. Publish parameter and graph changes
|
||
|
|
through a documented real-time-safe mechanism. Verify atomics are lock-free
|
||
|
|
where required on the target platform.
|
||
|
|
|
||
|
|
## Processing model
|
||
|
|
|
||
|
|
Process a bounded number of frames per block. Do not assume a fixed block size
|
||
|
|
unless the backend guarantees it. Define maximum frame and event counts and
|
||
|
|
safe behavior when those limits are reached.
|
||
|
|
|
||
|
|
The initial milestone is offline processing, then a test oscillator -> gain ->
|
||
|
|
meter/output graph, then a hardware backend.
|
||
|
|
|
||
|
|
## Clock and transport
|
||
|
|
|
||
|
|
Audio sample position is the authoritative playback clock. Use integer or
|
||
|
|
rational timeline representations to avoid cumulative floating-point drift.
|
||
|
|
Define tempo-map conversion and behavior at tempo changes before implementing
|
||
|
|
tempo automation.
|