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

[tourettes]

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

It is the stream time - only place where you can get is is to query reference clock (and keep the pause & seek calcs in correct state). I see no reason why it would cause any issues if the reference clock runs non 1.0x speed - after all the DS has no other sources of the time than MPAR.

The Filter Graph Manager calculates the position from the current stream time; it does not query the filters in the graph. For file playback, this yields an accurate result, because playback is synchronized to the stream time. For file writing, the results are not accurate. To get the current position in a file-writing graph, query the multiplexer filter. (Position is not relevant for live capture, however.)

 

[l337]

I have tested live TV with spdif Hdmi mediaPORTAL renderer with Lav codec
If everything works perfectly
the sound quality is poor as before (direct sound output)

can this be?

 

[legnod]

I got some time to test the new version and my synch issues (after pause or using skip steps) are gone! For now i only tested LiveTV and recordings but i will test more video formats the next days.
Thank everyone for your great work!

 

[Holzi]

the sound quality is poor as before (direct sound output)

It is not about sound quality but more about perfectly smooth playback. More info: http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/0_What's_New/1.3.x/MediaPortal_Audio_Renderer_(MPAR)

 

[l337]

The playback works great without stuttering or resyncs
The sound quallity is the same?
What audio codec do you use in conjunction with mp renderer?

 

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

It is the stream time - only place where you can get is is to query reference clock (and keep the pause & seek calcs in correct state). I see no reason why it would cause any issues if the reference clock runs non 1.0x speed - after all the DS has no other sources of the time than MPAR.

The Filter Graph Manager calculates the position from the current stream time; it does not query the filters in the graph. For file playback, this yields an accurate result, because playback is synchronized to the stream time. For file writing, the results are not accurate. To get the current position in a file-writing graph, query the multiplexer filter. (Position is not relevant for live capture, however.)

I did some extra logging just to make sure this really is the case - it is

Also tried running MPAR at bias = 0.95 - the "SynchCorrection::GetMatchingSampleForTime: Not Enough Data" problem happens very quickly, but using bias = 1.05 it's fine, so it seems to be related to large slow-downs of the clock.

Tony

 

[tourettes]

I have tested live TV with spdif Hdmi mediaPORTAL renderer with Lav codec
If everything works perfectly
the sound quality is poor as before (direct sound output)

1) sound quality should be compared only to the 1.3.0 RC audio renderer's sound quality - this thread is only for regression testing
2) renderer itself (DS renderer or MPAR) not usually the source for the bad sound quality
3) if there is some sound quality issue in MPAR then a separate thread should be opened for that specific issue

 

[tourettes]

the sound quality is poor as before (direct sound output)

It is not about sound quality but more about perfectly smooth playback. More info: http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/0_What's_New/1.3.x/MediaPortal_Audio_Renderer_(MPAR)

It is also about sound quality - MPAR uses exclusive mode where OS mixer is bybassed. Althou in Windows 7 & 8 there is really minimal or pretty close to non-exisiting improvement to the OS mixer case.

 

[tourettes]

I did some extra logging just to make sure this really is the case - it is

Also tried running MPAR at bias = 0.95 - the "SynchCorrection::GetMatchingSampleForTime: Not Enough Data" problem happens very quickly, but using bias = 1.05 it's fine, so it seems to be related to large slow-downs of the clock.

I'm not able to trigger that issue with slow down. I tried hard coded 0.5 bias inside MPAR and TsReader, LAV splitter and BDReader all are not causing the "not enough data" message to appear.

Is there something extra what is needed to trigger that issue?

 

[Owlsroost]

I've no idea, but attached are logs playing the same recording from the beginning for about 30 seconds, one with bias = 1.0 and one with bias = 0.95 (set from my modified TsReader.ax three seconds after 'run' - about 16 seconds later the "Not Enough Data" messages start). In both my tests and (I think) in FreakJ's situation (==24Hz on 60Hz display) there won't be any AdjustClock() calls, but I guess that shouldn't make a difference.

Would you like me to try some different MPAR settings ?