Re: [FFADO-devel] MOTU: sync issues again

[Jonathan W. <jw...@ph...>]

> On 7/17/07, Jonathan Woithe <jw...@ph...> wrote:
> > The first of these I've mentioned before: the MOTU needs a
> > ENABLE_DELAY_CYCLES (in StreamProcessorManager.cpp) somewhat larger than the
> > current value of 100.  As I've mentioned in the past this was reduced from
> > 2000 to 100 around svn rev 435, but 100 doesn't give the DLL enough time to
> > stabilise in the case of the MOTU.  I'm still thinking about how this can be
> > dealt with.  At the moment I'm considering a new StreamProcessor method
> > which returns its preferred ENABLE_DELAY_CYCLES value.  The
> > StreamProcessorManager can then call this function for every registered
> > stream processor object and choose the largest one.  That way interfaces
> > which can get away with small delays won't be penalised by others which
> > require longer startup delays (unless of course a longer-delay unit is used
> > together with the short-delay unit).  In the absence of howls of protest I
> > may implement this idea later this week.
> I don't have any MOTU hardware here. but it always sounds very harsh
> to me - when someone depends _just_ on timeouts. Are you certain,
> there's no other way here ?

What we're talking about here isn't a timeout.  It's the length of time the
sync source stream processor requires to ensure its software DLL is solidly
locked to the audio clock using timestamp information being supplied to it
via the firewire datastream.  The time taken is a function of many things
including the DLL implementation, the nature of the clock being locked to,
the properties of the timestamp information available and the update
frequency of the timestamp updates.  Most of these details are different for
different interfaces which is why it can happen that with some interfaces
DLL lock can occur much quicker than with others.

To be honest I'm not certain that there's no other way aside from a DLL to
keep sync with the MOTU.  However, based on observation its probably the
most memory-efficient way.  There might well be another trick we could use
but it most likely requires in-depth knowledge about the MOTU's internal
functionality, and unfortunately MOTU flatly refuse to help us out in this
regard.  Therefore we have to make do with what we can deduce.

Regards
  jonathan