372
379
// sending data to the DACs and sending data from the ADCs)
373
380
// packets once it has received a certain amount of data from the PC.
374
381
// Since the receive stream processor won't register as dry running
375
// until data is received, we therefore need to send some data during
376
// the dry running state in order to kick the process into gear.
382
// until data is received, we therefore need to send some data while in
383
// the initial states during startup in order to kick the process into
378
386
// Non-empty "empty" packets are not desired during the dry-running
379
// state encountered during closedown, however, so take steps to ensure
380
// they are only sent during the startup sequence. This logic is
381
// presently a quick and dirty hack and will be revisited in due course
382
// once a final control method has been established.
383
if (streaming_has_run==0 && isDryRunning()) {
387
// state encountered during any other stage (eg: during streaming or
388
// closedown), however, so take steps to ensure they are only sent
389
// during the startup sequence.
391
// Experimentation showed that it was necessary to send "silent" packets
392
// for the duration of the pre-streaming setup. Otherwise the FF800
393
// especially would give a burst of digital noise out of some or all
394
// outputs during the first FFADO streaming startup following the
395
// powering up of the interface (the duration of the burst was estimated
396
// to be of the order of 250 ms at 48 kHz sampling rate). Therefore if
397
// streaming has not yet run assume we're in the pre-streaming stages
398
// and send a silent data packet.
400
// While a single packet was sufficient to get data flowing from the
401
// fireface, the noise bursts would almost always occur in this case.
403
// Sending during the ePS_DryRunning seemed to reduce the probability
404
// of getting the bursts slightly.
406
// Sending during the ePS_DryRunning and ePS_WaitingForStreamEnable
407
// states was almost enough to prevent the noise burst: the bursts were
408
// far less frequent and when they did happen they were very short.
410
// Further notes about the noise burst:
411
// * it was not due to bad data from readFrames().
412
// * it seemed to be aligned to the time around the transition to
413
// the ePS_DryRunning state, although this was never explicitly
415
// * once streaming had been run once the bursts were very unlikely
416
// to occur on second and subsequent runs until the Fireface was
417
// powercycled. Bursts after the initial run were observed on very
418
// isolated occasions, but they could have been a side effect of
419
// testing at the time.
421
if (streaming_has_run == 0) {
384
422
signed n_events = getNominalFramesPerPacket();
385
// unsigned int cycle = CYCLE_TIMER_GET_CYCLES(pkt_ctr);
387
424
streaming_has_dryrun = 1;
388
if (streaming_start_count < (1)*n_events) {
389
streaming_start_count += n_events;
390
*length = n_events * m_event_size;
391
// generateSilentPacketData(data, length);
426
streaming_start_count += n_events;
427
*length = n_events * m_event_size;
395
if (!isDryRunning() && streaming_has_dryrun==1)
398
// m_tx_dbc += fillNoDataPacketHeader ( (quadlet_t *)data, length );
467
495
if (cycles_until_transmit < 0)
469
if (cycles_until_presentation >= RME_MIN_CYCLES_BEFORE_PRESENTATION)
471
m_last_timestamp = presentation_time;
472
m_tx_dbc += fillDataPacketHeader((quadlet_t *)data, length, m_last_timestamp);
497
// At this point we've theoretically missed the cycle at which
498
// the data needs to be transmitted. Technically, if
499
// cycles_until_presentation is greater than or equal to
500
// RME_MIN_CYCLES_BEFORE_PRESENTATION we have an xrun. However,
501
// since this is a silent packet there's no real harm in indicating
502
// that a silent packet can still be sent; it's not as if a silent
503
// packet consumes data. Furthermore, due to the fact that
504
// presentation time is estimated from m_last_timestamp it's possible
505
// that any xrun indication here is a false trigger.
507
// In any case, when silent packets are utilised during shutdown
508
// an eCRV_XRun return is "invalid" (see StreamProcessor, function
509
// getPacket(). Since silent packets are usually used during startup
510
// and/or shutdown there's little to be gained by flagging xruns; all
511
// they seem to do is prevent an otherwise clean shutdown.
512
m_last_timestamp = presentation_time;
513
m_tx_dbc += fillDataPacketHeader((quadlet_t *)data, length, m_last_timestamp);
482
518
else if (cycles_until_transmit <= RME_MAX_CYCLES_TO_TRANSMIT_EARLY)
added
removed
src/libstreaming/rme/RmeTransmitStreamProcessor.cpp
