Hopefully this resolves glitches on hyperthreading machines.
Apart from using unnamed Semaphores, pthread-w32 includes additional locks
(guess: mem-barriers), a fallback implementation and windows-specific
tricks that I'd rather not want to know about :)
For drivers that correctly report latency values(ASIO) this should result a
much closer alignment of audio in a loopback test. Measurement and
adjustment may still be needed, especially for non-ASIO drivers.
Testing with the RME HDSP Multiface and Yamaha AG06 using ASIO drivers results
in maximum offset of a couple of samples.
This does involve nagivating some really gnarly menus, which is unfortunate, but we don't have a good general
solution for this yet (it is fundamentally the same problem that affects the key binding editor and Mackie support
Rename run-session-tests.sh script to load-save-session.sh and make it operate on
only a single session and add a separate load-save-session-collection.sh script
Add --massif option to load-save-session.sh script
Rename some poorly named variables and add some documentation to the
load-save-session.sh script
well, now...
- Midi-Ports have a midi-buffer.
- Midi-Tracks have a midi-buffer.
- Midi-tracks have a diskstream.
- Midi-diskstream has a midi-ring-buffer.
- Midi-tracks have a delivery
- The delivery can get a reference to the actual backend-ports
- The delivery calls the Midi-Port's flush() buffer to send out queued events
at the end of a cycle
all clear ? :)
- when splitting the process-cycle: only the Ports are informed.
all other objects see a "normal" short process cycle starting at "0".
The offset needs to be applied early on, so that internally routed buffers
push the event at the correct time when combining the buffer with
immediate and async events.
Luckily Port::port_offset() is a static member, available to all, objects,
which allows to bridge the conceptual gap between the diskstream and
the delivery.
There's a snag:
When there's a note-on directly at the beginning of the loop it coincides
with the panic message sent when looping.
The panic comes before note events, so it *should* be good.
Also the final note-offs (state tracker end of loop/region) are sent
1 sample too early (smells like an off-by-one), and are hence dropped.
(no matter we send a panic right after it).
It should really be at the same time, just before the panic.
