Changeset 289

Show
Ignore:
Timestamp:
07/11/06 16:44:36 (16 years ago)
Author:
jwoithe
Message:

Minor tidy up. Some comments clarified.
Some test code has been added to the MOTU stream processor to assist in tracking down some sync-related issues.

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved
  • branches/libfreebob-2.0/src/libstreaming/MotuStreamProcessor.cpp

    r287 r289  
    9090#define CYCLE_DELAY 1 
    9191 
    92 // FIXME: currently data is not sent when the stream is disabled.  The 
    93 // trouble is that the MOTU actually needs zero data explicitly sent from 
    94 // the moment its iso receive channel is activated; failure to do so can 
    95 // result in a high pitch audio signal (approx 10 kHz) in channels which 
    96 // have had non-zero data in the past.  Things need to be changed around so 
    97 // this can be done; essentially the tests on m_disabled disappear from 
    98 // almost everywhere.  Instead, m_disabled will determine whether data is 
    99 // fetched from the event buffer or whether zero data is generated. 
    100 // 
    101 // The other thing which needs to be worked out is close-down. 
    102 // Experimentation has shown that some zero packets need to be sent so no 
    103 // high-pitched noises are emitted at closedown and subsequent restart.  In 
    104 // the proof-of-concept code this was done by manually calling 
    105 // raw1394_loop_iterate() from the iso shutdown function.  Under freebob a 
    106 // similar thing needs to be done from the respective function in the Motu 
    107 // AvDevice object, but the precise way of doing so without causing issues 
    108 // is yet to be determined. 
    109 // 
    110 // Finally, every so often sync seems to be missed on startup, and because 
     92// FIXME: every so often sync seems to be missed on startup, and because 
    11193// this code can't recover a sync the problem remains indefinitely.  The 
    11294// cause of this needs to be identified.  It may be the result of not 
    113 // running with RT privileges for this initial testing phase. 
     95// running with RT privileges for this initial testing phase.  Even so, sync 
     96// recovery needs to be implemented. 
    11497 
    11598        enum raw1394_iso_disposition retval = RAW1394_ISO_OK; 
     
    120103        m_running = true; 
    121104         
     105// FIXME: some tests - attempt to recover sync after loss due to missed cycles 
     106static signed int next_cycle = -1; 
     107if (!m_disabled && next_cycle>=0 && cycle!=next_cycle) { 
     108  debugOutput(DEBUG_LEVEL_VERBOSE, "tx cycle miss: %d requested, %d expected\n",cycle,next_cycle); 
     109  // Try to pick up the transmit sequence as best we can.  This only works 
     110  // some of the time for some reason. 
     111  m_cycle_count = -1; 
     112} 
     113if (!m_disabled) 
     114  next_cycle = (cycle+1)%8000; 
     115else 
     116  next_cycle = -1; 
     117 
    122118        // Initialise the cycle counter if this is the first time 
    123119        // iso data has been requested. 
     
    760756        // an xrun however since sometimes these can occur "normally" during 
    761757        // shutdown.  This is probably all tied up with the sync recovery 
    762         // issue which hasn't really been exported yet. 
     758        // issue which hasn't really been explored yet. 
    763759        if (m_disabled || !isRunning()) 
    764760                return true; 
     
    768764                // the closedown count to the number of zero packets which 
    769765                // will be sent to the MOTU before closing off the iso 
    770                 // streams.  FIXME: 128 is the experimentally-determined 
    771                 // figure for 48 kHz.  Other rates may require other 
    772                 // settings. 
    773                 m_closedown_count = 128; 
     766                // streams.  FIXME: 128 packets (each containing 8 frames at 
     767                // 48 kHz) is the experimentally-determined figure for 48 
     768                // kHz with a period size of 1024.  It seems that at least 
     769                // one period of zero samples need to be sent to allow for 
     770                // inter-thread communication occuring on period boundaries.  
     771                // This needs to be confirmed for other rates and period 
     772                // sizes. 
     773                signed n_events = m_framerate<=48000?8:(m_framerate<=96000?16:32); 
     774                m_closedown_count = m_period / n_events; 
    774775                return false; 
    775776        }