Software

Operating System - Puppy Linux 2.14


Yes, that says Puppy Linux.  I found this distribution when searching for small Live CD types of Linux.  This was by far the fastest distribution to boot, meeting my primary goal.  Secondly, it was possible to load a development environment.  This is key when trying to put together a custom Linux system.  I was able to create a master build installation on another computer, then build the tools I needed, and create packages to install on the target.

Puppy is a great distribution.  It has a modern kernel, has all the drivers, and a good deal of the packages I wanted were pre-compiled and worked.  I did however end up compiling a lot of stuff, but all in all, puppy is a great fast platform.  I did not use all the features of Puppy, and I invite people to try it out.  

I ended up using LILO as the boot loader, and mounting the root partition read-only.  I mounted the 60GB Harddrive as read/write and used it for nothing but media storage and anyhting requiring read/write access.  Another approach I used in RedHat is to run the entire operating system from an initrd, and never exit.  This is really kinda cool since the whole OS then runs in RAM.  I like this a little better because it is easier to modify if necessary, and does not incure the file read time for the whole image.
 

Why Not Windows? 

Okay, so I tried Windows.  Actually only after running a RedHat based system for a year or so did I really try windows.  I wanted instant on and all those great Frontends seem to promise the world.  All I can say is, and I know I'll get hate mail, Windows was not up to the task.

First, instant on in Windows did not work.  Yes, I used EWF and HORM.  I customized the install with nLite, used the free Windows Codecs.  However, a hybernate file with 512 MB RAM is, well, 512 MB.  Reading this from the Compact flash drive was not quick, and actually took longer to boot than the Puppt Linux installation.

Second, the Windows frontends are great, particularly RoadRunner, but they seem to have too much decoration and not enough function.  I actually had everything loaded and ready to go, even a custom skin I spent many hours developing.  When I tried out the Dolby Digital Playback however,  and could not get it working consistently in  Windows Media Player Classic, I became convinced of the error in my ways.  By the time I finished fighting to get consistent DVD playback, designed an on-screen keyboard, and worked out all the PhotoShop stuff, I realized how good I had it with Linux.  I knew Linux Dolby Digital would work, thanks to my previous experience with RedHat, and the software I chose to use was absolutely great, free OSS (more below on that).

Third, Linux allowed me to customize exactly what was loaded, and how.  I was able to create temporary file systems in ram, create a truly read-only boot partition, and support everything I wanted to do with only a PIII.  The best parts of Linux made it shine over Windows.  Customizable, extendable, simple, fast, and it works exactly the same way, every time.

Fourth, Linux is just bad-ass.  Custom boot screen, rock solid stability, everything can be scripted, and it is absolutely free.  I mean, how cool is it to say I did the whole thing in Linux?  Many people still haven't heard of linux.   So the real question is why use Windows?
 

Drivers - To hell and back?


Okay, there are some drawbacks to Linux, and although very few, they are somewhat major.  For instance, the FireWire drive did not work immediately and Dolby Digital playback had to be made to work.  Here's some more information on the drivers that made this system finally come together:
 

Firewire drives

Believe it or not, these do work out of the box in most newer Linux Distributions.  RedHat 9 and Puppy shared the issue of loading the correct modules at boot time, since I disabled any kind of drive automounting.  I got this working by editing the boot file "/etc/rc.d/rc.local" in Puppy and inserted the command:

/sbin/modprobe ohci1394 /sbin/modprobe sbp2
Now, when the system is booted, it finds the DVD Chassis every time.  OHCI1394 gives access to the firewire built into the computer, and the SBP2 allows mounting the drive.
 

Can't touch this

The drivers used for the DWW-700H are the touchkit drivers, and this manual.  They actually came on the CDROM with the screen.  To get them working at bootup, I added the following to rc.local in the /etc/rc.d directory:

/sbin/modprobe tkusb
/usr/bin/usbpnpd
/usr/bin/tpaneld

Some consideration is needed for the /etc portion of the driver installation.  The /etc/touchkit directory must not be read only, and the rest of the drivers, installed somehwere on the drive, must be relocated to a read/write partition as well.
 

Can you hear me now?

As a matter of fact, I couldn't.  I used the kernel provided liv-usb audio driver.  There was only 1 drawback: Dolby Digital did not work.  Let me 'splain.

With the SBLive 24, all audio is decoded by the board processor from the USB port and sent out of the SPDIF connector as 2 channel PCM wave Data.  The DSP (form my last page, it is the Alpine DSP) reads the decoded PCM data and plays the wave back through the ampifier.  Dolby Digital is usually compressed in AC3 format. Inside this format is a bit (NO_AUDIO) which tells the soundcard not to decode the data as 2 channel audio, but send it forward untouched.  The DSP is then required to decompress the audio data and play it back through all the speakers.  This bit was not being set by the driver when clients requested AC3 passthrough.  So I modified the driver and forced it to set the NO_AUDIO bit.  Here is my modified Driver.  Use it at your own risk.  Whenever the client asks for a sampling rate of 48Khz, the driver sends the NO_AUDIO bit to the card, and the data is passed through untouched.  Try that kind of modification in Windows!  

One might ask, how did you learn how to fix this problem?  My answer is I used a USB port sniffer and a Windows machine to send a Dolby Digital data stream and found the command packet by looking for all the commands.  When the card switched to AC3 passthrough, I saw the command packet and coded it in this driver.  I had contacted Creative, and never received an answer.  So I just did it myself.

Since I used the Kernel Driver, there was no need to insert startup commands in the rc.local file.  Bonus!