Callback priorities

Since libDaisy accesses the underlying ST HAL I’m wondering how the priorities of callbacks are configured. Jobs like ADC-sampling feature default callbacks in the ST HAL and I’m guessing that the callback registration functions by libDaisy access these. They are usually configured as interrupts as far as I know, and these have priorities in the NVIC.

libDaisy seems to handle callback registrations the same way for both sampling in regular time intervals and async events like incoming messages from a host in case the Seed acts as USB CDC device. While I understand and appreciate the simplicity, I wonder why callback functions generally look like

<peripheral>.setCallback(function_pointer, data_pointer)

instead of

<peripheral>.setCallback(function_pointer, data_pointer, priority)

This way, all sorts of “stalling” issues could be easily avoided by the user, at least as far as I understand. Is there a function in the middleware or HAL that lets the user set the priority for the interrupt associated with the corresponding callback trigger? Maybe relevance is best explained by an example:

The Seed acts as a continuous audio sampler and filter for an arbitrary effect/instrument/whatever. It also acts as a USB CDC device which can be plugged into a host machine, where presets can be uploaded. In such a case, incoming data triggers the callback given in seed.usb_handle.SetReceiveCallback() (an aperiodic event unlike sampling of audio). If the cost of processing is high, the USB CDC callback is never triggered, because the audio/processing callback starves everything else. In a case with priorities, the USB CDC callback would get a higher one, instantly disabling the audio callback.

Any suggestions on this?

Are there any real-world examples of ‘all sorts of “stalling” issues’ using libDaisy?