Cleaned up and improved the audio tab.
Fixes#1546. Kind of. There doesn't seem to be much need for a
sample rate selection for our current high-level audio system.
If we implement higher end audio backends in the future (e.g.
ASIO, JACK), those can be given a sample rate setting.
The macro defined namespaces confused the hell out of lupdate and more or less broke translations permanently. Looks like the only way we can do it is to have a hardcoded namespace, which goes against my instinct, but honestly how likely is it that we'll change the namespace anyway (I guess forks might want to do it, but that's their problem ;) )
macOS audio playback failed due to audio being processed in the main thread.
Now all audio playback has been placed into its own high priority thread to
always keep up better with the operating system's demands.
This system was kind of janky anyway. It makes more sense ultimately for the
audio management classes to contain the file handle rather than the renderer.
Fixes a number of playback stuttering and general UI lag issues by setting all
background tasks to IdlePriority rather than LowPriority. While it was assumed
LowPriority tasks would always get scheduled below NormalPriority (e.g. main
thread) tasks, it turns out this is not always the case. If the background tasks
start consuming a lot of CPU cycles, the scheduler may use "dynamic scheduling"
to schedule them above the main thread regardless leading to UI lag. This is
apparently the case for all thread priorities apart from IdlePriority, which
is allegedly a special case where threads are *only* scheduled when other
threads aren't busy ensuring the main thread stays responsive.
Implementation isn't perfect yet, viewer/renderer doesn't update yet when
the preference is changed so a sequence needs to be re-opened for the change to
take effect.
Previously the audio output manager was a "hybrid device" that acted as a pull
device for audio devices and as a push device and device proxy for the rest of
the application. This approach turned out to be flawed, particularly in the
frequent opening and closing of the audio device (extremely slow). Since we
use both pulling (for constant playback) and pushing (audio scrubbing, short
bursts of sound), it needed a similar but different approach. This approach
will switch the output device from push mode (default) to pull mode (during
playback) only when necessary resulting in far less UI lag (basically
unnoticeable now) than the previous approach.
luzpaz