The values in mach_timebase_info_data_t should be specified in terms of
'ticks'. On some machines, ticks may correspond to nanoseconds, but this
is not guaranteed.
Previously, if `stopTimer()` was called from within
`hiResTimerCallback()`, a call to `isTimerRunning()` immediately
following the call to `stopTimer()` would return true instead of false.
This patch fixes the issue, and adds some tests to verify the new
behaviour.
In very optimised builds, SHCore.dll may not be automatically loaded
into the address space of the calling executable. In these cases, the
call to `GetModuleHandle` will fail. Adding the call to LoadLibrary
ensures that the dll is loaded into the program's address space, which
will allow the call to GetModuleHandle to succeed.
Previously, if `loadImpulseResponse` was called before `prepareToPlay`,
the IR wasn't guaranteed to have loaded before the first call to
`processSamples`.
Now, we flush the queue of pending IR-load commands during
`prepareToPlay`, which should ensure that the most recently-loaded IR is
ready to use immediately.
The default main JuceActivity for JUCE apps calls appNewIntent() in its onNewIntent() implementation which is defined in juce_gui_extra. This commit moves the implementation into juce_gui_basics.
If an aiff file advertied a large number of metadata keys, the
StringPairArray::set calls resulted in quadratic complexity.
We now read keys into a std::map instead, as it enables much faster
lookup, and then convert back to a StringPairArray at the last possible
moment.
Previously we relied on Foundation.framework being implicitly linked by other frameworks, but this change is required when building with Xcode 12 targeting older macOS versions to fix missing CFNetwork symbols.
We use a manual-reset event rather than an auto-reset event to cancel IO
on the pipe. This avoids unlucky cases where new IO would start just
after signalling the event and would block indefinitely while waiting on
the newly-unsignalled event.
As far as I can tell, if a read was cancelled from a background thread,
the IO operation wasn't cancelled, so the system was poking at the
stack-allocated OVERLAPPED structure after it had been removed from the
stack, at which point something else might be occupying that region of
stack memory.
I'm pretty sure Address Sanitizer should be able to catch this sort of
thing so I'm surprised it didn't complain here.
