The Audio Renderer has an issue with some hardware / reference clock generation (1 Viewer)

Status
Not open for further replies.

Owlsroost

Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    From TsReader.logs it is visible that the TsReader is trying to throttle the playback

    Where in the log - I can't see any evidence of this ?

    I seem to have mixed up the pause that the seeking causes, my bad (been just too many years when I have gone thru the TsReader logs :)).

    No problem - I thought that might be the case - there are a lot of seeks in the log... :)
     

    Owlsroost

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    BTW - what do all the "SynchCorrection::GetMatchingSampleForTime: Not Enough Data" messages in the AudioRenderer log mean ? (90000 of them !)
     
    Last edited:

    davidf

    Retired Team Member
  • Premium Supporter
  • April 3, 2006
    796
    348
    Scotland
    Home Country
    Scotland Scotland
    It means that there are 1 or less samples for the time point(stream time). I.e. There is nothing in the wasapi buffer. It also means drift is forecast rather than calculated as it will use the last sample time and infer the current time by following where it's gradient would be now.

    If that line appears more than occassionly then something is seriously wrong.

    In this case the data is turning up late as you can see by the drops
     

    tourettes

    Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    4,800
    BTW - what do all the "SynchCorrection::GetMatchingSampleForTime: Not Enough Data" messages in the AudioRenderer log mean ? (90000 of them !)

    WASAPI renderer filter is probably running out of data. Is it live tv?

    edit, david was faster :)
     
    Last edited:

    Owlsroost

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    The log lines are there in both the 'TsReader' and 'LAV' splitter logs from FreakyJ (165000 lines in the 'LAV' splitter version), and it's a recording according to the info in TsReader.log :confused:
     
    Last edited:

    tourettes

    Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    4,800
    01-03-2013 18:15:47.266 [ bc0] Using HW clock
    01-03-2013 18:17:01.699 [ 12fc] SynchCorrection::GetMatchingSampleForTime: Not Enough Data

    So it takes for 1 min 13 seconds "until" the WASAPI buffers start to run on the edge.

    Please set LogSampleTimes = 1 in the registry (HKEY_CURRENT_USER\Software\Team MediaPortal\Audio Renderer), it will give more info on the buffery status.
     

    FreakyJ

    Retired Team Member
  • Premium Supporter
  • July 25, 2010
    4,024
    1,420
    Home Country
    Germany Germany
    sure I will turn it on and watch some tv.
    I was now watching all the time with the Tv @50Hz and it was working fine, so I assume I should switch to 60Hz again for the test?
     

    FreakyJ

    Retired Team Member
  • Premium Supporter
  • July 25, 2010
    4,024
    1,420
    Home Country
    Germany Germany
    here are the live tv logs I talked about in my previous post, I watched a half hour on Zdf_info

    Tv @50Hz
    live Tv
    TsReader + Lav for the rest + MPAR
     

    FreakyJ

    Retired Team Member
  • Premium Supporter
  • July 25, 2010
    4,024
    1,420
    Home Country
    Germany Germany
    new logs
    - Tv @60Hz
    - LogSampleTimes = 1
    - watched a recording

    Result: after some time there were heavy stuttering in the sound => I stopped Playback and posted logs here
     

    Owlsroost

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    A thought - TsReader uses calls to IMediaSeeking::GetCurrentPosition() - http://msdn.microsoft.com/en-gb/library/windows/desktop/dd407028(v=vs.85).aspx - to keep track of the relationship of sample timestamps to playback position (for various reasons).

    I wonder if this method takes into account the heavy clock pulling which is happening here (bias = 0.96) - if it doesn't, it might explain why TsReader might be having problems - although the clock is running slow, so it shouldn't be running out of data - doesn't make much sense at the moment.....:confused:
     
    Status
    Not open for further replies.

    Users who are viewing this thread

    Top Bottom