[mythtv] "Extra Audio Buffering" setting

John P Poet jppoet at gmail.com
Thu Nov 9 21:26:10 UTC 2017


On Thu, Nov 9, 2017 at 2:20 PM Peter Bennett <pb.mythtv at gmail.com> wrote:

> Hi Devs
>
> There is a Frontend General Playback setting called "Extra audio
> buffering" which mentions certain types of tuners that cause crackly
> audio. Actually it enables setting DecodeExtraAudio which then maybe
> sets a flag called lowbuffers in the demuxer (class AvFormatDecoder).
> There is lots of complicated logic around whether or not that flag is
> set and in some cases its value is saved and reset.
>
> The lowbuffers flag is only tested once in the system and if set the
> program buffers 100ms of video packets in AvFormatDecoder::GetFrame, so
> that audio is not left behind.
>
> Bug #13172 describes how playback becomes extremely jerky if you adjust
> audio sync negatively more than a small amount. The solution is very
> simple, just buffer more than 100ms in AvFormatDecoder::GetFrame. I
> tested with 1000ms and then you can successfully set audio sync to
> somewhere around -1200 before it becomes jerky. In the patch for the fix
> I settled on a figure of 250 as a good default and added for a setting
> called AudioReadAhead for the value.
>
> I would also like to get rid of the complex logic and flag surrounding
> the DecodeExtraAudio flag and replace that setting in frontend setup
> with AudioReadAhead with a default value of 250. With a value of 250 or
> 1000 it works on everything I have tried. There is no adverse impact
> that I can see, although it will take some extra memory for the
> additional buffering. I do not know why there is all the extra logic
> around whether or not to set the flag, it is safe and easy to set it all
> the time.
>
> I propose a setting that specifies number of milliseconds of audio
> read-ahead with an explanation that says to increase this value if the
> audio is jerky especially when adjusting audio sync negative.
>
> Any comments?
>
> Peter
>

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

If you want to play it safe, create a branch and ask as many people as
possible to try it.  I will.

However, if it is working well for you, even with your RPi units, then I
expect it to be fine.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20171109/a4950bc3/attachment.html>


More information about the mythtv-dev mailing list