QtMultimedia's audio io classes are expecting audio IO to be done via a QIODevice living on the application thread. Doing audio on the application thread has significant limitations: if the application thread is not fast enough to feed data to the driver (or consume data from the driver), there well be buffer overruns/underruns potentially causing audio glitches/dropouts.

• if the audio buffer size too small (as a rule of thumb: smaller than the expected duration for the QApplication event loop to block), there will be dropouts
• if the audio buffer size is too large, there will be a perceived latency between user input and audio being played back by the audio device.

notes:

• some backends do audio io directly on the application thread, while others (most notably coreaudio) use a worker thread and a ringbuffer between application and audio thread.
• audio worker threads should run at a higher priority than the application thread, as they are have (soft-)realtime constraints (coreaudio sets up thread priority / audio workgroup automatically, as the worker thread is owned by coreaudio)
• all operations on the audio worker threads should ideally be non-blocking. most notably, no blocking writes, no waiting on mutexes or other synchronisation structures, no memory allocations (technically, even printf is not allowed)