[mythtv-users] Audio Video Sync on v31 and Alsa Buffer Size

Tim Pletcher pletchtd at gmail.com
Wed Jun 3 15:32:26 UTC 2020

Hello fellow mythtv users.

I have noticed several recurring posts regarding issues with Audio-to-Video
synchronization (or lip sync) that people are experiencing after moving to
mythtv v31.  A significant change under the hood in this area is that
mythtv now uses the presentation timestamp information (which nearly all
modern video transports include) to keep these two streams synchronized.

In the synchronization approach in v31, the audio timestamp information
serves as the baseline and the exact moment of presentation of the
accompanying video frame is adjusted a little early or a little late to
always try to drive perfect synchronization. If things get too far out of
sync, the system will either drop frames of video to catch up in a larger
increments or it will rebaseline against the latest audio & video
timestamps and resume synchronizing.

One key element in this process is consistent audiotimestamp data and if
the audio playback alsa buffer is not configured to be large enough, then
quality of synchronization can suffer.  If this type of message appears in
your log file:

audio/audiooutputalsa.cpp:236 (IncPreallocBufferSize) ALSA: Try to manually
increase audio buffer with: echo 128 | sudo tee

then you really should try to increase the value of the alsa buffer as
instructed.  Consequently, the amount of alsa buffer required / requested
will differ depending on the number of playback channels in stream (e.g.
stereo source vs 5.1 vs 7.1).

I have noticed this exact msg/error appearing in several logs that have
been posted in trac tickets or forums related to av sync complaints.

As an example, I was experiencing significant sync jitter on a low end
Intel machine (Celeron N3350) using VAAPI when viewing 1080i 29.97fps
source material with deinterlacing. The system would regularly drop frames
and this made video playback not as smooth as I would like. When looking at
verbose playback, timestamp logs, I found this variability was driven by
variation in the audiotimestamp results. At the time, I had the same alsa
buffer message in the mythfrontend log that I never bothered to properly
address thinking it unimportant since i didn't hear any artifacts /
dropouts in audio playback. After fixing the alsa buffer, the timestamp
variability and associated sync jitter essentially disappeared.

See data here collected during LiveTV playback that demonstrates this:  The
y-axis scales are the same on these two plots and dip around 1550 frames on
the second plot is a channel change.

Before adjusting prealloc
Audioadjust results with /proc/asound/card0/pcm3p/sub0/prealloc value of 64

After adjusting prealloc
Audioadjust results with /proc/asound/card0/pcm3p/sub0/prealloc value of 128

Even on my more powerful frontend using NVDEC on a GT1030 card, I found
similar jitter existed if the alsa buffer was not set properly.

Unfortunately, adjustment of the alsa buffer is not persistent and must be
done upon each restart of the system. To work around this, I use a systemd
oneshot service to run a script to set the alsa buffer value upon boot.

To summarize, if experiencing occasional but recurring frame drops, you
might want to confirm you are using the recommended alsa buffer value. For
me personally, v31 playback using VAAPI on a low end intel machine is silky
smooth and better than anything I achieved on prior mythtv versions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200603/58b9e810/attachment.htm>

More information about the mythtv-users mailing list