xruns on script change; parameter handling performance #1525
Description
audio xruns occur every time a script is loaded.
its difficult to directly determine which jack client is stalling since they all have interconnected I/O and need to wait for each other. so before investigating i would just guess that the softcut and/or crone clients are stalled while handling large queues of commands.
design recap:
- parameter changes / actions are implemented as a lockfree, SPSC queue of "command" packets. (one queue per client.)
- the producer is the OSC server thread (in v2; in v3 it will be i guess the lua main thread but that's something to nail down.)
- the consumer is the audio thread.
- each client attempts to pop its entire command queue at the start of each audio block.
this last behavior is what makes the system susceptible to stalls on the audio thread. popping and dispatching a command is fast and the handlers are as small as possible, but some are inevitably heavier than others and all the efforts by the norns lua system to reset things to a known state mean that many, many commands can be placed in the queue at once when a new script is loaded.
some initial random ideas, broadly:
-
a control block size should be implemented for jack clients regardless: smaller than audio block size, larger than 1 sample.
-
command q processing time could be "amortized" between successive control/audio blocks. this has downsides...
-
considering a system allowing blocks of commands to be executed while the client is in a silenced/bypassed state. i think i like this idea for all sorts of reasons, but it's complicated