Continuous stuttering on Raspberry Pi 2 with ALSA passthrough.
#1
I'm running OpenELEC 5.0.8 on a Raspberry Pi 2, with a recent model Sony home theater projector and audio passthrough over an ALSA TOSLINK board (dtoverlay=hifiberry-digi). I have been running with Adjust Display Refresh Rate enabled, and Sync Playback to Display disabled.

Every so often (maybe once or twice per hour), video stutters badly and continuously for several seconds. Audio remains fine, but it looks as though a lot of video frames are being dropped. Eventually, it corrects itself. The codecinfo display's drop/skip count doesn't noticeably increase when this happens, but I do notice the W(fps) number changing a lot. I see entries like this in kodi's log file around the same time:

01:31:21 T:1587987520 DEBUG: CDVDClock:Big Griniscontinuity - CDVDPlayerAudio::HandleSyncError2 - was:6422020534.921498, should be:6422030571.303475, error:10036.381977
01:33:19 T:1587987520 DEBUG: CDVDClock:Big Griniscontinuity - CDVDPlayerAudio::HandleSyncError2 - was:6540470514.043476, should be:6540480771.523143, error:10257.479667
01:35:18 T:1587987520 DEBUG: CDVDClock:Big Griniscontinuity - CDVDPlayerAudio::HandleSyncError2 - was:6658970708.945143, should be:6658980832.653199, error:10123.708056

This happens with both 720p and 1080p files, regardless of whether the file is being read from a USB drive or the network, and regardless of the cache settings I use in advancedsettings.xml. Disabling omxplayer doesn't help (and I wouldn't expect it to, since codecinfo always shows the mmal decoder in use). I have only tested with 23.976 fps h.264 encodings.

Very recently, I tried enabling Sync Playback to Display: PLL. After just a couple hours of use, I haven't seen the problem return with this setting enabled. I was under the impression that this setting was unnecessary with audio passthrough, and I'm pretty sure I didn't need it with my CuBox i4pro. I don't even know exactly what it does, since the PLL setting isn't explained on the wiki.

Is this a known problem? Is the PLL sync method a reliable fix? What does it do?
Reply
#2
(2015-05-31, 02:36)forest Wrote: Very recently, I tried enabling Sync Playback to Display: PLL. After just a couple hours of use, I haven't seen the problem return with this setting enabled. I was under the impression that this setting was unnecessary with audio passthrough, and I'm pretty sure I didn't need it with my CuBox i4pro. I don't even know exactly what it does, since the PLL setting isn't explained on the wiki.

Is this a known problem? Is the PLL sync method a reliable fix? What does it do?

A media player always needs a mechanism for correcting sync between video and audio, either from errors in the file, or because video and audio run off asynchronous clocks (which they certainly will with USB audio).

The preferred solution is to resample the audio to speed it up or slow it down a little (typically it's < 1%) until the audio/video are in sync. It may cause a slight warbling sound (especially at the start of a file).
With passthrough you can't resample. The default option is to duplicate or drop samples. Depending on the receiver, that may produce an audio glitch (some receivers are quite good at masking it though).

The Pi has an additional solution to this which is adjusting the PLL (clock) of the HDMI display. This allows audio/video sync to be corrected without audio warbles and it works with passthrough. If it works for you it is the best solution. Unfortunately some TV/receivers don't like the clock ajustment and you may get audio or video dropouts. Most are fine with it and if this is the case you should use it.
Reply
#3
(2015-05-31, 13:47)popcornmix Wrote: A media player always needs a mechanism for correcting sync between video and audio, either from errors in the file, or because video and audio run off asynchronous clocks (which they certainly will with USB audio).
To clarify, I'm not using USB audio. I believe my HAT is using I2S. It is driver-compatible with the HiFiBerry Digi+.

Regardless, I don't think this explains why video stutters very badly for around 5-30 seconds at a time (this is far worse than a dropped or duped frame every once in a while), even when it was apparently in sync with the audio to begin with, and even with Kodi's Sync Playback to Display setting disabled. Something else seems to be going on here.

(2015-05-31, 13:47)popcornmix Wrote: The Pi has an additional solution to this which is adjusting the PLL (clock) of the HDMI display. This allows audio/video sync to be corrected without audio warbles and it works with passthrough. If it works for you it is the best solution. Unfortunately some TV/receivers don't like the clock ajustment and you may get audio or video dropouts. Most are fine with it and if this is the case you should use it.

Thanks for explaining the PLL setting.
Reply
#4
(2015-05-31, 20:26)forest Wrote: Regardless, I don't think this explains why video stutters very badly for around 5-30 seconds at a time (this is far worse than a dropped or duped frame every once in a while), even when it was apparently in sync with the audio to begin with, and even with Kodi's Sync Playback to Display setting disabled. Something else seems to be going on here.

No, that behaviour hasn't been explained.
Is it definitely an I2S audio specific issue? Can you try switching to hdmi or analogue (e.g. with headphones) and confirm if you see the same issue?
Reply
 
Thread Rating:
  • 0 Vote(s) - 0 Average



Logout Mark Read Team Forum Stats Members Help
Continuous stuttering on Raspberry Pi 2 with ALSA passthrough.00