<div dir="ltr">On Thu, Nov 9, 2017 at 2:20 PM Peter Bennett <<a href="mailto:pb.mythtv@gmail.com">pb.mythtv@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Devs<br>
<br>
There is a Frontend General Playback setting called "Extra audio<br>
buffering" which mentions certain types of tuners that cause crackly<br>
audio. Actually it enables setting DecodeExtraAudio which then maybe<br>
sets a flag called lowbuffers in the demuxer (class AvFormatDecoder).<br>
There is lots of complicated logic around whether or not that flag is<br>
set and in some cases its value is saved and reset.<br>
<br>
The lowbuffers flag is only tested once in the system and if set the<br>
program buffers 100ms of video packets in AvFormatDecoder::GetFrame, so<br>
that audio is not left behind.<br>
<br>
Bug #13172 describes how playback becomes extremely jerky if you adjust<br>
audio sync negatively more than a small amount. The solution is very<br>
simple, just buffer more than 100ms in AvFormatDecoder::GetFrame. I<br>
tested with 1000ms and then you can successfully set audio sync to<br>
somewhere around -1200 before it becomes jerky. In the patch for the fix<br>
I settled on a figure of 250 as a good default and added for a setting<br>
called AudioReadAhead for the value.<br>
<br>
I would also like to get rid of the complex logic and flag surrounding<br>
the DecodeExtraAudio flag and replace that setting in frontend setup<br>
with AudioReadAhead with a default value of 250. With a value of 250 or<br>
1000 it works on everything I have tried. There is no adverse impact<br>
that I can see, although it will take some extra memory for the<br>
additional buffering. I do not know why there is all the extra logic<br>
around whether or not to set the flag, it is safe and easy to set it all<br>
the time.<br>
<br>
I propose a setting that specifies number of milliseconds of audio<br>
read-ahead with an explanation that says to increase this value if the<br>
audio is jerky especially when adjusting audio sync negative.<br>
<br>
Any comments?<br>
<br>
Peter<br></blockquote><div><br></div><div>I have not looked at any of this code, but my guess is that it was to handle frame-grabber cards, where Myth had to mux the audio and video together itself.  We pretty much don't support those anymore (using one in this age is just asking for pain).</div><div><br></div><div>If you want to play it safe, create a branch and ask as many people as possible to try it.  I will.</div><div><br></div><div>However, if it is working well for you, even with your RPi units, then I expect it to be fine.</div><div><br></div><div>John<br></div></div></div>