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!