So recently I’ve been experiencing some pretty terrible static during audio playback, and a little bit of research seems to suggest it has something to do with the default buffer sizes used by Chrome and PulseAudio. It appears that recent builds of Chrome use a much smaller buffer size of 512 while older builds used 2048. You can restore this behavior by passing the —audio-buffer-size-2048 parameter to the executable. (Source: https://code.google.com/p/chromium/issues/detail?id=178626) However as my issue was system wide (mplayer, mpd also experienced the same thing), that pointed to PulseAudio. It also appears PulseAudio sets some pretty poor default buffer and fragment sizes as well. Those can be remedied by setting the correct values in /etc/pulse/daemon.conf. The values used for default-fragments and default-fragment-size-msec should match the buffer sizes used by your sound card. Those can be viewed by starting PulseAudio with very verbose logging enabled. (Source: http://forums.linuxmint.com/viewtopic.php?f=42&t=44862)
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.
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:
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.
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:
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!
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:
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
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:
From there it’s a simple matter to rmmod snd_ctxfi and insmod your newly patched one. This got sound working for me again.
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:
Lastly it’s important to allow IPSEC passthrough on your router should that not already be enabled.
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.
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.
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.
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.
In addition to being known for engineering prowess, Google is also known for being an interesting place to work.
I’m definitely going to miss working at Google (and not just for the free food!).
There are a few things that I did find irritating while working at Google though. Here are some.
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).
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.