intervigil.net

PCSX2 Analog Button Input

Wed, 16 Jan 2013 21:24:00 -0800

If you play games on emulators, it’s highly recommended you grab something like a SIXAXIS controller to do so with. However if you’re lazy like me and play on the keyboard, analog button presses typically aren’t emulated all that well by most keypad plugins. I hacked up this quick and dirty solution to PCSX2’s Onepad plugin to get past the dragon cave section of Star Ocean 3.

I’d like to revisit it and make it properly configurable via the GTK gamepad configuration interface, but alas I haven’t found a reason to do so yet.

Wine 1.5 and Napoleon: Total War

Wed, 16 Jan 2013 20:38:00 -0800

While I don’t play too many games any more, Napoleon: Total War is one of the few that I do from time to time. Probably the main reason I don’t play much anymore is because it typically takes quite a bit of effort to make Windows games run properly under Wine. Sometimes games require custom patches to Wine to make them work properly. Napoleon: Total War is one of those, as it requires a patch to the SetPixelFormat function to work.

Unfortunately the patch is not updated for Wine 1.5, so I’ve updated it here:

https://gist.github.com/4553809

Working on CyanogenMod

Tue, 03 Jul 2012 18:04:00 -0700

Those of you who have been following my GitHub repos in the past few months will have noted a large influx of Android related commits. While I was supposed to be working on my M.S. project, I took a lot of my free time to work on a port of CyanogenMod to my Android phone at the time, the HTC Sensation, device codename “Pyramid”. Since this was pretty much my first real go at working on the Android system (app development isn’t quite the same), I managed to learn quite a bit.

The starting point for any device supported by CyanogenMod is the device tree is the device tree, that typically lives in the /device/<manufacturer>/<device codename>. (where / is the top of the Android source tree) This repo is where device specific configuration options live. This repo can inherit from a device-class repo as well. (eg. htc/msm8660-common, for all HTC MSM 8660 devices) Most of the configuration actually lives in two main files, device_<codename>.mk (sometimes simply <codename>.mk), and BoardConfig.mk. BoardConfig.mk is where the description of device and hardware specific features goes. This includes defining the device name, CPU flags, display flags, sound flags, etc. The complete file ends up as a description of the device to the Android build system. Where BoardConfig.mk is responsible for defining a device, device_<codename>.mk is responsible for defining what packages and files go into the final device build. The Android build system largely defines targets as modules, and listing a module in the device_<codename>.mk file as a product package will cause it to be built and included in the final output. This includes all the HAL files (audio.primary, audio.policy, hwcomposer, camera, etc) as well as apps such as live wallpapers. This is also where additional files, such as those necessary for the ramdisk, configuration, etc are copied. Proprietary libraries that are extracted from the original device software are not copied here however. Due to various issues, proprietary files extracted from the original device software actually go to a directory hierarchy under /vendor/<manufacturer>/<device>. Typically a nice script will create the directories, generate the makefiles, extract the libraries, and copy them the correct place. All that is necessary is to tell the script which libraries are to be extracted. The most common method uses the proprietary-files.txt file to list all libraries needed.

Once a suitable device tree has been defined, and the appropriate files have been extracted, we can begin building. On a new device or class of devices, this typically means bringing in the corresponding HAL and other associated libraries. Typically these will come from upstream, bring provided by the chipset manufacturer themselves. (Qualcomm for the MSM series, TI for the OMAP series, Samsung for the Exynos/SMDK series, etc) This code tends to live in the /hardware/<qcom/samsung/ti> directories. Once this platform code is integrated into the build framework, work can proceed on working out the build process, and eventually on to adding device specific support. This is typically necessary as each chipset manufacturer has their own forks of the Android framework which they have then proceeded to hack up to better support their hardware. Since the patches released generally target development boards, real shipping devices (phones, tablets) typically have slight differences, either in additional DSPs for image or audio processing, or just different hardware revisions. All of this must be accounted for in the CyanogenMod hardware repositories. This is typically where all the problems lie in getting new devices supported. This is also again, why a support for a single device usually brings support for many other devices in short order. As they all share the MSM8660/Snapdragon S3 chipset, work on the pyramid device helped enable doubleshot (MyTouch 4G Slide), shooter (Evo 3D), and even Samsung Galaxy S2 US variant support.

The major shortcomings lie primarily in the lack of code and documentation for many of these devices though, making it difficult to get things working for which no code has been provided. This typically means the camera, and sometimes the RIL (radio interface layer). Camera support in particular, continues to be the bane of CM developers, as nearly everything necessary remains proprietary, and hidden.

As is with any software project, once you become familiar with the infrastructure, work proceeds much faster, as the ville (HTC One S) port I’m working on currently is closing in on full functionality, while the pyramid port took a bit more time. Currently I continue to work on the pyramid as well as the ville, and am working to improve MSM8960/Snapdragon S4 support in CyanogenMod. You can keep up to date with my work on my GitHub, as well as the CyanogenMod Project code review tool. Additionally, you can learn more about this from the man himself, as Cyanogen gave a talk recently on this very subject.

Ubuntu on the MacBook Air 4,1

Wed, 30 Nov 2011 14:51:00 -0800

Finally found the need to have a real laptop available, so I went out and picked up a MacBook Air over the Thanksgiving break. Since I’ve gotten so used to XMonad for day to day use, it would have to be running Ubuntu. Turns out that there is an Ubuntu community wiki page available detailing what is necessary to get things going.

A script available on almostsure creates a bootable USB drive to install off of, and the almostsure post-install script takes care of installing most of the drivers and configuration you’d want. For reference, the important things (as of Nov 30, 2011) are the following:

i915 module fix, without which kernel modesetting doesn’t work.
bcm5974 module fix for the trackpad.
btusb module for bluetooth, which for some reason doesn’t seem to be working with 11.10 out of the box.
hid-apple module for keyboard, for what I assume is backlighting and function keys.
xf86-input-mtrack Xorg input module, without which trackpad gestures (two finger scroll, etc) don’t seem to work correctly.
dispad package for touchpad pausing, although I haven’t noticed it coming into use.
macfanctld package for the fan control daemon, since the default 11.10 package doesn’t seem to do much out of the box.
custom xmodmap to remap the Apple key to Alt, Alt/Option to Mod4, since my fingers expect that sort of layout.
i915 power saving mode on boot, appending i915.i915_enable_rc6=1 to GRUB_CMDLINE_LINUX_DEFAULT.
Avoid the long bootloader timeout by executing: sudo bless —device /dev/disk0s4 —setBoot —legacy from the OS X recovery USB drive.

The one thing NOT covered by the Ubuntu community wiki is the wireless driver. The MacBook Air 4,1 has a Broadcom BCM43224 chip, which is actually covered by several different drivers, b43 (if you hack around a bit), brcmsmac, and the wl Broadcom STA driver (closed source). Poking around seems to suggest that the best option is the brcmsmac module, as it is based off the open-sourced driver that Broadcom released late 2010, however owing to it’s immaturity, it still lives in the staging drivers section of the Linux kernel. It also seems to lack some features supported by the Broadcom STA drivers, namely power management, which is the main reason why I chose to use the closed source (the horror) Broadcom STA drivers available from the Ubuntu “restricted” repository under the brcmwl-kernel-source package.

The one item to note with this module is that the brcmwl-kernel-source package actually doesn’t have an updated blacklist file in /etc/modprobe.d, and will fail to blacklist the brcmsmac module available by default, potentially leading to problems. I had to add brcmsmac and bcma to the blacklist with the following:

sudo sh -c "echo 'blacklist brcmsmac' >> /etc/modprobe.d/blacklist-b43.conf"
sudo sh -c "echo 'blacklist bcma' >> /etc/modprobe.d/blacklist-b43.conf"

This prevents the kernel from loading both drivers. Most of this information was found on the ArchLinux Broadcom wireless wiki page. And that concludes all the laptop configuration I had to do. All that remains is reconfiguring my XMonad settings for laptop use!

Sound Blaster X-Fi Titanium HD on Ubuntu 11.10 Oneiric

Fri, 14 Oct 2011 01:55:00 -0700

I took the plunge and upgraded my main machine to 11.10 from 11.04 today. Altogether not too bad since underneath the much maligned Unity lies compiz and ccsm still configures everything I actually care about. The one thing that did break on upgrade however was my sound. I happen to have a Sound Blaster X-Fi Titanium HD (etc etc), which according to Google searches, seems to be the source of quite a few people’s headaches. Specifically, the X-Fi Titanium HD is recognized by the snd_ctxfi driver, but prior to approximately 6/14/2011, it was recognized as an older model, which caused improper behavior, and if you were quick on the kernel logging, yielded messages similar to these:

[ 4881.961765] SB-XFi 0000:02:00.0: setting latency timer to 64
[ 4918.787949] SB-XFi 0000:02:00.0: PCI INT A disabled
[ 4918.787955] ctxfi: Something wrong!!!
[ 4918.787969] SB-XFi: probe of 0000:02:00.0 failed with error -1

Quick check on gmane.linux.alsa.devel shows that this fellow Harry Butterworth has put a lot of effort into patching up the driver to support the new card in these messages. The ALSA project’s git repositories show that these three patches are required to make things work:

Patch1

Patch2

Patch3

Now that I have the requisite background info, it’s time to get to solving the problem. At the time of this writing (10/14/2011), the version of the Linux kernel package Oneiric uses is 3.0.0-12.20 (full package: linux-image-3.0.0-12-generic). Let’s start off by fetching the source for the kernel with:

sudo apt-get install linux-source

This places the Ubuntu kernel source at /usr/src. We need to go there and unpack it somewhere useful.

mkdir ctxfi-module
cd ctxfi-module
cp /usr/src/linux-source-3.0.0.tar.bz2 .
tar xfj linux-source-3.0.0.tar.bz2

We now need to patch the unpacked kernel source with the proper patches from above. In this version of the source (linux-source-3.0.0-12.20), patch 1 has already been included.

patch -p1 < /path/to/patch2     
patch -p1 < /path/to/patch3

We need to now build our new kernel module. I found useful directions at the Ubuntu wiki page on custom kernel builds. Before doing that however, I noticed my current linux-headers package didn’t have the PCI_ID for the X-Fi Ti HD, so I added this line:

#define PCI_SUBDEVICE_ID_CREATIVE_SB1270 0x0062

/usr/src/linux-headers-`uname -r`/include/linux/pci_ids.h

file at line 1308, as in patch 1. Then I followed the make directions in from the Ubuntu wiki.

make -C /usr/src/linux-headers-`uname -r` M=`pwd` KBUILD_SRC=`pwd`/../../.. modules
sudo make -C /usr/src/linux-headers-`uname -r` M=`pwd` KBUILD_SRC=`pwd`/../../.. modules_install
sudo depmod -a
sudo update-initramfs -u

This installed the snd_ctxfi.ko module to:

/lib/modules/`uname -r`/extra/snd_ctxfi.ko

From there it’s a simple matter to rmmod snd_ctxfi and insmod your newly patched one. This got sound working for me again.

UCLA VPN with NetworkManager

Tue, 04 Oct 2011 18:00:00 -0700

I used the following to get set up in Ubuntu. Connecting to IPSEC VPN requires installing network-manager-vpnc-gnome, which will pull in the required packages. Let’s do that by running sudo apt-get install network-manager-vpnc-gnome Next we need the settings, which can be pulled from the PCF file, or the PDF on the BOL website. (Requires login) NetworkManager requires the following:

Gateway: vpn.ucla.edu
Group name: <group>
User password: <your BOL user password>
Group password: <decrypted group password>
User name: <your BOL user name>
Domain: blank
Encryption: Secure
NAT Traversal: Cisco UDP
IKE DH Group: DH Group 2

I used the pcf2vpnc program to obtain the relevant group info from the PCF. The pcf2vpnc program should have been installed by the vpnc package, and can be found on Ubuntu at:

/usr/share/vpnc/pcf2vpnc

Lastly it’s important to allow IPSEC passthrough on your router should that not already be enabled.

Less Coding, More Reading

Tue, 27 Sep 2011 23:30:00 -0700

In short, I’m back at school, where the objective is to read lots, but not to write as much.

Someone mentioned to me while I was working at Google that it’s more interesting to build things than measure things, which was one of the most notable things I took away from the internship.

As for the MS thesis/project, the hardest part is still starting, and I still lack a good idea in the partitioned global address space topic area to build upon yet.

My Summer at Google

Mon, 05 Sep 2011 21:42:00 -0700

I’ve been working at Google this summer as an intern, which is part of the reason why there haven’t been any updates to any of my things. (This blog, MicDroid, etc) They say Google is a place that engineers disappear into, and are not heard from again, and that seems somewhat true for me this summer. The other part of it is simply that my life has become busy, and I’ve had to make some sacrifices in what I spend my time on.

If there’s one thing that’s happened fairly frequently, it’s that people are interested in what goes on at Google. Today I’ll attempt to talk about some of the things I found interesting.

Please note: these are my personal views, they are not meant to be official announcements of any sort, nor are they in any way endorsed by Google.

Let’s begin with what I’ve learned this summer at Google.

Python: My projects this summer were primarily Python based, with a small amount of C++ on the side. I estimate I wrote around 3KLOC worth of Python, and around 500LOC worth of C++. Needless to say it’s great to learn another language, and for the Python lessons alone, this summer was worth it. One of the nicer things about learning Python at Google is that “correct” behaviors are enforced by the company style guide as well as code reviews. The best part about Python for my project was that it reduced the logic of the program to data structure manipulation.
Scripting ability: Since my project involves managing a fairly large sized fleet of machines, being able to script fluently using the usual bash tools (awk, grep, sed, etc) is important to successfully doing my job. A related lesson to this is to realize when your scripting has gotten out of control. After a certain level of complexity, perhaps it is better to fold the script functionality into a full-blown program.
Dependencies matter in building large distributed systems: I accidentally triggered a DDoS using the entire fleet of machines because of a set of changes that introduced a dependency on an external service. As it turns out that external service was unable to handle the load of the entire fleet of machines because that was beyond the designed usage of the service. Since then I’ve been a lot more careful in invoking library functionality that may depend on external services.

Next let’s talk about how things are done at Google.

As expected of the engineering-driven culture at Google, the toolchain for working in the main Google source tree is pretty heavily developed.

Google’s build system is fast. This blog post series provides a more in-depth look at it, but the short description is that it caches build output across the entirety of the main source tree to avoid having to do unnecessary compilation. Because of this, the large majority of build work done are actually retrieved from cache, leaving the builder very little actual work to do. Rebuilding my summer project typically takes less than 10 seconds.
Code search is very powerful. This blog post introducing public Google Code Search mentions that public Code Search is based on an internal tool that is very widely used. Internal Code Search is several orders of magnitude more powerful than the public variant, so much so that I typically browse through code in Chrome rather than the terminal.
Code reviews are required for any code that goes into the main tree (especially for interns!). Google has actually opened up a variant of their code review tool on Google Code. There is also an article and tech talk by Guido van Rossum available as well. I actually liked Google’s tool quite a bit, since I basically tracked my tasks and TODOs through it.
Code style is enforced through code reviews, style guides, and the presubmit process, as mentioned earlier. This leads to code of relatively uniform quality—quite a contrast to many other places I’ve worked before.
Git at Google. Google is known for being a Perforce company. It turns out there is quite a bit more to the Perforce system at Google than just that though. Also, the engineers have written a Git interface around Perforce, and it works relatively well. This lets me feature branch as much as I want while allowing me to make bugfix branches when necessary. Very useful.

Infrastructure at Google is actually quite interesting too. Having to deal with a lot of machines also equates to having a good amount of tools to deal with them as well.

Google’s VM management system is called Ganeti. It’s been open-sourced, and the project page details that it’s built around Xen/KVM. Ganeti is a layer above Google’s vast datacenter resources. There’s a fairly well developed set of tools around making Ganeti programmable as well.
Building and deploying to our machines is done through a combination of a constant integration system that produces debs, APT, Puppet, and Slack.
A good sysadmin needs to not only know the system inside and out, but needs to be able to script and program their tools as well. This is something I really need to work on.

In addition to being known for engineering prowess, Google is also known for being an interesting place to work.

It’s typically said the company is opaque to those on the outside, but transparent to those on the inside. Engineers are given access to almost everything, including source, documentation, information (including non-engineering related info), etc about nearly all Google projects. Additionally, there’s no particular embargo on talking to engineers working on other projects, so it’s not uncommon at all to hear a lot of details about other projects over lunch. There’s just a general openness regarding information inside the company.
There’s just as much complaining about Google products inside the company as there is outside. Especially with the recent launch of Google+ and the inconsistent real name policy that accompanied it, there has been just as much debate inside the company as there has been outside. So to those of you who have fallen victim to the real name policy, we feel you.
Along with the openness of information, internal public discourse about what the company is doing has many avenues, from mailing lists to groups in the company, to all company meetings. It’s great to be a part of the larger discussion concerning what the company is doing.
Google is a very strong proponent of dogfooding. Google employees can (and do) test early builds of almost any Google product before general release. Along with this comes the discussion of future features and products, of which there is quite a bit going on.
At least for the teams I was working with it felt like Google was very bottom-up, where we work on a small area of the team mission each day, rather than take direction on a specific product or feature. I’m not sure if this is due to my team not being a strict product team, but it sure does feel like each day you get to choose to devote your time to something that furthers the team mission. Personal ownership of what you’re working on is also pretty high, at least in the team that I work with. It’s definitely not on the same level as a startup, but it’s quite a bit nicer than some of the other places I’ve worked at. Word across the internet says things are changing across Google in this regard though, but it didn’t affect the teams I was in touch with.
There is a HUGE amount of information inside Google. This information is about nearly everything Google related, from product information, code documentation, tutorials, internal tools, what’s for lunch, parking, traveling, personal projects, etc. Not all of it may be up to date, but the information is definitely there. One could waste days just learning about Google history, how Google works, etc by reading documentation and sites inside.
There is a slide in one of the Google Mountain View buildings. A slide. I couldn’t find it. Maybe next time.

I’m definitely going to miss working at Google (and not just for the free food!).

I am going to miss the (relatively) consistent code style. Having worked at several places where there was no real style guide, being able to actually READ other people’s code was quite pleasant.
The tools (those mentioned above, and some that weren’t) make life quite a bit easier, especially the code search. I am seriously going to miss how useful the code search system was. In fact I’m already thinking about a possible system that hooks into Git repositories…
Working on a large distributed system is something I haven’t done before (the systems at Supercomputer Center were quite a bit smaller). It’s got it’s own unique issues, but overall it is quite fun to be able to work on.
It’s easy to find information at Google (who would have guessed?). Even if what you find is not current, at least it gives you a starting point to get more information. Additionally, there is a LOT of really fascinating information lying around internally. I just wish I had more time to ingest more of it.
Free food. (naturally)

There are a few things that I did find irritating while working at Google though. Here are some.

Some common usages of infrastructure require approval. This takes time away from useful implementation time and slows down the overall pace of work. I can understand why they require approval, but sometimes it seems rather arbitrary.
Not all the information is up to date. It’s very easy to find old documentation, or deprecated systems. Sometimes there isn’t even new documentation yet. This can also make it difficult to find the RIGHT information. Usually the solution here is to ask, but it nothing breaks up your workflow like finding out you were using a deprecated or undesired feature.
Not Invented Here syndrome is supposedly one of the big problems Google faces, however I didn’t actually run into it too much (or maybe I don’t know of enough outside systems to know I’m running into it). I do think that the existing code/build/repository model makes it difficult to integrate 3rd party code however.

Overall, Google has been great to me this summer, and I really think I would enjoy working there in the future (provided this post doesn’t disqualify me, oops).

How to Put Your Audience to Sleep

Fri, 27 May 2011 13:04:00 -0700

I’ve found that in the short time I’ve been in graduate school, I’ve had to listen to a lot of presentations. I’m not saying I can give a good presentation, but I can surely tell you what makes a bad one. Here’s a foolproof way to make sure your presentation is just as bad as many I’ve listened to already.

Step 1: Read off the slides

This one is pretty obvious, but it’s amazing how many presentations still do it. Everyone can read for themselves, the audience doesn’t need you to read for them.

Step 2: Speak very quickly

This one is bad too, especially if you are giving a talk in a language that is not your native language. It is difficult to keep pace if you can’t figure out what is being said.

Step 3: Go over every possible detail

I’ve seen this happen quite a lot when presenters go over code and feel the need to go line by line, variable by variable. I think this is very similar to the COMMENT EVERYTHING mentality of people as they learn to program. It suffices to go over the tricky bits only, or just ask for questions on the code from the audience, I’ve rarely seen an audience fail to ask questions about code.

Step 4: Talk about how unprepared you are

Just don’t do it. So very unprofessional.

Step 5: Argue/chat with your co-presenters

Save it for after the presentation.

WINE Startup Slowness

Fri, 27 May 2011 12:48:00 -0700

A while ago WINE started acting quite strange for me. It would frequently stall on startup, taking upwards of 30 seconds to launch anything, even builtins like winecfg, wine explorer and the like. Different WINE revisions, different kernels, different sound subsystems, performing wineboot —update, none of these solved my problem either.

Turns out this whole mess is caused by CUPS! I had CUPS configured for a printer several years ago, but the printer died last year, and I haven’t bothered to replace it since. Well, due to this bug, it turns out WINE is querying CUPS on startup and finding a badly configured setup! I removed my poor old dead printer, fixed my CUPS setup, and the problem went away!

Shrinking

Fri, 06 May 2011 14:41:00 -0700

I’d like to take a moment to talk about doing research. I’m currently working towards obtaining my MS degree, which entails either completing a thesis, or passing a (difficult) test. I think the thesis route is generally more useful as a whole, even though it’s so much more scary, which is pretty much why I’m headed that direction. I’m theoretically doing research in multicore systems/parallel languages, although it really is difficult to come up with a testable, unique idea. Of course, if that wasn’t the case then everyone would be doing it.

In any case, recently I’ve been reading a lot about PGAS languages, particularly UPC, and the runtimes associated with it. The main component that enables performance on distributed systems is RDMA functionality, which in the Berkeley UPC case, is supplied by GASnet, a communication library that abstracts the underlying communication fabric (Infiniband, Myrinet, Ethernet, etc) for high performance remote memory access. Now, where things get interesting is that the HPC community seems to have agreed to some extent that the SPMD/PGAS model is an interesting candidate for future computation, most prominently due to CUDA, as NVIDIA’s graphics cards have enabled some incredible numbers on the latest TOP500 listings. Since today’s commodity chips actually derive quite a bit (more than you expect) from yesterday’s supercomputers, any sort of interesting functionality enabled by the communication network of today’s supercomputers should be applicable to a future many-core (32+) chip. The key point here is that although the appearance of the system is quite different (think Jaguar vs TILE64), the architecture is really quite similar, because as the number of cores on chip increases, the need for a sophisticated communication network, very much like those found in today’s massive supercomputers, becomes much more apparent. It is here that my research efforts are currently directed.

While all this is well and good, my problem is that I’m still lacking “the idea”, although I have a suspicion that is due to me searching for some grand unifying theory of many-core systems as it were, instead of concentrating on finding some salient point of interest and digging from there.

Algorithms for Interviews

Sat, 19 Mar 2011 15:00:00 -0700

I didn’t expect to be this busy with stuff this quarter, class projects and such have been taking up all my time, and I STILL haven’t gotten around to finishing the resample/background instrumentals functionality for MicDroid.

So here’s a short list of what I HAVE been working on this quarter:

1. UCLA CS 259 project: using high level synthesis tools like Autopilot to generate a custom FPGA for accelerating medical imaging benchmarks.

2. Summer internships and jobs: I’ve interviewed with (or am still interviewing with) Google, Intel, Amazon, Adconion, Quantcast, Riverbed, and a startup out of downtown LA.

3. UCLA CS 180: yes, the algorithms class I didn’t do so well in as an undergraduate class is back!

As an undergrad majoring in Computer Science, the one class that will get you a job is going to be your algorithms class. It’s also one of the few classes I didn’t do so well in as an undergrad, which is why I’ve got to take the course again as a graduate student. That said it doesn’t help that it feels like a remedial course this time around. Still, the timing was incredibly useful since there is a lot of interviewing to be done this quarter, so reviewing things like hash tables, stacks, tree traversal, sorting, and big-O notation in class was a great help.

Big-O notation surprisingly is by far the subject that comes up the most, since every interviewer ever will ask for the (typically time, sometimes space too) complexity of every algorithm you design during an interview. Reviewing average-case complexity for things like hash tables and quicksort is also worthwhile, since those questions do (and did for me) come up.

Next up is tree traversal, which is surprisingly common, most typically in the context of search, pointers, and recursion. The most common questions I’ve heard this year ask for either tree comparison or search. Usually this involves designing a tree structure, including nodes using pointers, or references, followed by implementing a recursive search implementation of depth-first search. The best advice I have for this is to keep things simple, and be very familiar with your language of choice.

Sorting is a perennial favorite for interviews, since sorting algorithms cover the entire range in time and complexity. But for an interview, there’s no need to know all the sorting algorithms in existence, just pick one simple one with linear time complexity, and another with O(log n) complexity, and that should be enough. It’s important to be able to re-implement your chosen algorithms from scratch on the fly. I’ve had a few interviews where I had to do this as part of a larger question, so make sure to practice!

The last, most interesting point I’ve noticed about interview questions is the frequent occurrence of hash tables. There are many cases where the question asked has structure such that comparison and lookup are linked very tightly, a perfect application of hash tables. A typical example question will be something like finding duplicate elements in a list, or anything that is attempting to uniquely identify some subset of data. This is where the comparison+lookup structure of the program lies. When the interviewer is unsatisfied with the time complexity of the problem, I have found they are frequently looking to speed up some part of the algorithm through use of a hash table. Just be certain that it is completely clear a hash table lookup is average case constant time, and worst case linear time.

My interview experience had 90% of the questions covered by the topics I’ve posted about above. The other 10% of questions tended to be more in-depth questions that link a few different topics together. I’m looking forward to finishing up my interviews and finding out where I’ll be headed this summer. But for now I plan to enjoy my break, and tentatively finish up some long overdue work.

Still Alive

Thu, 20 Jan 2011 23:40:00 -0800

I’ve heard T-Pain himself mentioned that the famous I Am T-Pain app will be coming to Android, and that there will be much rejoicing. What does this mean for MicDroid? Well, despite the fact that I definitely don’t have the backing of a company to equalize on features, I don’t plan on closing up shop. It will however let me work at a more leisurely pace (as if the pace I work at isn’t leisurely enough already), because there are a few things which are interesting enough to me to keep me working on this project.

Those of you out there who actually keep up to date with my commits on github will probably have noticed that MicDroid is in fact capable of background music now, albeit with some pretty serious caveats. First and foremost is the fact that in order to set a track as background music, it is required that the track be in WAVE format, and not MP3, AAC, or any of the other less popular audio formats. This is primarily because Android does not expose any sort of audio decoder (or encoder) API to developers, despite the fact that most phones have hardware capability to do so. The current workaround is to use Lame4Android to decode MP3 to WAVE, then set that WAVE as backgrond music. Ideally I’d like to add liblame to MicDroid and just decode MP3s on the fly, but the MP3 codec does in fact have licensing issues, and I’d prefer not to deal with that for now, at least not until other more interesting problems have been solved.

The other two remaining issues that I’d like to look at are echo cancellation and audio resampling. Both of these are necessary since phones may be recording at an arbitrary sample rate, while background music may be playing at a different sample rate. Since MicDroid uses a simplistic Output = Mic / 2 + Music / 2 sort of formula to mix, this means the PCM data input to the mixer needs to be sampled at the same rate. Currently I’m looking to tap CCRMA’s resample library to do this, which means reading and understanding the code. Sadly my background is in software, so I don’t have the DSP knowledge to make it a trivial task, so this may take longer than I hope. Secondly, the echo cancellation, which will make it far easier to deal with live correction (hopefully), is something else I’d love to add in. Personally I’m actually not too sure there’s a lot that can be done, due to the lack of any low latency audio API in Android, but I think it’s a direction worth looking into. The best sources for this seem to lie in VOIP software and solutions, and I’m looking into sourcing some code from Oslec and csipsimple. Again, DSP is not my strong suit, so it remains to be seen how much I can do with the code.

So in summary, there are still plenty of things left to build, and plenty of directions to expand. I’m thinking that once I get basic audio mixing capabilities functioning using resampling I will release an update with instrumental support as an experimental feature. Additionally, it is my plan to do a write up about the various audio processing that MicDroid does as well.

Until then though, I have plenty of coding to do.

Making the Magic Happen

Wed, 29 Dec 2010 22:29:00 -0800

I’ve put an updated version of Lame4Android out on the Android Market today, and while I’m glad to say it now supports decoding WAV->MP3, it does still have one small glitch, where feeding in files created using Lame4Android will not encode properly. I have a feeling that this is due to the first few bytes of the file not being skipped correctly, which causes the encoder to crap out immediately. I will have a fix for this soon.

Now, on to what I wanted to talk about. Any programmer over the span of their career will have written an API of some shape or form. It may not be good, or widely used, but they’ll have done it. This is one of those parts of programming you wish they taught everyone else in school, along with variable naming and spacing, in that you’ll wish everyone wrote their APIs like you would. It’s also one of those things where everyone can tell when there is a good API, but cannot necessarily write one themselves.

I’ve had plenty of experience (attempting) to write APIs, but the first time I truly had to worry about what I was writing was when I worked at Deluxe. At the time I was given the task of re-writing the framework on which all of the Universal Blu-Ray releases were written on, since the previous version was getting a bit long in the tooth, and did not support some of the newer base framework functionality. Additionally it was full of strange quirks and unnecessary wrapper functions. Now here I think is the crux of writing a good API: exposing the right amount of magic to the client program. What I mean by this is that the amount of magic the API does behind the scenes to provide the functionality available underneath must not be too little, nor too much. Too little magic in the API and you’re left with a nothing more than a thin wrapper around the underlying functionality. An example of this would have been the Universal Blu-Ray framework I was talking about earlier. In quite a few places the old framework would provide wrapper functions to switch audio tracks (think switching from French audio to German) that was nothing more than a wrapper around the underlying base framework’s switch audio track functions. On the other hand, too much magic in the API leaves you with a very inflexible set of exposed functionality. An example I’m thinking of would be the Android MediaRecord API. While the designers expose pretty much all the functionality a developer would need to record audio, it just isn’t very configurable. You can only record in a certain format, and then only directly to a file, not to a buffer, or to the speaker, or anything else. Nor can you (not until Gingerbread at least) apply effects to the recorded stream. In order to do any of the above, you as a developer must use AudioRecord, which only outputs to a buffer that the developer must manipulate. Too much work is done by the underlying layers, all of it magical to the client programs.

Now to get back to the point of everything though. Today I’d like to say the liblame API is finished (or as finished as a hobby project ever gets), and I’d like to say I did a good job in exposing enough magic to anyone who would like to use it. Please let me know if you do, I’d love to hear from you.

Samsung Galaxy S Redux

Sat, 11 Dec 2010 17:20:00 -0800

I’ve recently been bitten (again) by Samsung Galaxy S AudioRecord bugs, and after having to ignore it to focus on classwork for the past few weeks, it’s time to get back into it. The last MicDroid update featured improved error handling due to proper (sort of) use of exceptions instead of an Android Handler to route all exceptions to error handling code. Unfortunately this broke Galaxy S support due to what I believe is described in these posts. It appears the Galaxy S phone just locks up the AudioRecord if you try AudioRecord.startRecording() while it is initialized improperly. This behavior certainly seems consistent with the (mass of) bug reports I’ve been getting from users. I think I’m going to have to try some of the dirty hacks mentioned above to fix it.

Another project which appears not to have had too many issues with the Galaxy S series is the rather famous Sipdroid. They also have AudioRecord code which supposedly works on the Galaxy S series. They use an interesting method of delaying until the next frame is read before reading from AudioRecord again. I’m fully intending to try this method out also, since if it works, it means I can potentially simplify a lot of the complex recording code current around. Also, it could potentially mean fixing the horrible buffer size hacks I’m using right now and finally allow the Galaxy S series to take advantage of live recording.

Should I get it to actually work, I definitely plan on releasing details.

Finally, the last, best hope for the Galaxy S series is the upcoming release of an official 2.2 ROM. There have been rumors that the 2.2 ROM fixes a lot of the audio bugs that plague the 2.1 Galaxy S ROM, and should an update that fixes these fully roll out, all of these horrible Galaxy S problems should be solved. Obviously this is the best solution for everyone :)

Something else I’ve been throwing around in my head has been the fact that the Galaxy S has a relatively slow internal SD card. I’m wondering if this has any effect on recording, especially if AudioRecord.read() reads audio at a rate faster than the phone can write.

It’s problems like these that really have me looking forward to Gingerbread, as it’s OpenSL and effects pipeline support can potentially go a LONG way towards resolving basic audio functionality issues like these. Now if only we could get Google to release the source code and Samsung to follow standards and release fully baked hardware…

Holidays and Gingerbread

Mon, 06 Dec 2010 13:27:00 -0800

Google announced Gingerbread today and the list of new shiny things to play with is quite long. It includes things like a complete native API for activities/OpenGL ES/OpenSL ES/sensors, audio effect API, and NFC. Of particular interest to me is the OpenSL ES, audio effects, and AAC encoding APIs. It’s very obvious to see that these platform changes are meant to push Android gaming in a serious way. Google is hoping game developers will sign on, meaning we might see quite a few more corporate-produced games. All of this will mean a lot of interesting things for the future, especially for MicDroid. Unfortunately all of these fancy new toys are available only under 2.3, meaning we will all need to start pushing for updates from our phone providers. :)

Finally, I’d like to take a minute to talk about MicDroid and updates. Especially the fact there haven’t been too many in recent weeks. The most obvious reason for this is that I’m back in school, and classes are taking up a significant portion of my time. I’m hoping (again) to get more free time in the coming 3 week holiday break to put some fixes out for Galaxy S (which I cannot test easily), and (finally) finish up LAME MP3 support and background music import. Additionally, I’d like to take a moment to apologize to Galaxy S users for the latest update. I’m not certain where the failure is coming from, but my suspicion is the audio hardware initialization and wave writing code. I can’t really imagine going out to pick up a Galaxy S phone, but if any kind soul out there would like to lend some Galaxy S testing time, it would be much appreciated. Finally, I’m also going to be looking at integrating new 2.3 features, as well as hoping that Google drops the 2.3 source code soon :)

Happy holidays!

CUDA is PGAS

Thu, 04 Nov 2010 21:28:00 -0700

Been reading articles about Partitioned Global Address Space since a week or two ago, and I have to say, the programming model is exactly the same as CUDA. The PGAS programming model languages (most prominent of which seems to be Unified Parallel C) were originally developed for use in supercomputer class machines such as the Cray T3D, SGI Origin 3000 (I love reading about these machines!) and Beowulf clusters. The main idea of these languages is to take advantage of the copious parallel resources of these machines by splitting the memory into several levels local to each processor. CUDA does this by dividing the memory and cache available to the stream processors on the GPU into thread local, block shared, and program global. These pretty much correspond to the private, shared, and global memory areas of Unified Parallel C, with the same thread restrictions. As I mentioned earlier, threads can be blocked. This is basically a logical bundling of threads meant for use on a particular task, as UPC and CUDA have shared memory for this end. The typical use of this block shared memory is to allocate each thread a small slice of shared memory to write results into. As a result, to obtain maximum performance in both UPC and CUDA, intelligent layout of data in block shared memory is paramount.

In terms of language features, UPC and CUDA differ only very slightly, the primary differences being the more flexible memory layout of UPC and the more restricted language of CUDA. Underneath the language runtime though, the architecture is also strikingly similar. On one hand you have machines like the Cray T3D, SGI Origin 3000, etc, which can arguably be considered ancestors to today’s GPUs in a sense. The Crays and Origins of the past are typically massively parallel shared memory systems. Each compute board contains a few processing units, associated cache, and shared memory, as well as interconnects to many other similar compute boards. The memory structure of these machines can be mapped to the PGAS programming model fairly easily. Thread private data can reside in the caches present on the compute boards, while each block can be represented by an single compute board, or even a compute cabinet, with the aggregate memory used as block shared memory. Global memory can be thought of as the control/loader machine’s memory. Interestingly, while the model described above can be considered relatively intuitive, the truth is that due to the hardware implementation of machines like the T3D and Origin 3000, it was frequently the case that partitioned global address space language performance may not have been as fast as a traditional message passing approach, or may have even been implemented using message passing. This was especially true in the case of the T3D, as it’s specialized “shell” circuitry actually made the implementation of a global address space language quite difficult. In a fair amount of papers, strict comparisons against different parallel programming models are not as common as I would have liked. But let’s move on to CUDA for now.

CUDA on the other hand relies on a control/loader machine, the PC, as well to initialize running of CUDA programs. Global memory can be thought of as this control machine’s memory as well. From there it can load up and distribute sections of work to each logical thread block and associated shared memory. The processing elements (NVIDIA would have you call them stream processors I believe) of the GPU are also very similar to a compute board in that there are many of them, and each element has several processors with associated cache, and access to some of the global memory. (the memory model is more complex than I’m going into here, but IIRC, for some of the later GPUs, the number of processing elements is directly tied to memory bandwidth in a NUMA architecture of sorts) In many ways then, CUDA is the essence of late 80s/early 90s supercomputers distilled into a single add-in board for our modern PCs. Who says supercomputer technology is useless for the average consumer?

MicDroid Settings

Thu, 04 Nov 2010 19:47:00 -0700

I actually made a post on reddit about this a little bit ago, so I thought it might be a good idea to explain in more detail here.

There are an awful lot of settings available in MicDroid, and here’s a bit more explanation about what they do.

Android Settings
Prevent Screen Lock: Self-explanatory, screen won’t turn off while recording if this is on.
Enable Ads: Self-explanatory, disable this to not show ads.

Recording Settings
Enable Live Correction: Enables playback of tuned sound over speakers in realtime. Requires headphones, otherwise you get really nasty feedback. Also requires that your phone be powerful enough to run it. Realistically this means anything with an ARM v7 chip, which is pretty much all phones after the Motorola Droid 1 except the MyTouch Slide, HTC Aria, and any Samsung phone not as powerful as the Galaxy S (Galaxy, Intercept, etc).
Change Sample Rate: Allows user to change the sample rate of the recording from 44.1kHz to 8kHz. Higher numbers means better sound typically, although it does require your phone to be a bit more powerful. Also, not all phones can record at all sample rates. If you are having trouble getting your phone to record, try changing this to 8kHz or 22kHz.
Change Buffer Size: Allows user to change the buffer size (indirectly). Larger values means the buffer is larger. This value is actually a multiplier, so the difference between an 8x value and a 16x value is VERY large. Larger buffers mean there will be less skipping if your phone can’t keep up with the recording and processing. Larger buffers also take much longer to fill than smaller ones, so if you are using Live Correction, it is HIGHLY recommended you keep this number SMALL. Samsung Galaxy S* users are recommended to bump up this setting if they experience trouble recording.

Key Settings
Change Key: Self-explanatory, this allows the user to change the key the program is tuning to. For purposes of this program, minor keys are the same as the relative major key. Musically this is not exactly correct, but due to the way the program processes the notes (it looks at key signature, not the order of notes), there is no difference.

Pitch Settings
Pull to Fixed Pitch: This oddly named setting controls the degree to which the pitch you hear is your voice, versus a specific pitch (Concert A by default). Higher numbers make it sound more like a generated tone. This should be defaulted to 0.0.
Pitch Shift: Controls how many notes the output is shifted by. Setting negative numbers tends to make the sound deeper, positive numbers tends to make the sound squeakier. Usually you don’t need to change this setting too much, maybe a few notes negative if you find the default makes you sound rather chipmunk-like.

Correction Settings
Correction Strength: This aptly named setting controls the strength of the auto-correction. Higher numbers implies you want the program to make your voice sound more like the correct pitch. Leaving this at Full is generally fine.
Correction Smoothness: This setting controls how gradual the transition is from tuned note to tuned note. For a more natural sound (similar to what is used for vocals in most songs), set this to ‘Some’ or more. For the T-Pain/Madonna effect, this NEEDS to be set to ‘No Smoothing’. The abrupt transitions between tuned notes is what gives this setting it’s signature robotic sound.
Formant Correction: Allows formant correction. This option allows the following to be changed, but does nothing by itself if the Warp Amount is not changed.
Correction Warp Amount: This setting is meant to fix the chipmunk sound that frequently happens. Negative values attempt to counteract this by making the sound deeper. Positive values seem to make the sound even squeakier. I personally find that this setting is generally unneeded, as pitch-shifting tends to give a better result. Probably a better idea to use negative numbers, if at all.
Mix: This setting changes the amount of tuned (processed) sound output versus original (unprocessed) sound. Generally you want the tuned signal, as that’s why you’re running this app. :P

Default Settings
Reset to Default: self-explanatory, resets all settings to default.

*Samsung Galaxy S: These phones include the T-Mobile Vibrant, AT&T Captivate, Verizon Fascinate, and Sprint Epic 4G and US Cellular Mesmerize.

Ads, Ads, Ads

Thu, 21 Oct 2010 22:40:00 -0700

MicDroid 0.40 has been released!

Release highlights include many force close errors fixed, including some more weird async task related rotation issues. Also there have been ads added to the recording library. AdMob ads can be removed via a setting in the options however, they’re purely optional. Code for instrumental support has been added, however it is not enabled, since it only supports wave files currently, and that isn’t much use for most users. Future work primarily involves getting LAME built as a library for proper mp3 support. Hopefully this release will be relatively trouble-free, and have fixed most of the outstanding issues from 0.39. Thanks for your support!

SITREP

Fri, 15 Oct 2010 15:02:00 -0700

I’ve been pretty busy with school (I know I keep saying it) so I haven’t had as much time to devote to Android related things recently, and for that I apologize.

Android

My girlfriend made a giant Android cake for my birthday, and it was delicious! I bought a G2 that same day to replace my Nexus One, because I’ve been waiting for a high-spec Android slider on T-Mobile for nearly a year. Now all it needs is permanent root… Also, I’m selling my Nexus One, so if anyone out there is interested, feel free to email me about it.

MicDroid

The latest work available on GitHub shows that backing instrumentals are now working, although the functionality is pretty rough, and is limited to wave files only right now. The next logical step is to make the instrumental selection and playback/record functionality a little more user friendly, with a nice countdown toast (or overlay if I can find someone to do that for me), and a nice instrumental selection menu. Additionally, mp3 support via LAME will be included before I release again, since that is one of the big items people have been waiting for, and would allow music library import, mp3 saving, and MMS support (MMS requires mp3 format). This means the next MicDroid release is probably a while off. I’d like to include an ad library too, partly because I intend to get familiar with the API, and partly because ad revenue would be nice too ;) although I fully intend to leave the user an option to disable ads. Finally, if anyone wishes to help out with MicDroid development, feel free to fork at GitHub and submit patches back to me.

Tyrian

This is pretty much stalled. Fortunately OpenTyrian on the Android Market is at a very playable state. I should concentrate on getting mp3 support for MicDroid done first.

UCLA

Classwork comes first now. I don’t intend to repeat my undergraduate academic performance.