various latencies, was Re: [Rosegarden-devel] these timing problems

[Chris C. <ca...@al...>]

On Wednesday 10 Dec 2003 5:26 pm, Richard Bown wrote:
> The fetch latency is how much time it takes us to
> assemble the new set of events from the composition to send to ALSA
> - used to be much more prevalent when we actually used DCOP

Well this is what we appear to be doing at the moment, for each 
timeslice.  The "magic" values involved are fetch latency, play 
latency, and read-ahead.  The "position" refers to the time within 
the composition, ignoring latency.

 * Loop around updating the position according to the external time on 
the ALSA queue.  (RosegardenSequencerApp::updateClocks)

 * Wait until the position reaches the last fetch position, less the 
fetch latency.  (RosegardenSequencerApp::keepPlaying)  When it does:

 * Fetch events from the mapped composition, starting at the last 
fetch position and with a duration of the read-ahead.

 * Dump them out.  As Rich notes elsewhere, there's no latency 
accounted for in the read, but the play latency is added during the 
write.

 * Increment the last fetch position by the read-ahead.

 * Continue.

Yeah, I see what you mean about there being a latency missing.  Hmm.

The fetch latency describes latency within our own system that 
requires us to start getting events before they're supposed to be 
queued.  That should be as short as possible, but obviously no 
shorter than the time it actually does take to fetch a slice.  If 
it's too short, notes at the start of the slice will end up bunched 
up somewhat.  Yes?

The play latency describes latency elsewhere within the system that we 
need to account for (MIDI cables, USB interfaces etc?).  I don't have 
much feel for this one, except that if it's too low we get dropouts 
because ALSA can't process the events before their timestamps and 
that's pretty fatal.

The read-ahead describes how big a chunk we write at a time, and 
should be short enough not to cause too much of a lag at the GUI 
(e.g. when stopping playback) but long enough to allow ALSA to do 
most of the timing work instead of us.  Having read-ahead does cause 
problems at the end of a loop (where we always get some notes from 
after the loop edging in).

So, I think the latency we're missing is a fetch latency subtracted 
from the arguments to the call to fetchEvents.  At the moment the 
slice code kicks in when it thinks we need a slice at a time offset 
by the fetch latency, but then it's not using the fetch latency to 
get the slice.


Chris