• Keyboard input now works correctly when there's no joystick connected
• Stripe recording (see http://ahefner.livejournal.com/13165.html)
• "Screenshot movie mode" (toggled by Control-F12)
• FUSE filesystem support, disabled by default (see http://ahefner.livejournal.com/14789.html)

1. On 32-bit Linux, with newer versions of libmpg123 than my Debian-running laptop happens to have, the compile-time choice of large file support breaks binary compatibility with the libmpg123 library, wreaking havoc with the FFI bindings. Specifically, if large file support is enabled, a number of symbols change names, e.g., mpg123_open becomes mpg123_open_64. This is irritating and not how I'd have done it (for instance, I don't think the version number of the shared library changes to indicate the break in compatibility), but I could've easily worked around it in mpg123-ffi by detecting which version is present at the time the library is initialized. I very nearly did so, were it not for the following problem:


2. On 32-bit Linux, due to the desire to have properly aligned data when using SSE instructions, recent versions of GCC provide support for aligning stack frames along larger boundaries, such as 16 bytes. The mpg123 developers seem to take this support as sufficient justification to ignore the platform ABI, introducing dubious stack alignment checks at every entry point to the library. This is not something I know how to work around from the CFFI binding in a reasonable fashion, so for the time being I've given up on adapting to such hostile versions of the library. Fortunately, I've absorbed enough trivia eavesdropping on the SBCL hackers on IRC to know that Darwin uses 16 byte alignment for precisely the same reason, so SBCL must support it, and after a few minutes searching I hacked the align-stack-pointer macro in SBCL's x86 backend to enable the 16 byte alignment on Linux as well, which appears to work around the problem (at the cost of my build environment getting even stranger). I also rebuilt the libmpg123 library with --disable-largefile and, just to be thorough, --disable-aligncheck, and set my CFLAGS to -mstackrealign, two measures which I think should've sufficed to solve the issue even without a hacked SBCL.

Mixalot is the audio back-end of Shuffletron, factored into its own system(s) because it might be useful for other purposes. It includes a mixer which pulls audio from any number of streamer objects and outputs them to ALSA. It also includes FFI definitions for libmpg123 with some helpers for decoding MP3 files and reading ID3 tags, and a streamer class for decoding and playing MP3 files in real time. The libmpg123 portions are usable independently of the audio mixing/output code.

Most eMusic fans I've heard from are real music nuts, and are there to sample a wide range of music from relatively unknown cutting-edge acts, not to download music they could find anywhere. Imagine the clerks in High Fidelity suddenly being told that their favorite mail-order distributor is raising prices, but in exchange will now let them order ABBA and Chili Peppers records just like the chain stores in the mall.

hefner@lightworks:~$ ls -l /tmp/nesfs
total 0
-rw-rw-rw- 1 root root   8192 Dec 31  1969 chr-rom
-rw-rw-rw- 1 root root    256 Dec 31  1969 oam
-rw-rw-rw- 1 root root  32768 Dec 31  1969 prg-rom
-rw-rw-rw- 1 root root   2048 Dec 31  1969 ram
-r--r--r-- 1 root root     22 Dec 31  1969 rom-filename
-r--r--r-- 1 root root     15 Dec 31  1969 rom-hash
-rw-rw-rw- 1 root root   8192 Dec 31  1969 sram
-rw-rw-rw- 1 root root  16384 Dec 31  1969 vram

I'm fiddling with some C code, experimenting with different approaches to various subtasks, some of which depend on previous tasks. Results are valid only for the duration of the current frame. Performance matters, so I tend to comment pieces I'm not currently working on unless they're needed. For the time being, the data is often only displayed as debugging output, but sometimes the debug display is turned off, making the computation wasteful. Up to this point I'd been juggling the dependencies manually, calling each computation in order from a central point, but finally I've gotten restless to automate things. Here's some cute C preprocessor fun I bashed out a few minutes ago:

struct task {
    char *name;
    int last_time;
    int locked;
    void (*taskfn) (void);
};

#define deftask(name) \
  void task_do_##name (void); \
  struct task name = {#name, -1, 0, task_do_##name}; \
  noinline void task_do_##name (void)

static inline void require_task (struct task *task, int time)
{
    assert(task != NULL);
    if (task->last_time < time) {
        if (task->locked) {
            fprintf(stderr, "Fatal: Circular dependency on task \"%s\".\n", task->name);
            exit(1);
        }
        task->locked = 1;
        task->taskfn();
        task->last_time = time;
        task->locked = 0;
    }
}

I interface this with my code and the global frame_number as follows:

Next I define various tasks. Some depend on others:

deftask(track_motion)
{
    .. some code here ..
}

deftask(feature_matrix)
{
  .. more code here ..
}

deftask(grid_alignment)
{
    using(track_motion);
    .. yet more code..
}

Code elsewhere also relies on the 'using' macro to ensure computations are up to date. The components communicate through global state. If they didn't, and the style were more functional, I supposed I'd be blogging about how I'd implemented memoization instead. Eventually, I might rig this up to farm the computation out to other threads (though this doesn't seem like such a huge win unless I go back to eagerly computing things in advance of needing them). I'd need a parallel 'using' operator.

• $20.5 billion: Agriculture, Rural Development, Food and Drug Administration, and Related Agencies
• $57.7 billion: Commerce, Justice, Science, and Related Agencies
• $33.3 billion: Energy and Water Development
• $22.7 billion: Financial Services and General Government
• $27.6 billion: Interior, Environment, and Related Agencies
• $151.8 billion: Labor, Health and Human Services, Education, and Related Agencies
• $4.40 billion: Legislative Branch
• $36.6 billion: State, Foreign Operations, and Related Programs
• $55.0 billion: Transportation, Housing and Urban Development, and Related Agencies
• $0.1 billion (?):  Further Provisions Relating to the Department of Homeland Security and Other Matters

• Nutrition for Women, Infants, and Children (WIC): $6.9 billion
• Rural Development: $2.7 billion
• Agricultural Research: $2.3 billion ($1.1 billion for Agricultural Research Service, $1.2 billion for the State Research, Education, and Extension Service)
• Food and Drug Administration: $2 billion
• International Food Aid (P.L. 480): $1.2 billion
• Food Safety and Inspection Service: $972 million
• Conservation Programs: $968 million
• Other: $3.46 billion ($20.5 billion minus sum of the above)

• FY 2008 Participants include 2,153,250 women, 2,222,533 infants, and 4,328,516 (presumably non-infant) children. Total participants: 8.7 million in 2008. So the 9.1 million estimate for 2009 sounds reasonable.
• FY 2008 Food costs: $4.5 billion, or $521 per participant per year ($43.42 per month, as the table shows).
• FY 2008 Nutrition Service and Administrative (NSA) costs: 1.6 billion.  From the link above: "Approximately two-thirds of total costs are used to provide nutrition education, breastfeeding promotion and support, and linkages to health and other client services (e.g.,immunization; drug, alcohol and tobacco education; referrals to family and child health social programs).  The remaining third is used for traditional management functions."

• Federal Bureau of Investigation: $7.1 billion
• Federal Bureau of Prisons: $6.2 billion
• State and Local Law Enforcement and Crime Prevention Grants: $3.2 billion
• Drug Enforcement Administration: $1.9 billion
• Bureau of Alcohol, Tobacco, and Firearms: $1.1 billion

• NASA: $17.8 billion
• National Science Foundation: $6.5 billion
• National Oceanic and Atmospheric Administration: $4.4 billion
• Global Climate Change Research: "Nearly $2 billion"
• NIST Research: $819 million

• Census Bureau: $3.1 billion

• "Square rising edge" - a square wave at a few hundred Hz (220? 440? I forget.), increasing in amplitude each cycle from 0 to 127. I measured the height of the rising edge. I let this repeat 29 times and averaged the results. I screwed the program up and only captured every other amplitude level (incrementing the amplitude variable on every clock edge instead of just one).
• "Pulse 1" - Same idea, ramping up the amplitude of a brief pulse. I measured the height of the largest rising (or rather falling) edge in the viscinity of the pulse. I let this loop for 20 or 30 minutes, averaging out 1,440 samples per amplitude level. The individual ramps didn't look right, having a curious moire-like modulation as the energy of the pulse fell differently into samples, but it averaged out into a very nice curve. Unfortunately, it was different enough from the previous curve to bother me, although it shared some common features.
• "Pulse 2" - I thought I'd try lengthening the pulse, hoping I might get cleaner data. Instead I got the opposite - the resulting curve, even average over 1,300 samples per amplitude level, is extremely jagged and irregular. I haven't figured out what went wrong here