MediaPortal Audio renderer - better video playback quality (6 Viewers)

[davidf]

Neither do I except when the RAID 1 gets full. More storage just means a bigger housekeeping task when you run out and I haven't cleared out the NAS in ages, more storage = bad housekeeping. It was mostly TV recordings, but unfortunately not all. We lost both legs of a DB cluster in work a while ago within 10 minutes of each other and the datacentres are 15 miles apart to prevent dataloss

Apologies for being a bit off topic.

 

[tourettes]

Re: AW: MediaPortal Audio renderer - better video playback quality

@tourettes
could you explain a little bit in which cases it makes sense to change the value to 0 (system clock)?

In theory newer, since the A/V sync shouldn't be drifting anymore if the system clock and audio clocks are running different speeds. But if there are some more severe issues spotted then it is worth to test the system clock as reference. Also it is not yet 100% sure that the audio clock related code is able to cure the slowly drifting A/V sync.

Some A/V synch problem with audio HW based reference clock. Watching Covert Affairs after some pauses and some stops play lost A/V synch. video delay for maybe 500-750 ms.

Did that A/V sync sudenly appear or did it grow during the playback? That would be the most interesting thing to know since:

1) suddenly (after skip / resume from pause) -> issue is not related to the audio HW clock as reference clock
2) drifted slowly to bigger -> issue is most likely broken auio HW ref clock code (althou the system clock based would cause similar drifting, but probably in different magnitude)

I think there is some bug currently that causes the slowly drifting A/V sync issue with the audio HW reference clock inplementation. At least I did notice a A/V sync issue in recorded tv playback yesterday after 30 minutes. Pretty nasty to track down since it happens such slowly - I guess I'll have to figure out some way to calculate the sync drifting to be able to "see" it before it is possible to hear / see the actual drift in the playback.

 

[tourettes]

@tourettes you need the code within the TODO because of audio clock starting half way through a period which would give a high adjustment rate incorrectly (although this depends on the code within the audio renderer so I can't be sure).

Actually the audio buffer related timestamps stay as zero when the rendering is not done, so the high adjustment is not done because of that. But the actual adjustments seems to be quite varying it would have expected much more smaller variance in the multiplier. Now it is just too coarse what we get.

Added adjustment for completeness - the correction code is in integer maths which used to be quicker but probably isn't anymore, you have the bias to worry about which is a double anyway.

Thanks, I'l try to test that approach if it is giving any better results than the current one.

 

[tourettes]

I can't see what's wrong yet (how is m_dAdjustment calculated?) but the figures are not what I expected. The stats on my machine show a constant 1.0003 which would add up to a clock drift of just over 1 second per hour or 24 seconds per day. It could be in the Audio Clock I suppose but I'm certainly not seeing my clock go off by 3.5 minutes per week.

dAdjustment adjustment is not calculated at all, It is either 1.0, 0.997 or 1.003. This is used for the minor v-sync position correctins and it is the EVR presenter who decides what adjustment should be used - basicly it will slowly move the v-sync into correct position by resampling the audio a bit. So, m_dAdjustment is not related to the audio HW clock at all.

void MPEVRCustomPresenter::AdjustAVSync(double currentPhaseDiff)
{
  // Keep a rolling average of last X deviations from target phase. 
  // These numbers have values between -0.5 and 0.5
  int tempNextPhDev = (m_nNextPhDev % NUM_PHASE_DEVIATIONS);
  m_sumPhaseDiff -= m_dPhaseDeviations[tempNextPhDev];
  m_dPhaseDeviations[tempNextPhDev] = currentPhaseDiff;
  m_sumPhaseDiff += currentPhaseDiff;
  m_nNextPhDev++;

  double averagePhaseDifference = m_sumPhaseDiff / NUM_PHASE_DEVIATIONS;
  
  m_avPhaseDiff = averagePhaseDifference;

  // If we are getting close to target then stop correcting.
  // Since it is a rolling average we will overshoot the target, so we plan to stop early.
  // If we are speeding up, we should stop when above the "green" limit
  if (m_dVariableFreq > 1.0)
  {
    if (averagePhaseDifference > -0.05 )
    {
      m_dVariableFreq = 1.0;
    }
  }
  // If we are slowing down, we should stop when below the "green" limit
  if (m_dVariableFreq < 1.0)
  {
    if (averagePhaseDifference < 0.05 )
    {
      m_dVariableFreq = 1.0;
    }
  }

  // If we have drifted significantly away from target, let us speed up or slow down until we are within above limits again
  if (averagePhaseDifference > 0.1)
  {
    m_dVariableFreq = 1.003;
  }
  if (averagePhaseDifference < -0.1)
  {
    m_dVariableFreq = 0.997;
  }

  //Log("VF: %f averagePhaseDif: %f CP: %f ", m_dVariableFreq, averagePhaseDifference, currentPhase);

  if (m_pAVSyncClock && m_dVariableFreq != m_dPreviousVariableFreq)
  {
    m_pAVSyncClock->AdjustClock(1.0/m_dVariableFreq);
    m_iClockAdjustmentsDone++;
  }

  m_dPreviousVariableFreq = m_dVariableFreq;
}

 

[davidf]

Added adjustment for completeness - the correction code is in integer maths which used to be quicker but probably isn't anymore, you have the bias to worry about which is a double anyway.

Thanks, I'l try to test that approach if it is giving any better results than the current one.

The speed up will probably be significant percentagewise but will be small in real time i.e. your code execution time will be small anyway. One advantage it will give you is that there will be no error introduced due to floating point maths. After seeing the variation over your 100 second sample I would probably up the 10 minute sample limit to see when it becomes stable, it seems to have a range 0.0004 after 100 seconds. You didn't use a max sample time but I didn't want to overflow the figure (but I suspect you'd need a few years of samples to do that 2^64 is quite big even in nano seconds)

 

[tourettes]

Added adjustment for completeness - the correction code is in integer maths which used to be quicker but probably isn't anymore, you have the bias to worry about which is a double anyway.

Thanks, I'l try to test that approach if it is giving any better results than the current one.

The speed up will probably be significant percentagewise but will be small in real time i.e. your code execution time will be small anyway. One advantage it will give you is that there will be no error introduced due to floating point maths. After seeing the variation over your 100 second sample I would probably up the 10 minute sample limit to see when it becomes stable, it seems to have a range 0.0004 after 100 seconds. You didn't use a max sample time but I didn't want to overflow the figure (but I suspect you'd need a few years of samples to do that 2^64 is quite big even in nano seconds)

Just wondering about how to detect the A/V sync drifting (we must assume that the EVR presenter itself is not causing any drifting... otherwise it will get too complex - but the dropped frames should make the piling up of the error impossible).

Would following give use the required debug info?

if (m_dStartQpcHW == 0)
      m_dStartQpcHW = hwQpc;

    if (m_dStartTimeHW == 0)
      m_dStartTimeHW = hwClock;

    if (m_dStartTimeSystem == 0)
      m_dStartTimeSystem = dwTime;

    if (m_dStartTimeCorrected == 0)
      m_dStartTimeCorrected = m_rtPrivateTime;

    m_dDurationHW = (hwClock - m_dStartTimeHW) / 10000;
    m_dDurationSystem = (dwTime - m_dStartTimeSystem); 
    m_dDurationCorrected = (m_rtPrivateTime - m_dStartTimeCorrected) / 10000;

    //Log("hw: %I64d sys: %I64d cor: %I64d hwsy: %I64d hwcor: %I64d", m_dDurationHW, m_dDurationSystem, m_dDurationCorrected, m_dDurationHW - m_dDurationSystem, m_dDurationHW - m_dDurationCorrected);

    if (m_dPrevTimeHW > hwClock)
    {
      m_dStartTimeHW = m_dPrevTimeHW = hwClock;
      m_dStartQpcHW = m_dPrevQpcHW = hwQpc;
      m_dStartTimeSystem = dwTime;
      m_dStartTimeCorrected = m_rtPrivateTime;
    }

void CSyncClock::GetClockData(CLOCKDATA *pClockData)
{
  // pointer is validated already in CMPAudioRenderer
  pClockData->driftMultiplier = m_dSystemClockMultiplier;
  pClockData->driftHWvsSystem = m_dDurationHW - m_dDurationSystem;
  pClockData->driftHWvsCorrected = m_dDurationHW - m_dDurationCorrected / m_dBias;
}

driftHWvsSystem <-- drift in this should be constantly going into up or down, with the speed of the driftMultiplier. If that happens the correction should be working ok.

driftHWvsCorrected <-- this should be quite static? If this increases or decreases it should tell us that the A/V sync is failing apart? Of course it wont take the bias into account. Also the adjustment might falsely cause drifting (or it could even cause real drifting).

Are those assumptions valid? Or should we use something else to compute the real A/V sync drifting? I really cannot sit in the front of TV / monitor for months to watch the A/V sync slowly getting out of the drift and then make a single code line change after 2 hours have passed (to be able to detect the sync drifting)

 

[red5goahead]

Re: AW: MediaPortal Audio renderer - better video playback quality

In theory newer, since the A/V sync shouldn't be drifting anymore if the system clock and audio clocks are running different speeds. But if there are some more severe issues spotted then it is worth to test the system clock as reference. Also it is not yet 100% sure that the audio clock related code is able to cure the slowly drifting A/V sync.

Some A/V synch problem with audio HW based reference clock. Watching Covert Affairs after some pauses and some stops play lost A/V synch. video delay for maybe 500-750 ms.

Did that A/V sync sudenly appear or did it grow during the playback? That would be the most interesting thing to know since:

1) suddenly (after skip / resume from pause) -> issue is not related to the audio HW clock as reference clock
2) drifted slowly to bigger -> issue is most likely broken auio HW ref clock code (althou the system clock based would cause similar drifting, but probably in different magnitude)

I think there is some bug currently that causes the slowly drifting A/V sync issue with the audio HW reference clock inplementation. At least I did notice a A/V sync issue in recorded tv playback yesterday after 30 minutes. Pretty nasty to track down since it happens such slowly - I guess I'll have to figure out some way to calculate the sync drifting to be able to "see" it before it is possible to hear / see the actual drift in the playback.

It seems related to fast forward function (maybe the backward I'll check it) and when I pause or stop it disapper.

 

[davidf]

Just been playing downstairs with the proper HTPC and have found out the obvious. Now that I am looking at the correct figure and have been playing with the forward rewind etc. it is blatantly obvious that the error in the figures is introduced during the first few frames (probably during scrubbing). The stats on the ION don't work particularly well but I've attached the two pictures of first run and after a rewind. In the first the aud sys drift is close to your limit of .95 and increasing slowly and in the second after some playing it is a steady 1.00000000.

You can either ignore the first x samples or weight the totalling to give more weight to later samples - this would bring the aud sys drift to it's steady state quite quickly rather than just have it tend towards it as it does now.

The figures I was playing with from your earlier post don't seem as graceful as the ones from the ION which makes me think that the GPU and audio are tied by Nvidia (all done on the GPU).

Could you send me a longer trace of the stats from your setup and I'll try a few different methods to see if the clock can be quickly corrected - the spreadsheet I was trying on is still in work and it would be interesting to see how much the clocks varied, at the end of your trace it was only a total of 15 nano seconds away but had got way off in the middle which is suspicious.

 

[tourettes]

Could you send me a longer trace of the stats from your setup and I'll try a few different methods to see if the clock can be quickly corrected - the spreadsheet I was trying on is still in work and it would be interesting to see how much the clocks varied, at the end of your trace it was only a total of 15 nano seconds away but had got way off in the middle which is suspicious.

DVD and Blu-ray seems to generate more stable audio buffer clock. Maybe since they are multi channel ones and there is few times more data to be rendered (or the DS graph components are just asking for the reference time in "better" times).

 

[tourettes]

You can either ignore the first x samples or weight the totalling to give more weight to later samples - this would bring the aud sys drift to it's steady state quite quickly rather than just have it tend towards it as it does now.

I guess this could explain a bit of the A/V sync drifting, but not the constant drift that I see on my HTPC.

I think the reason for the constant drifting must be the v-sync adjustments the EVR presenter is requesting. There is currently no real correlation how long the reference clock calculation and the audio resampling is done. Both are running on their own. It will be quite hard to make the audio resampling to pass the real modified time to the reference clock (or actually the time is easy to pass...) Currently I can see that some X rate was used to resample xx ms of audio, but I have no clue (yet at least) how the reference clock should take that into account.