Check timer for invalid frequency
Precalculate timer tick rate to save a few instructions
Don't use static variables inside functions to avoid checking for initialization
Use static functions inside anonymous namespace for internal linkage
I'm not sure if this test is going to be effective as I don't have hardware to
test on at the moment. As noted in the documentation, Windows XP should be the
only OS where QPC uses a timer source that is non-monotonic(multi-core with
non-syncronized TSC).
timeEndPeriod must be called with the same timer resolution value used in
timeBeginPeriod. When the process exits the timer resolution is restored anyway
so this is not very important.
I put these in libpbd as that is where the debug bits are for the Waves backend
but I think it makes more sense for them to be in libardour as that is where
the AudioBackend class is defined
I left the Waves debug bits in libpbd for now.
Rename it get_win_special_folder_path to indicate what it is returning
Move documentation for the function into the header and use doxygen style
comments.
Fixes a couple of memory leaks in ArdourVideoToolPaths class although it looks
as if there are more.
Added AVX versions of existing 5 SSE functions. Added 6th AVX function to copy vectors which is 1.5 times faster then memcpy.
Data consistency and validness is fully tested after processing with new AVX functions on aligned and non aligned buffers.
This breaks the build for windows builds that don't use the pthreads_win32
library. Using the opaque pthread_t type like this is probably not a great
idea. Using PBD::pthread_name is another option that I've used elsewhere
that seems more useful.
For some backends the process thread can change (e.g.
switch coreaudio headphone + internal speakers)
If there are existing x-thread event calls this can lead to
the following situation:
1) SessionEvent::operator new
2) audioengine process thread change
3) SessionEvent::operator delete -> crash, wrong thread
SessionEvent::operator delete can safely push the event back to
the pool for later cleanup..
Expanded API splits apart some CrossThreadPool functionality, and provides
access to current pool status information (available(), total(), used(), pending_size())
These changes are MSVC specific and shouldn't affect the other builds.
(incidentally, libpbd already offers a function called 'fast_log2()'. Not sure if that could have been used instead...)
