It would be completely shut down.
With the stock code, when the CPU usage is 60% at 2 samples per block, the CPU is in theory busy for approx 48 us in the audio thread, which then goes to sleep and the CPU is fre for linux processing for 32us. When it is time for the audio thread to start running, it doesn't start immediately, rather it takes it some non-zero time to wake up. This time can be more than 20us, and sometimes it is in excess of 40us, which is why you get occasional dropouts.
The fix above prevents the audio thread from sleeping altogether, which means it never relinquishes the CPU to Linux and so it never wakes up late and it never drops out. The downside is that it never leaves any CPU time to Linux and nothing else than the audio thread will ever run on the CPU. That will not allow it to run any UDP transmission, however slow.
Maybe you need a mix of sleeping and then busy wait, which, if finely tuned, may give Linux just enough time to be able to send minimal amount of data over the network. You could try in PRU.cpp to modify these lines:
// Poll
while(pru_buffer_comm[PRU_COMM_CURRENT_BUFFER] == lastPRUBuffer && !Bela_stopRequested()) {
so that you sleep before the busy wait:
// Poll
task_sleep_ns(5000);
while(pru_buffer_comm[PRU_COMM_CURRENT_BUFFER] == lastPRUBuffer && !Bela_stopRequested()) {
The sleep time is expressed in nanoseconds. Start at 5000 and see if you can increase it before dropouts start to appear. Once they start to appear, decrease it back to a point where they stop. At that point, try running a UDP sending task in a dedicated thread with SCHED_FIFO and priority > 0 and < 95 (e.g.: via a Bela AuxiliaryTask). This may be good enough.
A more advanced solution would read the current time (see Bela_gettime()) as soon as the audio thread goes past this busy loop and then try to determine once it's done how long to sleep for before the busy wait, or whether to sleep at all, but this is more compilcated.
