Kodi Community Forum
Linux Sync playback to display not working with 44100 Hz audio - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: Video Support (https://forum.kodi.tv/forumdisplay.php?fid=264)
+--- Thread: Linux Sync playback to display not working with 44100 Hz audio (/showthread.php?tid=377506)



Sync playback to display not working with 44100 Hz audio - motig - 2024-05-13

Hello,
I have had this problem for quite a while now and I finally have some clue as to what is causing it. When I turn on "Sync playback to display", some videos do not play correctly. The sound stops after maybe one second and the video gets stuck several seconds later - pressing the stop button makes Kodi unresponsive and I have to restart it.
It turns out this might be an audio resampling issue. All tested videos had AAC sound codec but the ones that were working had a 48000 Hz sampling rate while the ones that do not work have 44100. When the problem occurs, this gets printed into the log:

2024-05-13 11:01:59.468 T:24450   error <general>: CActiveAEFilter::CreateAtempoFilter - avfilter_init_str failed
2024-05-13 11:02:01.432 T:24783   error <general>: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer


It looks like it fails to initialize a filter from ffmpeg - probably for resampling. I have been using Kodi for years on this system so to rule out other problems I have created a new empty home directory for the Kodi user. I am currently using Kodi on Arch Linux version 21.0-4 but this problem has been present for at least a couple of versions. I am using an Nvidia GeForce GT 1030 for HDMI output (both video and audio).


RE: Sync playback to display not working with 44100 Hz audio - motig - 2024-06-06

After hours of debugging we tracked the problem into a fmod() call returning NaN unexpectedly. Then after days of learning about x87 FPU and tracing all instructions up until the FPU stack got full we found out the root cause was caused by the FFMPEG commit from 2020 [1] (rewrite from inline assembly into a NASM file) where they forgot to issue an EMMS instruction before returning from MMX implementation of yuv2rgb.

A patch fixing the problem [2] was sent to the FFMPEG.

[1] https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/e934194b6a4159b7960cabefb0dd8b998c1961e8
[2] https://patchwork.ffmpeg.org/project/ffmpeg/patch/AM9P193MB194004554ECF79F43679CFB2AFF92@AM9P193MB1940.EURP193.PROD.OUTLOOK.COM/