Age | Commit message (Collapse) | Author |
|
|
|
The disk-reader assumes that all playback ringbuffers are in sync
and have the same fill_level.
|
|
|
|
|
|
|
|
|
|
Since ead883302fe800ae, it is no longer possible to use a null
pointer SessionEvent::track as flag to indicate overriding all
buffers.
|
|
|
|
|
|
|
|
|
|
|
|
pre-export
|
|
transport work
|
|
This apparently happens on some Windows systems when exporting
a range starting at 00:00:00:00
I'm still hoping there's a better fix for these race-condition
issues, perhaps by kicking the TFSM...
|
|
This reverts commit c5332ddd0092c3a73315923a90c41024c0ad7758.
Apparently this is not needed 4f3a95a1da is sufficient.
|
|
|
|
See also
* 4f3a95a1da9
* cfd95340b18
* 61e7f3176bf
|
|
This picks up where cfd95340b1 left off.
The goal is to ensure that the butler has completed all
PostTransportStop related tasks and won't meddle with transport
after exporting has started.
Previously this could happen, because realtime_stop() queues
PostTransportStop and the butler is sommoned after every
export process cycle.
Since 61e7f3176bf the butler keeps calling non_realtime_stop()
every time it is woken up, until TFSM comes around and unsets the
flag in the process callback.
|
|
|
|
name (not the new one)
|
|
This cuts reverb tails and synth sounds after export.
Disabling freewheeling, continues normal processing where
export left off. This previously kept notes ringing, or reverbs
audible.
|
|
|
|
|
|
The actual issue was introduced in 61e7f3176bfd8e:
Session::non_realtime_stop() no longer unsets PostTransportStop
(other changes from that commit are not relevant).
The real issue however is a race-condition.
So far this only seems to happen on MacOS, Coreaudio.
It seems that non_realtime_stop() is called in the butler-thread
after exporting has started, even though the butler has been
paused in wait_until_finished().
Perhaps Coreaudio thread switches causes TransportFSM to
reinitialize and scheduling the butler?
The use of `usleep()` makes this rather a workaround.
However it's sufficient for the coreaudio rt thread to run
at least once.
|
|
|
|
|
|
This reverts commit a13ef36b3b6212d1ae0c563c7a60a86152dbb48f.
A better fix is coming.
|
|
|
|
A port can callback from its destructor, which if occuring inside the backend destructor
would reach an already partially destructed backend.
|
|
Amend 648beb94. If initial re-fill happens via override buffers,
the buffer may still be effectively empty.
|
|
|
|
|
|
Port (or Tracks) can be safely added during playback, however
the disk-reader's playback buffer is initially empty. This lead to
false-positive Underrun() signals when processing takes place
before or concurrently with re-filling the disk-buffer for the new
channels.
Now new empty buffers are ignored, and produce silence until the
initial refill is complete. There is however no per-channel
de-click in, yet.
This fixes: play some audio track, ctrl+drag a region to the
drop-zone, creating a new track while playing.
|
|
|
|
|
|
|
|
|
|
|
|
JACK is not yet finished.
Changes also include minor reformatting and a spelling correction (latecies to latencies)
|
|
|
|
|
|
|
|
Ignore latency of async ports (Virtual Keyboard in particular),
and only consider ardour's own ports.
|
|
|
|
|
|
Only compare playback latency, delaylines in tracks do not
push back the capture latency to the source.
The delayline on tracks sits in between disk-writer and disk-reader,
delaying input to align with the disk-reader.
Furthermore tracks may be connected to different inputs,
even though those inputs are usually from the same hardware
device, capture latency of those ports can differ.
|
|
|
|
|
|
|