this is not a fix yet, just some comments and
code cleanup done while reading/investigating:
* limit reads to available write-space
* skip inactive tracks
* handle potential unsigned + negative value.
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.
Fixes a hack where it's transient parent was used to give an order hint
(for the order key of any new tracks).
This commit adds a new combobox "insert_at" to let the user tell us
where they want new tracks to go.
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..
In the past, we chose different defaults in homage to ardour's old mix/edit groups.
But that wasn't a very good idea.
For now they have all properties enabled and the user can disable them as-needed.
It might also be nice to make the user's property selections perist for new groups.
Summary:
* use mmap() for the whole peakfile instead of lots of small seek/reads
* cache the computed peaks
* where possible, open files with O_NOATIME.
not quite sure how -fomit-frame-pointer can make a difference with 64bit
builds, but it does crash on start in
gdk_window_new -> .. -> [NSColor _controlColor] -> GetThemeImage
-> _NSAppKitThemeLock with no other threads involved.
full backtrace: http://pastebin.com/FxsCMzSY
