Life of a Netflix Partner Engineer – The case of the extra 40 ms

I kind of wish the author touched more on the one-frame-at-a-time aspect. Why <i>aren&#x27;t</i> they copying more data into the device decoder? It seems somewhat silly on a non-realtime OS to grab one frame, request a 15ms wait, and then grab another frame, when your deadline is 16.6ms. That essentially guarantees a stuttering playback at some point, no?<p>Is there not a better way to do this? There must be. Why not copy 10 frames at a time? Is the device decoder buffer that small? Is there no native Android support for pointing a device decode buffer to a data ingress source and having the OS fill it when it empties, without having to &quot;poll&quot; every 15ms? So many questions.

Previous discussion<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25426195" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25426195</a>

For some perspective on how other platforms try to prevent this problem, see the Multimedia Class Scheduler Service:<p><a href="https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;windows&#x2F;win32&#x2F;api&#x2F;avrt&#x2F;nf-avrt-avsetmmmaxthreadcharacteristicsa" rel="nofollow">https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;windows&#x2F;win32&#x2F;api&#x2F;avrt&#x2F;nf-a...</a><p>It was added in Windows Vista. It periodically adjusts the priority of threads to make sure they are getting enough CPU time.

In a weird way, I love tackling these kinds of bugs. It can be frustrating but it’s an exercise in logical thinking and you often learn some interesting details of lower parts of the stack, debugging techniques, etc. as you go.

This article was posted when it was new, and I still have the same opinion now as I did then.<p>Why was Netflix putting effort in to supporting a device that the vendor clearly didn&#x27;t care about?<p>This unnamed vendor was, in late 2017, preparing to launch a new device running Android 5.0 which was EoL and had not seen an update since late 2015. Android 8.0 was already out at the time. There is no valid excuse, it&#x27;s not like they were trying to offer continued support for a legacy device.<p>In a world that made sense, a company the size of Netflix should have the clout to say &quot;hey hold up here, what are you trying to push this out of date crap for?&quot;

&gt;I can’t predict all of the issues that our partners will throw at me, and I know that to fix them I have to understand multiple systems, work with great colleagues, and constantly push myself to learn more.<p>So what is his domain exactly? He went from shipping other platforms&#x2F;devices to his first Android device. So presumably, he is learning multiple operating systems? Is that practical to have working knowledge of multiple OS internals?<p>Wouldn&#x27;t they be better served by people specializing in one OS&#x2F;platform? That would lead to quicker issue resolutions as someone isn&#x27;t spending time learning a new OS.<p>(These aren&#x27;t criticisms of anyone&#x27;s ability, but rather why the scope of responsibility is so large and requires so much mental effort)

tl;dr. The root cause for their issue was this:<p>&gt; The Android thread scheduler changes the behavior of threads depending whether or not an application is running in the foreground or the background. Threads in the background are assigned an extra 40 ms (40000000 ns) of wait time.<p>&gt; A bug deep in the plumbing of Android itself meant this extra timer value was retained when the thread moved to the foreground. Usually the audio handler thread was created while the application was in the foreground, but sometimes the thread was created a little sooner, while Ninja was still in the background. When this happened, playback would stutter.

Also previously posted on HN a month ago, with 200 comments.<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25426195" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25426195</a>

Well, that was unexpectedly inspiring. I find I like building things that work, but the detective work of a challenging bug is often way more interesting!

I&#x27;m pleasantly surprised that this time the 40ms wasn&#x27;t from Nagle&#x27;s algorithm