Howto Install Boodler On A Linux iPAQ PDA

Soundscaping with Boodle on a Familiar Linux Distro'd Compaq iPAQ

Boodler is a very cool and unique programmable sound generation application for Linux. The author, Andrew Plotkin, was kind enough to respond to my requests regarding an older version (1.4) he had ported to the Zaurus that didn't function on my iPAQ (Linux) properly.

So I decided to just plow ahead and assume the Laptop version would work on the iPAQ, and yes, it worked with some ugly old-school hackery. Dan Kegel's "crosstool" provided terrific cross-compilation support for the ARM processor on the iPAQ.

 

Date: Wed, 14 Nov 2007 00:14:22 -0800
From: Todd Stiers <tas@darthracing.com>

To: Andrew Plotkin <erkyrath@eblong.com>,
Subject: Re: Boodler on IPAQ Running Linux

Hi Andrew,

Got Boodler 1.6.1 running on the (linux) iPAQ! This is huge!

"revtest.Go" is my little audio test built from your samples

root@h3600:/media/cf/tas/boodler-effects# uname -a
Linux h3600 2.4.19-rmk6-pxa1-hh37 #1 Mon Aug 14 15:51:09 CEST 2006 armv4l unknown
root@h3600:/media/cf/tas/boodler-effects# boodler revtest.Go
running "start up and run"
started!
looped!
looped!
Traceback (most recent call last):
  File "/usr/bin/boodler.py", line 163, in ?
    cboodle.loop(generator.run_agents, gen)
  File "/usr/lib/python2.4/site-packages/boodle/generator.py", line 313, in run_agents
    def run_agents(starttime, gen):
KeyboardInterrupt

root@h3600:/media/cf/tas/boodler-effects#


Steps I took:
1. Install the "Familiar GPE" Linux Distribution as per http://www.handhelds.org

2. Establish network connectivity with the iPAQ. I used the USB cradle/USBNet method to my iPAQ H3650 32MB w/128 MB CF sleeve. This way you can ssh/scp into your Linux iPAQ as a server (too cool).

3. Find, install and get familiar with using Boodler on your Linux PC platform. Be sure you have Python 2.4.

4. For the iPAQ, install python as per the ipkg packages available via the search on www.handhelds.com. Again, Python 2.4

5. Try to install boodler on the iPAQ

   a. scp boodler.py root@ipaq:/usr/bin
   b. log right into the iPAQ: ssh root@ipaq
   c. create the launch script, point to vi /usr/bin/boodler (taken from the original 1.4 ipk)
#!/bin/sh

set -e
set -o noglob

export BOODLER_SOUND_PATH=/media/cf/tas/boodler-snd
export BOODLER_EFFECTS_PATH=/media/cf/tas/boodler-effects

python /usr/bin/boodler.py $*

   d. try running "boodler". The imports attempts will fail. FOR each fail do
      i. from the Linux PC: scp /usr/lib/python2.4/<failed import>.py root@ipaq:/usr/lib/python2.4
          (use the .py files, let the iPAQ python generate any .pyc)
      ii. goto d until you get a failed attempt to load "cboodle_oss.so"
          (/usr/lib/python2.4/site-packages/boodle/cboodle_oss.so)
      iii. congrats, now it gets hairy

6. To make a working cboodle_oss.so, you will need to have a version compiled for the ARM processor. To do this, you will need an ARM compiler.

7. Dan Kegel has a great tool called "crosstool" that will make a targetted compiler for your system. (I only bothered to try because I interviewed Dan several years ago to work at Idetic/MobiTV and he's a badass).
   a. http://kegel.com/crosstool
   b. I used "crosstool-0.43", http://kegel.com/crosstool/crosstool-0.43/doc/crosstool-howto.html
   c. Following the instructions, I downloaded and untarred, cd'd and ran ./demo-arm.sh
   d. After answering questions about my various GCC paths, it ran for a long time (I went to bed sleep). This thing basically downloads and compiles a targetted cross compiler compatible with your system (I am running Fedora Core 5)
   e. When I woke up, I had a full compiler: /opt/crosstool/gcc-4.1.0-glibc-2.3.2

8. Knowing nothing about Python's distutils led me on a goose chase looking for how the Boodler *.c files get built into .o and .so files,
or how to set the compilers or options sent to the compilers.
   a. "python setup.py build" is a call to the "distutils"
   b. my PC compiler kept being called to build the .o files.

9. SO I moved my stock /usr/bin/gcc asside and symlinked /usr/bin/gcc to my new ARM compiler
   a. /usr/bin/gcc -> /opt/crosstool/gcc-4.1.0-glibc-2.3.2/arm-unknown-linux-gnu/arm-unknown-linux-gnu/bin/gcc

10. The OPTIONS distutils set up were still breaking the compile - specific complaints were gcc arguments:
   a. -mtune=generic
   b. -m32
   c. -march=i386

11. When the arguments above were removed, the build process proceeded with .o files generated in Boodler-1.6.1.iPAQ/build/temp.linux-i686-2.4/src/cboodle

12. Again, this was a manual process of running "python setup.py build", copy the failed gcc line, remove args, run again, so I got lazy:
   a. moved /usr/bin/gcc to /usr/bin/gcc.arm
   b. wrote script /usr/bin/gcc:
#!/bin/bash
#
#
args=$*
echo $args | sed -e 's/-mtune=generic//g' -e 's/-m32//g' -e 's/-march=i386//g' > /tmp/args
gcc.arm `cat /tmp/args`

13. After cranking out .o files, I got errors attempting to compile the "audio_esd.c" code. I saw the audio_oss.o had succeeded, so my solution was to comment out the extensions that were not of interest in "setup.py":

# The list of driver extensions.
all_extensions = [

        BooExtension('file'),

        BooExtension('stdout'),

        BooExtension('oss',
                libraries = append_if(('bsd' in sys.platform.lower()),
                        [], ['ossaudio']),
                available = check_header_available('sys/soundcard.h'),
        ),

        # BooExtension('esd',
        #       libraries = ['esd'],
        #       available = check_header_available('esd.h'),
        # ),

        #BooExtension('alsa',
        #       libraries = ['asound'],
        #       available = check_header_available('alsa/asoundlib.h'),
        #),

        #BooExtension('vorbis',
        #       libraries = ['vorbis', 'vorbisenc'],
        #       available = check_all_available(
        #               check_header_available('ogg/ogg.h'),
        #               check_header_available('vorbis/vorbisenc.h')),
        #),

        #BooExtension('shout',
        #       libraries = ['vorbis', 'vorbisenc', 'shout'],
        #       available = check_all_available(
        #               check_header_available('ogg/ogg.h'),
        #               check_header_available('vorbis/vorbisenc.h'),
        #               check_header_available('shout/shout.h')),
        #),

        #BooExtension('lame',
        #       libraries = ['mp3lame'],
        #       available = check_header_available('lame/lame.h'),
        #),

        #BooExtension('macosx',
        #       extra_link_args = ['-framework', 'CoreAudio', '-framework', 'Python'],
        #       available = (lambda ls : (sys.platform == 'darwin')),
        #),
]


14. The "python setup.py build" finally was "clean"

15. I found the file:
Boodler-1.6.1/build/lib.linux-i686-2.4/boodle/cboodle_oss.so
and scp'd it into place on the iPAQ:
   a. scp cboodle_oss.so root@ipaq:/usr/lib/python2.4/site-packages/boodle/

16. On the iPAQ terminal, I was able to now run the /usr/bin/boodler program:root@h3600:~# boodler
usage: /usr/bin/boodler.py [ options ] module.AgentClass [ data ... ]
root@h3600:~#

17. Using my CF card as the target (for space!), I copied over the boodler-snd and effects/ directories from the Linux PC:
   a. scp *.py root@ipaq:/media/cf/tas/boodler-effects
   b. scp -r * root@ipaq:/media/cf/tas/boodler-snd/
   (you would want to optimize/be choosey if you lack a CF card)

18. Run boodler with some content
   a. root@h3600:~# boodler hardhat.MotorRun  - success!!
   b. my own effect: root@h3600:~# boodler revtest.Go - also success!!
   c. less than 10% of the CPU is being utilized on the iPAQ, very efficient compared to my own audio generation attempts.

19. TODO - try out the event management bootmsg and -listen features. Might need to install more python as per step 5d above.

20. I can write something up for linkage if you would like, or attempt a clean packaging for the specific iPAQ distro now that I have.


Again thank you for writing this program - porting/the hacking above is  a worthy struggle. You have a very unique/interesting program here thats going to work well for my application - a background/warning/presence audio for my electric motorcycle,

http://opensourceelectricvehicle.blogspot.com/.

I plan on using the thottle position (retrievable via serial cable to the iPAQ) as events to vary the audio.

I will have to add you and now Dan to the credits!

Thanks,
-Todd