<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 10/11/17 08:26, John P Poet wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACSqvJ=FHc5EqUMtW1WMhmnZqRfFmoCEvMb08Jp3FmD3B0D8nA@mail.gmail.com">
<div dir="ltr">On Thu, Nov 9, 2017 at 2:20 PM Peter Bennett <<a
href="mailto:pb.mythtv@gmail.com" moz-do-not-send="true">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>
<br>
</blockquote>
Beware of and test with mythmusic and audio only streams when you
change this.<br>
<br>
Note that audio is rendered as it is seen in the decoded stream
whereas video is not.<br>
Audio only for mythmusic has as special shortcut that limits the
buffer to 500ms or less so that when you seek or change streams the
response is quick.<br>
<br>
You are correct in that the audio buffer size directly relates to
the amount of -ve sync achievable. This is a design constraint.<br>
<br>
Also some OTA streams have largely varying A to V time gaps on PTS
and the buffer is also required to absorb this. mkv's can also be
quite un-aligned Ive found.<br>
<br>
If you enable some of the more fancy features in audio land such as
ch->6ch upsampling and AC3 reencoding, you will also chew up the
buffer. The upsampling is especially a buffer hog partially due to
the LPF for the subwoofer channel. I have noticed this is quite long
when I start/skip for audio to catch up (600+ms).<br>
<br>
Changing the extra buffering to a number in settings is ok but you
need to add some help text.<br>
That said, I have patches to change mine to 1.5 secs as default
audio buffer size because the existing is inadequate for some of my
media.<br>
<br>
As an aside, there is also a bug in passthru mode in that if the
rate does not match the standard AC3 rate, then you get no sound out
of your digital amp as the AC3/DTS stream is not framed correctly
due to differing bitrates on the SPIDF line. The workaround is to
enable timestretch as this reencodes correctly and then all sound is
good. This happens on most of our (AU) HD channels.<br>
<br>
HTH<br>
mark<br>
</body>
</html>