<div dir="ltr"><div>Hello fellow mythtv users.</div><div><br></div><div>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.  </div><div><br></div><div>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.</div><div><br></div><div>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:</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>audio/audiooutputalsa.cpp:236 (IncPreallocBufferSize) ALSA: Try to manually increase audio buffer with: echo 128 | sudo tee /proc/asound/card0/pcm3p/sub0/prealloc </div></blockquote><div>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).</div><div><br></div><div>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.  </div><div><br></div><div>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. </div><div><br></div><div>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.

</div><div><br></div><div><div>Before adjusting prealloc</div><div><a href="https://imgur.com/DXQ6cQF" target="_blank">Audioadjust results with /proc/asound/card0/pcm3p/sub0/prealloc value of 64</a><br></div><div><br></div><div>After adjusting prealloc</div><div><a href="https://imgur.com/1tEgS3s" target="_blank">Audioadjust results with /proc/asound/card0/pcm3p/sub0/prealloc value of 128</a></div><div><br></div><div></div></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><div><br></div><div> 

</div></div><div><br></div><div><br></div></div>