Working as the primary blog author for XBMC can be a very humbling experience, particularly for a non-developer like myself.  As the person who sums up for users the work done by much smarter people than myself, I get to go through a process that I call “Putting on my stupid hat.” I begin by reviewing at the various Pull Requests for the month on Github or in some other way finding a topic that I’d like to describe to the user base. Then I ping the author of the pertinent code on IRC and have a conversation with him about whatever it was that he wrote.

Sometimes the results of this conversation get included in the monthly write-up, sometimes they don’t.   Typically, I try to only include oft requested features or other new additions that I think the majority of regular folk will be excited about. Sometimes it’s hard to tell what will or will not be interesting though, and on those occasions I’ll need to delve deeper into the topic.

Typically, it is these moments where I need to delve deeper into a topic when the putting on of the stupid hat occurs.

For example, when we announced XBMC for Android, a critical sticking point had to do with something called Neon. For several weeks prior to the announcement, a spirited debate was going on in internal discussion about whether we should or should not focus on Neon, whether focusing on Neon would kneecap us in the future, etc. etc. I’d tell you more about these debates, but honestly, they all pretty much blew right over my head.

When you are a non-dev working with devs, you very quickly learn to just accept that they are going to say hundreds of sentences that mean absolutely nothing to you. Heck, you also learn that software development can get so specialized that the guy working on database stuff can have absolutely no clue what the guy working on video decoding stuff is talking about. It’s little wonder that the history of software development is one constantly marred by a lack of communication. Simply entering a specific section of C++ coding is like training yourself in an entirely new language.

Anyway, what I knew was that Neon was important. I didn’t know why or what it was, but I knew it was important. After the announcement, only a few people in real life seemed to worry very much about Neon, but it nagged at me that I didn’t understand what it was. So I pulled my stupid hat out and went searching for Scott Davilla,* one of the major players in the XBMC for Android space.

*I should take a second to talk about Davilla. If you’ve been paying any attention to XBMC over the past 4 years, you know that Davilla is a smart dude. He was the main guy behind our iOS port. He’s big on OSX. The fact that he ported XBMC to iOS (i.e. the first ARM platform) laid much of the groundwork for porting to other ARM devices, like the Raspberry Pi and now Android devices. 

Scott, and, honestly, pretty much the entire rest of the team, can be very patient with the uneducated. So long as you keep following the explanations and can ask questions, he’s often willing to explain in great detail something as intense as why cross-platform cross-building is magic.

So I asked him about Neon. He told me it was a vector processor. I did not understand. He asked if I’d ever heard of mmx or sse, which are x86 (aka Intel) instructions sets. I said yes, guardedly. He said that Neon is simply an ARM instruction set which allows an ARM processor to work faster and more efficiently without needing more ghz. On a very basic level, all Neon does is allow the CPU to do a calculation on four variables at once, rather than doing 1 variable at a time. So instead of requiring the CPU to do 32 operations, it can perform the same function in a mere 5 operations.

This can be incredibly powerful on low power systems. For example, when converting 1080p yuv to y,uv (honestly, I have no idea what that means, but I guess its pretty critical for image and video display and playback or something), a typical ARM processor without Neon can perform the function in about 16ms or more. An ARM processor that has access to the Neon instruction set can perform the same conversion in less than 1ms.

This means two things. First, ARM processors that don’t have access to Neon (like the Tegra2) are almost certainly going to be slower than those that do have access. Second, ARM processors that do have access to Neon (like Tegra3) will not have to ramp up the CPU nearly as much to perform the same task, so in addition to being faster, they will also be more efficient in the battery department*.

*Curiously enough, another topic came out of this conversation. It’s somewhat ironic that we announced XBMC for Android a mere month after announced AudioEngine for XBMC, because the Android port is all about making XBMC as light on the CPU and battery as humanly possible, while AudioEngine, to some degree, is about taking maximum advantage of the CPU to output glorious HD sound with nary a thought for battery life. Those two endeavors are like oil and water and – much like any other polar opposites – require a constant, delicate tug of war within the XBMC codebase between efficiency on the one hand and performance on the other.

I learned all that about Neon, and the crazy thing is, I ultimately decided not to include it in any write up at all, because, while undoubtedly there would be numerous people interested in the explanation, the vast majority would mostly just say, “So… you’re saying I should buy a Tegra3 Android device?”  Or even better, there’d be users who would blame us for not working hard enough to support outdated hardware.*

*That’s probably my favorite thing of all!

Anyway, I’ve learned a lot of things in my time with XBMC. I learned what Neon was. I’ve had extensive explaining of json and parameters and API calls and databases sent my way. I learned that a Playlist is not the same thing as a Queue (I may write about that at some point). But most importantly, I’ve learned that the project is more important that pride.

I can’t code,* and I don’t especially want to learn to code. The typical method of making XBMC better is closed to me. But I can write and evangelize and tell the rest of the people of the world, most of whom are also not coders, just why XBMC and the XBMC Team is so awesome. And if doing that means periodically admitting to being sorely uneducated, then I guess I’m willing to hang on to my stupid hat and bear that burden.

After all, even the most refined among us are allowed to look stupid every once in a while!