[mythtv] AVSync2 Improvements

Mark Spieth mark at digivation.com.au
Tue Feb 12 23:48:18 UTC 2019


On 13/02/2019 10:38 am, Peter Bennett wrote:
>
>
> On 2/12/19 3:59 PM, Mark Spieth wrote:
>> On 2/13/2019 3:01 AM, Peter Bennett wrote:
>>> I have been using the latest patch 
>>> https://code.mythtv.org/trac/attachment/ticket/13383/20190208_1644_catchup_plus.patch 
>>> for a couple of days and it looks good now.
>>>
>>> Mark- you said you may have some improvements - I plan to commit it 
>>> anyway and those can always be done afterwards.
>>>
>>> You said that making the wait into a series of short waits may 
>>> improve things. Currently on a desktop system everything is between 
>>> -5 and +5 ms so I don't know if much improvement is possible. Also 
>>> on thinking about it I don't know how that would help, if the 
>>> operating system is going to delay resuming a process on one wait, 
>>> would it be less likely to delay it on a bunch of smaller waits?
>>>
>>> If I don't hear anything back I will commit that patch to master and 
>>> fixes/30.
>>>
>> By all means commit. It seems pretty good to me. Haven't tested live 
>> TV since I don't use it but the periodic video stutter is ok. Not as 
>> smooth as it could be but pretty good at all speeds so far used. I 
>> see on the shield +-20ms which I don't understand ATM. The opensles 
>> driver chunks things into 10ms blocks so that is currently the best 
>> audio time quantum that is available. Ill look at providing a better 
>> estimate which should be possible using the buffer callback and a 
>> time delta.
>>
>> The original AVSync used some averaging/smoothing of the AV delta, so 
>> that may be useful to improve playback smoothness. Panning shots and 
>> ticks show this effect quite clearly.
>>
> I added the avsync averaging code to address the problems with OpenMAX 
> Audio. AVSync2 is supposed to achieve the same by limiting the size of 
> each adjustment to 10 ms or other value as specified in settings. You 
> could try changing that to see if it helps.
>> Not sure how much the smaller delays affect things. When I get time 
>> Ill disable or maybe put in a config and do some A/B tests.
>>
>> As mentioned before, there may be a timestamp wrap issue but only saw 
>> strangeness once and have deleted that program so Ill have to wait 
>> until I see it again.
>>
> The code under "if ((lateness > AVSYNC_MAX_LATE || lateness < - 
> AVSYNC_MAX_LATE)" is supposed to address timestamp wrap, which should 
> occur without anything unusual being visible. If you have any example 
> which wraps I would like to test it and make sure.
It was just a gut feeling. No evidence. Have to find another instance 
and chase it when I see it.
>> Cheers
>>
>> Mark
>>
> I have attached a new patch to the ticket to address the LiveTV problem.
>
LGTM but it does change the pause nature of the system. Not sure of this 
effect, but resetting rtcbase seems key.

Mark



More information about the mythtv-dev mailing list