Re: [FFADO-devel] MOTU code lost in api cleanup

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

Hi Pieter

> >> I've been doing some optimizations on the amdtp SP's that can be 
> >> interesting for the motu too. Especially regarding the muxing and 
> >> conversion of packets to ports etc, since that seems to be a major 
> >> performance issue.
> > 
> > Indeed.  One thing I'm trying to work out is an efficient way to
> > encode/decode an array of packed 24 bit integers.  The way I currently do
> > this in the MOTU code is effectively to write byte-wise but this is a killer
> > for performance, especially on newer CPUs.  I have ideas which, now the
> > whole Christmas thing is finished, I might actually get a chance to
> > experiment with.
> 
> Be sure to take a look at the Amdtp transmit SP (in the api-cleanup 
> branch) when you experiment.

Initially I'll be doing some out-of-tree tests since it's easier to measure
performance.  What's your plan for merging your api-cleanup branch back to
main?

> Note that a very big performance hit (for me at least) is the int->float 
> conversion, but that should be solved when compiling with -march=pentium.

Yes, it always is on Pentiums.  It's to do with the way gcc codes int-float
conversions - it does it in a way which causes a pipeline stall on the FPU.
Check out 

  http://mega-nerd.com/FPcast/

for the details of the problem.  At the end of this document are links to
header files which implement the ideas contained therein.  A few months ago
I tested the theory in ffado with a subset of the MOTU code and found that
the implementation of these ideas did result in a drop in the CPU load
required by ffado.  Messing with these ideas inside the MOTU code is one of
the things I want to do in the near future since its a relatively easy way
of getting a potentially large efficiency improvement.

> I'd like to eliminate the 'seconds' field from the timestamps, as it's a 
> rather unnecessary field due to it's timespan. This might be a 
> significant performance optimization since doing so removes (at least) 
> 30% of the work timestamp operations have to do. It also allows us to 
> use 32-bit integers for the timestamp, and IMHO also floats for the 
> timestampedbuffer DLL. What are your thoughts on this?

I don't need the seconds field for the MOTU - in fact the MOTU does not send
or receive a seconds field in its pseudo-timestamp fields, so in order to
utilise the current DLL I have to synthesise the seconds field within the
MOTU code.  Unless there's something I've missed I don't have a problem with
the seconds field going away.

Moving from double to float for the timestampedbuffer DLL would improve
performance I would expect, especially on 32 bit CPUs.  However, we have to
be careful to ensure that we really do have sufficient resolution with a
float since some interfaces (eg: the MOTU) really cannot work without it.

Having a look at my initial notes on the subject my immediate reaction is
that even without the seconds field a float is unlikely to provide
sufficient resolution to keep picky interfaces like the MOTU happy.  After
dropping the seconds field the maximum count in the DLL accumulators will be
24576000.  Thus we consume 8 significant figures for the units portion of
the DLL timestamp value.  Experimentation has shown that the MOTU requires
at least 2 decimal places of precision (and preferably more) to ensure the
timestamps don't drift due to round-off effects.  A float has no more than 9
significant digits, which would mean that for at least half a second the DLL
will only be capable of reporting (and keeping track of) at most one decimal
place in its timestamps. This is almost certainly insufficient for correct
operation of the MOTU based on prior experience.

Having said all that I think it's infinitely preferable to get rid of the
use of double in the timestamped buffer - as I mentioned at the time I made
the change to double in July 2007.  However, if this is to be done we'll
have to come up with a clever way of preserving sufficient precision for
interfaces like the MOTU - a float by itself is unlikely to be enough, even
without the seconds field.

> The current trunk and api-cleanup branch still seem to have a startup 
> issue. I didn't see it with the devices I usually test with, but when 
> testing with the (more picky) saffire pro it showed up. Apparently at 
> startup it can happen that we stop sending packets until the system 
> starts (i.e. the device has sent some valid packets). The saffire 
> doesn't like this, and dies. This might be a problem for the motu too. 
> I'm investigating the issue, and it should be solved soon.

No problem.  Under alternative operating systems I have confirmed that the
OS in fact does not start sending packets to the device until some time
after streaming is started.  It seems to me that the software does this to
allow the transmit stream to lock to the timing provided by the receive
stream before attempting transmission.  It's therefore likely that the MOTU
may in fact tolerate the above stream interruption but of course testing is
the only way to confirm or deny this.

Note I didn't get to the testing overnight because something which was to
occur tonight got moved to last night at the last minute.  Therefore I
should be able to do something tonight instead.

Regards
  jonathan