Return of the Bard

Recently, while prowling the net for GCW Zero goodies that might be willing to work for me on the zipit, I spotted some hints about a new release of Bard the Storyteller.  That got me thinking, maybe it was about time for an iz2s build of Bard.  I'm not sure why I never got around to it.  Perhaps I was worried the performance wouldn't be up to the level of the openwrt build, and I'd be stuck with the robotic 8KHz Kal voice instead of the surly 16KHz version.  I don't know.  Anyhow, I finally decided to give it a shot.

So I applied the old openwrt-zipit Bard patches, then tweaked the battery monitor and screen blanking code for iz2s.  I also adjusted the key bindings to move the page up and down functions onto the zipit Prev and Next keys, and added the increase and reduce functions (for volume/fontsize/speed) to the period and comma keys, as well as the volume +- rocker buttons.

It seemed to work ok, but the highlighted words seemed to jump ahead of the spoken voice quite a bit, so I dug a little deeper into the code.  I noticed some floating point code sprinkled about, here and there.  Seems like an odd choice to target small underpowered devices like the Nanonote, with no native floating point, and yet control the volume with a floating point multiply for each and every audio sample.   I switched that code to use an 8-bit fixed point volume multiplier.  I also converted the idle time check code to use integer milliseconds, like the rest of the SDL code instead of floating point seconds.  I did the same for the audio sample position timing code.  That might have made the "lip sync" a tiny bit better.  But it's hard to tell.

Here's the iz2s bard and flite executables, and a libzip that I needed to build it.

bard-iz2s.zip

I'll put together a patch file with the code changes ASAP.

But first I want to do some experiments with the rest of the voices.  I built the default set of flite voices, but aside from kal they all use floating point numbers for the data.  So they're an order of magnitude slower on the zipit.  That's ok if you want a higher quality voice, but you can't use them in bard because the text processing is too slow for realtime.  It might be nifty to fixup bard to "lip sync" the text on screen with a preprocessed .wav file, but I'd rather see about converting the voices to fixed point.  I examined some of the data and so far the largest number I've seen is around 220, and all the floats have 6 digits after the decimal point.  That range of values would probably fit quite nicely in a 12.20 fixed point format, which would speed things up enormously, and might even sound ok if the math doesn't overflow.  We'll see...

By the way, this might be a good time to mention that I finally remembered to add the missing speaker setting in the /mnt/sd0/bin/setup-alsa.sh script. 

  /mnt/ffs/bin/amixer -q sset "Right Speaker Playback Invert" on

I also toggled the identical setting in /mnt/sd0/etc/asound.state.  Without  that setting the speaker isn't really loud enough to hear.  But with it, I could almost picture myself listening to internet radio via the speaker, if I forgot my headphones.  It's certainly good enough to listen to the bard speak.


Next up, maybe a beta3 of the ultra iz2s SD card image.

Bad links (the fickle memory of the net)

Sometimes it seems the internet never forgets.  You know what I mean.  Post something you'd rather forget and it gets wedged in limbo on some far away anonymous internet cache.  Halfway between here and forgotten.  Forever.  But other times things can disappear down the infamous internet memory hole with seemingly no notice whatsoever.  A sudden transition from the crystal clarity of ones and zeros to a new state, existing only in our own feeble fuzzy memory.  Was it ever there?  Did it really happen?  I don't know, do you?

Today feels like one of those days.  IZ2S 2.05e is no more.  Just a bad link.  Sure, you can probably dig up some mention of it on the archive.org wayback machine, if you know what to look for, and when.  But good luck finding a zip file with the stuff you need.  Actually the older versions 2.04 and 2.05 are still currently available but I'm not  sure they have what I need.  Unfortunately for me, IZ2S 2.05e is an integral part of my install instructions for iz2jffs.  So now I have to come up with a new method, and then track down and fixup any links to the old way.  Yeah, I need to modify the internet memory of the past to better suit the crummy reality of the present.  Seems vaguely Orwellian when you think about it.  You can call me Winston...

Anyhow it's not an emergency procedure because flashstock is still available, and it installs an iz2jffs that's either the latest version, or the one just before it.  I can't really tell from the website.  In fact my new manual install procedure will probably end up using flashstock if it contains the right version of the tar command that I need.  Otherwise I may give up on the manual "install from tarball method" and instead create the backup files used by the flashstock script for any new releases of iz2jffs.  Only time will tell.  Or maybe it won't...

In the meantime I had already started working on my own version of IZ2S.  Sort of a super sized iz2jffs, except running off the SD card instead of the internal flash, and containing most of the goodies posted here over the years, already installed.  That's tons of stuff, so I had to trim it back a bit to bring it under 100MB or so. 

It's a lot of work, separating the experimental junk on my personal SD card from the good stuff, but I got far enough along to drop a beta release onto the internet.  It still needs tons of work, especially in the gmenu2x GUI since I tend to run things from the command line much of the time.  It boots into rockbox, because that's what I use it for most of the time -- an mp3 server for the car.  You can press the smiley face button to exit out of rockbox into gmenu2x to do other things.

I had to pull out gcc and gnu-emacs to keep the size down, so if you want them you'll have to get them from the goodie bag.  And you'll have to fixup g++ to make it work.  I tend to stay away from C++ for small things (like zipit code) so I never noticed the install was slightly broken.  A normal gcc setup uses softlinks to install the architecture dependent header files, but you can't do that on a FAT  filesystem.  For gcc I made copies and moved some files, but I forgot to do it for g++.  So to fix it you should do this:

  cd /mnt/sd0/share/gcc/include/c++/4.1.1/arm-linux-uclibc/bits
  mv * ../../bits

Then you can compile hello.cpp.  Well, at least it worked for me...

Here's the 70MB ultra large iz2s beta.  Just unzip it onto a FAT formatted SD card and it should boot up in a stock zipit.

uz2s-beta2.zip

If you'd like a working Doom, fceu NES emulator, and some other programs, you can follow the goodie bag link and install Dronz' sd0-f5.zip to get the addz directory onto your SD card.  There's a bunch of nice stuff in there.


Update:

Err... while I'm on the subject of loose screws and memory loss, I have to mention that I totally forgot about some new nethack builds that I worked on about a month ago.  

Here's a nethack ipk for openwrt that I'm 99% positive works.  Apparently I patched it for a uclibc strcasecmp bug.

nethack-openwrt.ipk

And here's an SDL nethack build for iz2s (screenshot from gp2x).

nethack-sdl-iz2s-beta1

I wonder what else I forgot...