[FFADO-devel] MOTU status update

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

Hi Pieter

I had a chance to test ffado svn845 overnight against jackd svn1082. 
Briefly:

 1) The startup / shutdown issues remain in that the high-pitched tone is
    heard during these times.  No surprises here since that wasn't addressed
    between revisions 833 and 845.

 2) CPU load has dropped slightly - on my 2 GHz machine it's down from 65%
    with rev 833 to around 55% with 845.  Still too high but obviously a
    move in the right direction.

 3) I'm still getting a segfault on jackd exit but it's not precipitated by
    the operation of the watchdog anymore.  I didn't have time to chase this
    extensively.  A core dump indicated the segfault occured as a result of
    the getName() method call in PortManager::~PortManager() on line 47 of
    src/libstreaming/generic/PortManager.cpp.  It was faulting while dealing
    with one of the MIDI ports.  My theory at present is that the MIDI ports
    might be freed elsewhere (in a throwback to the previous MIDI port
    arrangement) but not unregistered.  This may mean that the MIDI ports
    have already been destroyed by the time PortManager::~PortManager() runs.
    At this point though this is just all idle speculation on my part.

In relation to (1) I must say I'm somewhat confused about what is meant to
occur in the different states, what the various methods in
MotuTransmitStreamProcessor.cpp are meant to do and how these methods relate
to the different states.  We seem to have "data" packets, "empty" packets
and "silence" packets, although "empty" and "silence" packets currently seem
to both do the same thing (return a header only packet with length 8).  In
my view "silence" packets should be data packets with the audio data all set
to zero.  If this is the intention I can't quite see how the current code is
meant to achieve this.

Finally I note in StreamProcessor.h that the ePS_WaitingToStop state (which
as the comment says will be needed for MOTU) has been commented out.  I
therefore conclude that this state has not yet been implemented.  If this is
the only way of sending zeroed audio data to the MOTU on closedown (which is
needed to prevent the nasty high-pitched tones on shutdown and the next
startup) then there probably isn't much I can do on the MOTU side until the
base infrastructure implements this.  On the other hand, perhaps you've
rolled this into the DryRunning state, but if so it's not clear to me how
the MOTU streaming code should deal with the DryRunning state.

Regards
  jonathan