I try to share required info ASAP from AMD SOC machine. Martin, please note that I start mpv itself first time right after your suggestion to watch your presentation. I didn't use it before for years. So stutters present on both i7 and AMD SOC systems I have with any background software running, more visible when system load is higher. It seems mpv give a good load to system to oblige them.
_Any_ process which require a lot of system resources including CPU time and treading (bitcoind from ports, for instance) do stutter situation worse, and increases IPIs I think. Do you accept ktrace file from AMD SOC machine with mpv working or do you need it from i7 machine too. These files are huge... Martin ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, April 3, 2020 11:06 AM, Martin Pieuchot <[email protected]> wrote: > On 03/04/20(Fri) 09:40, Martin wrote: > > > Hello, Martin. > > [...] > > When I run mpv and try to watch 720p video. In case of stutters after some > > time of watching audio flow desyncronized with video flow and mpv show > > video FPS/2 rate afterwards. > > Each time of stutter mpv increase 'Dropped' like > > A-V: 0.000 Dropped: 58++ Cahce: 1378s+154MB > > Ok so the piece of software is mpv(1). > > > I did ktrace for mpv process. I run and see by 'kdump -H ktrace.out' that > > it has > > one process ID and / mostly one-three thread used. > > But sometimes (assuming in stutter times) it jumping against treads with > > different numbers. > > Could you upload the output of kdump -H somewhere such that I could look > at it or compress it and send it? > > > Yes, IPI increased to 900-1000 when stutter appears. > > I'm going to disable step-by step each 'out of the box' software to > > determine the reason. Am I right doing this way? > > I believe it isn't necessary. From what you are saying it seems that > mpv(1) alone is the piece of software exposing the issue. > > There are multiple possible reasons for IPIs, but if the high rate > you're seeing is exposed by mpv(1), it would suggest they are related > to scheduling. > > By looking at the output of ktrace(1) we should have a better > understanding of what is happening in userland. I'd suggest you also do > the btrace(8) profiling so we can see which code path in the kernel is > responsible for the IPIs. These should allows us to work with facts and > not guesses. > > Thanks for your efforts, > Martin
