Description
sdrtrunk Version
master / 0.6.1 Beta 3 (and all versions before)
Describe the bug
The audio playback manager has a dedicated incoming audio queue processing thread that either stopped or never started, causing all audio to accumulate in a queue and eventually exhaust the system memory resources.
End user captured a VisualVM heap dump with the application in an excess memory consumed state which showed the inbound audio queue was full of audio segments. The thread is well-protected from errors that could cause the thread to die and all of the queues are non-blocking, so best guess is that the audio thread never started and that can only happen if the audio outputs were never configured.
The processing thread is started once the audio mixer configuration is setup. It's possible that this never happened and therefore the thread never started. Decouple the thread startup so that it is always running and use a lock to protect access to the audio outputs.
Additional context
Raspberry Pi running Linux OS
VisualVM heap dump captured by end user that shows 5.3G+ heap consumed.