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

[Owlsroost]

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]

BTW - what do all the "SynchCorrection::GetMatchingSampleForTime: Not Enough Data" messages in the AudioRenderer log mean ? (90000 of them !)

 

[davidf]

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]

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

 

[Owlsroost]

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

 

[tourettes]

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]

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]

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]

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]

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.....