Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
6.9
Description
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)
Attachments
Issue Links
- relates to
-
QTBUG-128256 Spatial Audio relatively high latency in QtQuick3D.Xr
- Reported
-
QTBUG-128181 [macOS] QAudioSink chooses a default buffer size that's too small, causes buffer underruns
- Closed
-
QTBUG-43690 QAudioOutput should pull data in its own Thread
- Closed