MediaPortal Audio Renderer - Strange Clock / Sync Issues (1 Viewer)

[T.J]

One again i've spoken too soon - was watching some recorded tv and had the audio at least half a second out from the video :-(

Attached are the logs and screenshots of the four differernt configs i've tested / logged, they are

HW_on_TS_on: HWBasedRefClock set to 1 in the registry and time stretch enabled
HW_on_TS_off: HWBasedRefClock set to 1 in the registry and time stretch disabled
HW_off_TS_on: HWBasedRefClock set to 0 in the registry and time stretch enabled
HW_ff_TS_off: HWBasedRefClock set to 0 in the registry and time stretch disabled

I'm using a single display (TV) connected via a Denon AV receiver using HDMI.

All the logs etc were created using the same recording each time and allowed to play for about 20,000 frames. The dropped frames are glitches in the signal, on the HW_off_TS_on the drift was about -16ms but reset to zero at around 17,500 frames when it dropped some.

Once again thanks for all the help

 

[kiwijunglist]

drift is normal for timestretching (AFAIK) it builds up then it resets.

 

[davidf]

If you are referring to the Hw vs System then this number is expected to drift and wander. The value represents the difference between the clock on your motherboard and the clock in the audio hardware. MPAR uses the audio hardware to determine the media time rather than the motherboard, as the when the audio hardware has produced 10 seconds of sound then 10 seconds of media have passed (no matter if your motherboard says different - to use it would cause periods of silence (motherboard clock slower than audio hardware) or missing audio (motherboard faster than audio hardware)). On some setups one or both of these clocks can "estimate" some values - on Xonar hardware we've seen the clock go backward on occasion.

For your purposes the drift is the one to watch - it's how much difference there is between what you see and what you hear i.e. how far ahead the video is from the audio. For situations where little resampling is required it is better to pass the audio to the hardware as it is on the TV broadcast and only resample the audio when the difference between what you are seeing and hearing gets to a certain threshold (18 ms from memory). This is done as resampling degrades the audio slightly and you will only notice the "drift" when it gets to about 20ms or above (substantially above usually).

It is possible for MPAR to be out of sync (starts out of sync and stays out - very rare and I can't find the cause or replicate on demand), but if it starts in sync it should stay there.

The reason you should not use MPAR with live TV is that your TV provider will only provide TV at a certain speed (50Hz) so if MPAR resamples the audio to match the refresh rate of your TV then you will run out of buffered TV broadcast to display - at this point any one of a number of bad things might happen, usually stuttering or silence followed by picture breakup (occasionally Live TV stops as it thinks the stream has stopped). This would be true in your case as your monitor/tv is running at just over 50Hz so MPAR will resample so that: just over 1 second of stream audio is played in every second of real time. While this will cause you to have a nice smooth picture it will not last for long enough for an evening of TV viewing.

 

[T.J]

Thanks for detailed reply - makes a lot of sense when explained that way. Just a quick follow up question, does changing channel "reset" the tv buffer and would this make it possible to use MPAR on live TV as long as the channel changes were fairly frequent?

 

[davidf]

, sometimes it has the effect of resetting the buffer, sometimes not... there are a lot of other factors as the TV Server tries to be efficient about what it does (Whether the channel is on the same mux, whether the audio/video are of a different format or resolution). It may work or may not.

Owlsroost is working on a solution for that though, it may turn up in Area 51 at some point (if I'm honest I promised to help him but I've been busy with two paying jobs, and one of them is getting neglected ). It will slow the audio to allow a minimum buffer to be kept (and cause a few duplicated frames, although you probably won't notice as it would only kick in if the buffer ran too low and only for a short period). If it was accurate I'd try and work out how long you'd be able to watch for, but it wouldn't give an answer you could rely on (and I'm too tired to be sure of getting the answer right - it would take a lot of code reading to be sure I'd got all the * & / the right way round).

 

[longjohn119]

If you mean bitstreaming then you should say bit streaming NOT passthrough

This is why MediaPortal is so confusing to mo0st people, everyone including the people at MediaPortal use different terminology than the property and setup pages use

The difference between a Master and a Journeyman is attention to detail, something that's missing in the software world today especially when it comes to documentation. Openj Sourse is especially frustrating because most documentation consists of **opinions** on a message board and most of them are wrong so you send hours fixing a problem that wouldn't take 5 minutes with good documentation

Like right now for me I'm likely to spend 2-3 hours trying to figure out why this supposedly best thing since sliced bread the Mediaportal Audio Renderer just doesn't work despite having the setting exactly like the tutorial that doesn't include (as usual) a clue on what to do when it doesn't work

Frankly the ONLY reason I don't go back to MCE 7 is it doesn't have any real streaming to my other devices but other than that it just works .... I'll take something that works right over Eye Candy any day

Did you have audio passthrough unticked and see if this helps?

I quote @kiwijunglist here

LAV Audio Configuration:

It doesn't matter if you use HD-Audio / HDMI audio / Digital Co-axial / Optical SPDIF / RCA - you must disable bitstreaming so we can decode everything for MPAR. Trust me you will not lose out on quality we are using the all powerful mediaportal audio renderer!!!!! MPAR can output HD audio via PCM. We also don't want A/V Sync correction in LAV!!!

Mediaportal Audio Renderer (MPAR) Configuration:

 

[blub]

Hi

I am using MPAR and it is working perfectly with my AVR set to a dlay of 50ms. However, as mentioned before, it does not work for Live TV.
For live TV I have to set my AVR to a delay of 80ms - however I do not want to change the setting each time I switch from movies to Live TV

Any idea how I can set MP to have a fixed delay for TV codecs (i.e. 30 + 50 AVR =80)?

 

[CypherMK]

Hi

I am using MPAR and it is working perfectly with my AVR set to a dlay of 50ms. However, as mentioned before, it does not work for Live TV.
For live TV I have to set my AVR to a delay of 80ms - however I do not want to change the setting each time I switch from movies to Live TV

Any idea how I can set MP to have a fixed delay for TV codecs (i.e. 30 + 50 AVR =80)?

Mpar will not work with live TV!

 

[HomeY]

Mpar will not work with live TV!

It will work as long as the audio's HW clock is not running faster than the broadcaster's HW clock .

 

[CypherMK]

It will work as long as the audio's HW clock is not running faster than the broadcaster's HW clock .

But it generally advised not to use it with live TV, right?