After preliminary testing for UNDERRUN errors, I have determined that there is a direct/indirect relationship between:
The way the library works should give an insight into whats happening here.
Firstly the block size determines how often the audio chain runs (this is triggered typically from an interrupt from either the input or output devices - the system picks just one device to be the trigger). If you don't include at least one device that's interrupt driven the audio chain never runs at all, a common cause of confusion.
Its vital the audio system completes it processing before the next trigger interrupt is due, so having a smaller block size can cause issues if other, higher priority, interrupts are using a significant amount of time. Thus larger blocks can avoid this problem, as can ensuring high priority interrupts only take a few microseconds (good practice). The audio chain drops its interrupt priority to minimum to play nicely with other ISRs.
Also larger blocks mean the processing is more efficient, as the setup/teardown around the block processing is amortized over more samples. Thus the total processor cycles used with a block size of 16 might be a lot more than with 128, leading to processor saturation (and dropped blocks/clicking/buzzing or worse). Block size is a compromise between efficiency and latency.
However larger blocks will require more audio memory to be used, note.
Clicking or buzzing is usually because you've run out of processor cycles, you haven't declared enough audio memory and the system is starved of blocks, or you've monkeyed with the order of declaration of the audio objects from that auto-generated by the audio tool and created unwanted block delays where they aren't needed or desirable.
You should declare objects after their sources and before their destinations as much as possible. Any signal travelling the other way will force a block delay and a extra block needs to be available to hold that data between triggerings of the audio chain. The audio tool handles generating an efficient order of creation of the audio objects for you.
And one final thing, the sigma-delta style DAC and ADC typically used for audio have a lot of latency built-in, often dozens of samples - they are not the devices to chose for a real-time signal processing system - SAR ADCs and fast DACs are needed for rapid response, as these each have a latency of less than one sample time.