Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xruns on script change; parameter handling performance #1525

Open
catfact opened this issue Mar 12, 2022 · 1 comment
Open

xruns on script change; parameter handling performance #1525

catfact opened this issue Mar 12, 2022 · 1 comment

Comments

@catfact
Copy link
Collaborator

catfact commented Mar 12, 2022

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

@catfact
Copy link
Collaborator Author

catfact commented Mar 12, 2022

this branch adds _norns.mixer_commands_enabled and _norns.softcut_commands_enabled for testing, each taking an integer argument (>0 to enable.)

when disabled, audio thread doesnt pop or dispatch commands for that client. (they are still pushed though, until the queue fills up.)

when disabled, i see a lot fewer xruns. still a few. these seem to be from SC...? i suppose engine cleanup can be aribitrarily heavy.

@catfact catfact removed their assignment Jan 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant