Archive for the ‘Linux’ Category

Open High Definition Video Capture Card

February 21, 2010

Discrete Cosine Transform coefficients

The page I have created for this project over at OpenCircuits.com is here

Here is an excerpt:

Description
This project will capture High Definition Video 1280×720 at 30fps, and hopefully be capable of 60fps and maybe even 1080p. I intend to use a cheap FPGA, A HiSpeed USB PHY, and an Analog Devices Video A/D chip. I will nail down exact chip numbers later. The target platform driver and example code will be written for linux. This project is more a proof of concept and more for fun and excercise rather than to be practical. But I will take any advice and help that I can get and who knows what we might create here. Entire BOM should be less than $40 but we’ll see.

Yes I know about the Hauppage HD-PVR or whatever its called that Capures Component video at 720p. The problem is that device uses H.264 encoding, which is just way too expensive to decode, it takes a Dual Core 1GHz Machine at 99%. It is also not totally open to hacking.

Current Status

  • 04/06/2010 Adding the FPGA to the board now, external devboard is gone.  It will be a spartan3e 250 vq100 pkg.
  • 04/03/2010 Firewire Chip found that offers a High-speed parallel interface, TI TSB12LV32IPZ: http://focus.ti.com/docs/prod/folders/print/tsb12lv32.html
  • 03/25/2010 Mailing List has been added, here is the mailman link to subscribe: https://lists.sourceforge.net/lists/listinfo/openhdcapture-discussion
  • 03/24/2010 USB Chip is the USB3250. Working on schematic capture and part selection.
  • 03/19/2010 USB Chip will likely be the USB3250, the USB3318 would be slightly more difficult to put into the UTMI core from opencores.
  • 03/12/2010 Chris http://twitter.com/chrisindallas has offered to help with the USB portion of the project
  • 03/11/2010 Project now has git hosting on git://openhdcapture.git.sourceforge.net/gitroot/openhdcapture/openhdcapture
  • 03/11/2010 Added “How To Volunteer” section. Found this core that should work with the USB chip here: http://www.opencores.org/project,usb
  • 03/09/2010 Created the ad9883a part and package in Eagle. I Began researching what it takes to get the USB3318 chip to work. I am also Considering maybe using the TSB41AB1 1394/Firewire chip. USB is a PITA to work with because of the protocol overhead. If we do Firewire, it will be in addition to USB.

I am in the planning/brainstorming stages, although I have been researching this for at least the last 6-8 months.

I have a working Forward/Reverse DCT algorithm in matlab (actually Gnu Octave) that can compress an image 5:1 with little loss in quality. I have also done much research on putting a DCT in hardware. Currently the DCT will be broken down into 2 stages, and all multiplies/adds will likely be done using a very parallel bit-wide pipeline to keep clock speeds high.

Data Bandwidth Issues
YUV422 720p data comes in at roughly 1280*720*30*16 = 443 MegaBits/s. HiSpeed USB is 480Mbits/s which, after taxes, is probably not enough. Note that 720p60 is twice that. Either way using the DCT and some Huffman coding along with other simple compression techniques we can squeeze the data down a little without hurting quality too bad. My goal is to get it down to 150Mbits/s

Embedded x86 Linux Revisited

March 4, 2009

Now that flash is really cheap, why use squashfs?  Save some time and effort and use this in your initrd for a readonly flash file system.

A non-wordpress-butchered version is available here:

http://pastebin.com/f3655ef7f

Here it is, read my notes at the top for howto actually use it:


# Local filesystem mounting -*- shell-script -*-
#
################################################################
# File:
# /scripts/local
#
# Root, or / in these notes is the initrd's (busybox) root,
# not your system's root!
#
# You need the aufs module for this to work. To do this install
# aufs on your base install, add aufs to: /etc/initramfs-tools/modules
# Now using your target kernel run:
# mkinitramfs -o initrd.img
#
# make a directory, copy an initrd to it then cd to it and:
#
# mv initrd.img initrd.img.gz
# gunzip initrd.img.gz
#
# make sure aufs exists somewhere in /lib/modules//
# After modifying local script, etc do the following in the initrd's
# root folder where /bin and /lib etc is to create a new initrd:
#
# find ./ -print | cpio -H newc -o > ../newinitrd.img
#
# Now tell grub to use this initrd for a RO root filesystem
#
# Note fstab gets hosed, if you need an fstab, make sure this
# script reflects that. I use an fstab for the default initrd for RW
# and none for RO, but you can make this script use a different one for
# RO if you want.
################################################################
# Parameter: device node to check
# Echos fstype to stdout
# Return value: indicates if an fs could be recognized
get_fstype ()
{
local FS FSTYPE FSSIZE RET
FS="${1}"

# vol_id has a more complete list of file systems,
# but fstype is more robust
eval $(fstype "${FS}" 2> /dev/null)
if [ "$FSTYPE" = "unknown" ] && [ -x /lib/udev/vol_id ]; then
FSTYPE=$(/lib/udev/vol_id -t "${FS}" 2> /dev/null)
fi
RET=$?

if [ -z "${FSTYPE}" ]; then
FSTYPE="unknown"
fi

echo "${FSTYPE}"
return ${RET}
}

# Parameter: Where to mount the filesystem
mountroot ()
{
[ "$quiet" != "y" ] && log_begin_msg "Running /scripts/local-top"
run_scripts /scripts/local-top
[ "$quiet" != "y" ] && log_end_msg

wait_for_udev 10

# If the root device hasn't shown up yet, give it a little while
# to deal with removable devices
if [ ! -e "${ROOT}" ] || ! $(get_fstype "${ROOT}" >/dev/null); then
log_begin_msg "Waiting for root file system"

# Default delay is 180s
if [ -z "${ROOTDELAY}" ]; then
slumber=180
else
slumber=${ROOTDELAY}
fi
if [ -x /sbin/usplash_write ]; then
/sbin/usplash_write "TIMEOUT ${slumber}" || true
fi

slumber=$(( ${slumber} * 10 ))
while [ ! -e "${ROOT}" ] \
|| ! $(get_fstype "${ROOT}" >/dev/null); do
/bin/sleep 0.1
slumber=$(( ${slumber} - 1 ))
[ ${slumber} -gt 0 ] || break
done

if [ ${slumber} -gt 0 ]; then
log_end_msg 0
else
log_end_msg 1 || true
fi
if [ -x /sbin/usplash_write ]; then
/sbin/usplash_write "TIMEOUT 15" || true
fi
fi

# We've given up, but we'll let the user fix matters if they can
while [ ! -e "${ROOT}" ]; do
# give hint about renamed root
case "${ROOT}" in
/dev/hd*)
suffix="${ROOT#/dev/hd}"
major="${suffix%[[:digit:]]}"
major="${major%[[:digit:]]}"
if [ -d "/sys/block/sd${major}" ]; then
echo "WARNING bootdevice may be renamed. Try root=/dev/sd${suffix}"
fi
;;
/dev/sd*)
suffix="${ROOT#/dev/sd}"
major="${suffix%[[:digit:]]}"
major="${major%[[:digit:]]}"
if [ -d "/sys/block/hd${major}" ]; then
echo "WARNING bootdevice may be renamed. Try root=/dev/hd${suffix}"
fi
;;
esac
echo "Gave up waiting for root device. Common problems:"
echo " - Boot args (cat /proc/cmdline)"
echo " - Check rootdelay= (did the system wait long enough?)"
echo " - Check root= (did the system wait for the right device?)"
echo " - Missing modules (cat /proc/modules; ls /dev)"
panic "ALERT! ${ROOT} does not exist. Dropping to a shell!"
done

# Get the root filesystem type if not set
if [ -z "${ROOTFSTYPE}" ]; then
FSTYPE=$(get_fstype "${ROOT}")
else
FSTYPE=${ROOTFSTYPE}
fi

[ "$quiet" != "y" ] && log_begin_msg "Running /scripts/local-premount"
run_scripts /scripts/local-premount
[ "$quiet" != "y" ] && log_end_msg

if [ "${readonly}" = "y" ]; then
roflag=-r
else
roflag=-w
fi

# FIXME This has no error checking

modprobe ${FSTYPE}
##########################################################################
###### Mod'd by Brian Phelps aka Electronjunkie ##########################

mkdir /root/.tmpfs
mkdir /root/.rootfs

mount -r -t ext2 /dev/sda1 /root/.rootfs

modprobe aufs
modprobe loop
mount -t tmpfs -o size=20M tmpfs /root/.tmpfs

mount -t aufs -o br:/root/.tmpfs=rw:/root/.rootfs=ro none /root/
mv /root/etc/fstab /root/etc/fstab.defunct

#########################################################################

# FIXME This has no error checking
# Mount root

[ "$quiet" != "y" ] && log_begin_msg "Running /scripts/local-bottom"
run_scripts /scripts/local-bottom
[ "$quiet" != "y" ] && log_end_msg
}

High Speed Logic Analyzer FPGA

August 6, 2008
Spartan 3e Sample Board

Spartan 3e Sample Board

Many others have had the idea to build a logic analyzer based on an FPGA. I have some novel ideas that make it much easier and much more practical to accomplish this, while keeping the features of a much more expensive LA. Some qualities that make this idea unique:

  • Save Development time on the PC end Dramatically
  • Use a slow speed PC Bus
  • Sample at whatever speed the FPGA can dish out (100MHz easily for the spartan series)

The design strategies which make this possible are:

  • Use the 216Kbits of internal Block RAM (27,000 bytes)
  • Only record changes, and time value on the inputs, (dramatically saving RAM space), also making it easy to create vcd files from this data
  • Use the PC serial port (UART + Level shifter) or ft232r
  • Create a vcd file from the vcd-like dump
  • Use gtkwave on a PC to view waveforms in the vcd file
GtkWave in action, viewing a simulation

GtkWave in action, viewing a simulation

Limitations and Tradeoffs

Unforunately, as with any engineering task, there are numerous trade-offs. This design maximizes usefulness for my standard logic analyzing needs like sniffing data on an i2s bus, or capturing a usart bit-stream.

  • The Spartan3e is only 3.3V tolerant without voltage translators.
  • We can only capture about 10,000 bit “events” or so (usually enough though).
  • Triggering will be kept simple to keep the overall design simple (wait for a low signal or high signal).
  • Uses independent clock, so it is asynchronous to any local clock on the device we are sampling.
  • Need a PC

The constant clock limits complexity on usart / rs232 interface. Otherwise a clock must be calculated at run-time, and this is not practical. I also do not want to be limited to sampling systems with clocks. I always try to practice Keep it Simple Dammit (KISD).

Design Parts

The Hardware

I intend to start this project out on an older Spartan 3e development board. I will first create a block diagram and some logic timing diagrams. The inputs will be double buffered by flip-flops to avoid metastability caused by setup/hold violations on the asynchronous inputs. We can’t get rid of all of this, but we can minimize it. This is a common “hack” for asynchronous inputs. Just google it and you’ll see.

This project will be published on http://www.opencircuits.com.

The UI Software

I will create a simple GUI to control the Logic Analyzer (reset, set trigger, dump data). This will be based on GTK in Linux using C and uses just the serial port, so this should be easily ported to MS windows. I know you can embed GtkWave into an app, we’ll see if I get that ambitious though. You will be able to name the signals here. Grouping of signals may be added at a later date. Grouping is a feature I would rarely use.

VCD File Generator

A VCD file is an ASCII based file in which only changes are recorded. The format is simple enough that we don’t need a special library to read/write to VCD. It consists of a small header with things like the date, simulation time, and signal names. My UI program will generate a dump and call this VCD generator program to convert it to a VCD. It should be pretty simple.

Contributing

This design is intended to be open (source files and schematics are public) and anyone who is interested may contact me if they would like to help make it better or add features.

Embedded x86 Linux

October 11, 2007

Another Update: Check out the new version without squashfs here.
Updated!  I modified the squashfs and init so now the entire init script is executed properly, before it would work, but we were missing a few things in the final init stage.

DebianThis rough draft howto describes my experience, minus most of the goof-ups, of how you can setup a small x86 embedded system. A typical linux box that boots grub does the following:

  • Read the MBR
  • load the kernel pointed to by the bootloader
  • load the initial ram disk
  • execute an init script who’s main purpose is to set the environment up so that the real root file system can be mounted
  • then it mounts the FS and executes the real init script, but only after the preliminary init mounts the real root file system read/write.

Confused yet? It gets worse if you must use a read only file system like an IDE/CF flash disk. The preliminary init (ran from initial ram disk) must mount the real file system (usually squashfs) read only. It also sets up a read/write FS in RAM so that the system may store and use things later like /proc, /dev, and /var. After creating both read only and read/write file systems (FS) it merges them with the unionfs/aufs kernel function in init. Then it switches root and executes the real init. There fortunately are many “LiveCD” scripts that set this up for you automatically. These init scripts (like casper in Debian) are overkill and can break an embedded system whose environment is known ahead of time. Its a bit like using this toilet paper dispenser in a mission critical application, like after eating the Habenero Hotwings and drinking 5 pints of beer from the local pub.

Also I hate all the autodetecting that comes with most live cds, power glitches and other things can trick it and it is slooowwww, Embedded systems must be reliable! Mine are 500MHz dinosaurs with no electro-mechanical parts whatsoever.

I like to boot the target filesystem root on the target hardware as an actual r/w FS first and set everything up the way I want it. This has the side effect of also testing my hardware configuration and allows me to make major changes quickly.

Then I halt and mount the target on another host to freeze the system into my own read-only install. Remember! It must be readonly if we are to run off of flash in the end, b/c of the limited writes.

Here we go………….

First create skeleton debian install:
Usage: debootstrap [OPTION]… <suite> <target> [<mirror> [<script>]]

% debootstrap sid fs-root-debian-sid

Put this file system on a drive and boot your real hardware. Set everything up the best you can (Minor changes can bee made later, don’t worry).

Back at the host:

chroot to new install or boot the real system hardware using a non flash hard drive:

install squashfs-tools, kernel, and same versions of squashfs and unionfs kernel modules
You may have to fix /etc/resolv.conf for this and other apt based installations
# apt-get install kernel-image-xxx unionfs-modules-xxx squashfs-modules-xxx squashfs-tools

unchroot, do:

Create the boot-dir:

# mkdir -p fs-boot/boot/grub

chroot, do:
# apt-get install grub

make sure mkinitramfs and busybox is installed

unchroot, do:

Copy the boot loader

# cp -a fs-root/usr/lib/grub/i386-pc/* fs-boot/boot/grub/

Copy the kernel over:

$ cp -a fs-root/boot/* fs-boot/boot/

Create the squashed FS

% mksquashfs fs-root fs-squashfs.squashfs -all-root # Makes all files owned by root

On the chrooted target, install initramfs-tools
# apt-get install initramfs-tools

Now the tricky part, edit init scripts, then create the initramfs:

chroot to the fs-root and create our squashfs script:
# vim /usr/share/initramfs-tools/scripts/squashfs

modify it to look like the included file “squashfs_script”, some highlights are:

# This is how we mount the rootfs
# substitute /dev/sda1 for what it will be on the target upon boot, I’m using a usb flashdrive
mount -r -t ext2 /dev/sda1 /.tmpfs/.mnt
losetup /dev/loop0 /.tmpfs/.mnt/boot/fs-squashfs.squashfs
mount -r -t squashfs /dev/loop0 /.tmpfs/.sqfs

# Here we create the final rootfs
mount -w -t unionfs -o dirs=/.tmpfs/.overlay=rw:/.tmpfs/.cdrom=ro:/.tmpfs/.sqfs=ro unionfs /.union

# And switch over to the new FS and run the real init, This is done as the last line of the default debian etch init script, not the squashfs script, you should comment out the old last line:

# Chain to real filesystem
maybe_break init
#exec run-init ${rootmnt} ${init} “$@” <${rootmnt}/dev/console >${rootmnt}/dev/console
exec run-init /.union /sbin/init “$@” </.union/dev/console >/.union/dev/console

Now, still crooted as the target, edit /boot/grub/menu.lst to be:

# menu.lst – See: grub(8), info grub, update-grub(8)
default 0
timeout 5

title Debian live
root (hd0,0)
kernel /boot/vmlinuz vga=791 root=/dev/loop0 ramdisk_size=100000 boot=squashfs #username=user hostname=debian persistent
initrd /boot/file1.img
boot
# Note the boot=squashfs tells init to execute scripts/squashfs
# root=/dev/loop0 is our readonly root squashfs mounted in the initscript
# ramdisk_size=100000 gives the kernel (and us) some space (100M) to work with our unionfs

We’re almost done, now make the initramfs, recall we are still chrooted

# mkinitramfs -o file1.img <kernel-version-here>
please put your kenel version int the appropriate spot above (whatever string is appended to /lib/modules on the target)

Exit from chroot and copy the resulting file1.img to your targets’ boot directory /fs-boot/boot/

# cp file1.img /fs-boot/boot/

Now copy fs-root and fs-boot files to your production device, I’m using a usb flash drive (I assume is partitioned this way):

# cp -a fs-boot/* /mnt/sda1/
# cp -a fs-root/fs-squashfs.squashfs /mnt/sda1/

Make sure that the /proc /dev and /sys directories are empty, they will be filled later by the last stages of init on the unionfs

Install grub to the target device so it will boot, I will not cover that here, its covered everywhere else on the net quite well

I usually like to test the setup under vmware or qemu, as it can save time when debugging.

Comments? Mistakes? Help me make this better. I welcome all non-spam feedback.

BRP-PACU Most Major Update Ever, File Release At Last!

October 9, 2007

File Release!!

For those of you new here, BRP-PACU is an open-source program capable of real-time audio analysis of professionally installed loudspeaker systems. The idea is to use a calibrated microphone to measure the response of a room to playing a reference signal which is usually pink-noise but could be Pink Floyd, as long as it has decent spectral characteristics. The measured signal gets fft’d and divided by the reference signal’s fft. This is captured at 3-5 locations. These captures are then averaged and flipped, then used to calibrate the system.

If none of this rings a bell you probably should read some of my other post topics, because this stuff is probably gonna bore you.

It uses GTK+, alsa-lib, gtkdatabox, fftw, and more! Many of the algorithms were first tested and simulated with Gnu-Octave. Sorry windows users, this requires alsa so tough luck, but you could try it under VMWare, VirtualBox, or Qemu, or even an Ubuntu dual boot.

From my Project News page at sourceforge.net:

Posted By: electronjunkie
Date: 2007-10-09 12:30
Summary: Current Project Status I have made significant progress now with this project. While it is still not usable in its current state, it does the following:

  • Displays FFT of Blackman Windowed audio input in real-time.
  • Displays the transfer function, H(f) = Y(f) / X(f), of the measured system (channel one divided by channel two, or output (measured) divided by input (reference)), where X(f), Y(f) is the fourier transform of the output and input respectively.
  • GUI now uses the quick excellently documented gtkdatabox library instead of the scantily documented libgoffice. Great Success!
  • Averaging function for the H(f) frame, so graph doesn’t bounce/jump in time and smoothing of the plot to make the data more readable by humans, ex: H(f) = (H(f-1) + H(f) + H(f+1))/3.
  • Impulse Response now works! h(t) = H-1(F)

*Output is in dB and Octaves like humans hear, as opposed to Voltage and frequency in Hz, with actual frequency in Hz displayed under mouse cursor.

Todo:

  • Add channel 1 & 2 signal indicators
  • Add support for more than the 4 + averaging buffer.
  • Add save as support (so that a session can be saved). This is something even the expensize programs like SMAART do not do. How many times have you sampled a room just to have SMAART or your PC lock up and lose your buffers. It will also allow you to save samples for future reference.

These items are actually trivial to implement. As an engineer all the fft/data related processing is easy to me, the hard part has been the programming read tape (fixing Makefiles to include libraries, using the libraries API’s). But I have learned some excellent concepts along the way.

Currently we are using one thread for the gui/fft app and one thread to obtain the audio. I’ll probably separate the gui from the fft thread, so that I may change the audio thread to a callback instead of polling. Right now I just want to make it work, then I will optimize the coding later.

The code will be released at version 1.0, as it will not be released until I have tested for memory leaks, and actually used it to calibrate a sound system. RT60, and other measurement features will be available in later version releases.

BRP-PACU

August 31, 2007

Update! fixed link that sourceforge somehow broke.

BRP-PACU

Brian’s Reasonably Priced Professional Audio Configuration Utility

Audio Engineering With Linux Part II

BRP-PACU in action capturing noise.

File Release today! The code is GPL. To all you MS windows folks out there this means the program is free as in it costs $0. It is also free to use, distribute or even sell, but the source code must be included (upon request) and it must retain the GPL license. Contact your lawyer for more details on legal redistribution.

Un/fortunately it will not run under MS Windows, unless someone decides to modify my code to do so. I may decide to distribute a Linux VMWare player image so that MS Windows folks can use it. There won’t be a huge quantity demand for this software, but those that have a use for it will be desparate enough to use a virtual machine. If someone would like to donate money I will port it to MS Windows. Make me an offer.

Here is a brief description of the project:

Currently there is only overpriced Live Acoustical Analysis ($600-$1200) software capable of performing the transfer function of FFT’s for sound system configuration. This is ridiculous considering the trivial nature of the concepts, but understandable since there is only a limited audience. There does not seem to be an Open Source Version available. And there definitely is no software available under Linux.

This project is written for engineers who configure professional audio systems. It’s main feature will be the ability to take multiple sample transfer function plots (output FFT / input FFT), average them together, and flip the averaged plot to aid in final equalization. Nearly all Professional Audio Engineers use this function now rather than the older Real Time Analysis method because it is quicker and just as precise. This technique is powerful and quick, but very difficult to master, perform properly, and requires a special microphone and mixer to do correctly.

This project will also be able to provide a simple FFT plot to aid in finding room modes and quick audio verification.

This Project uses the FFTW package, libgtkdatabox, GTK+, alsa, and is programmed in C, and runs under Linux.

I currently have a dual threaded program, one which collects audio data, and one that performs the FFT and plots the results. It currently is a full featured audio analysis tool capable of finding the delay automatically in a system and is able to find both the transfer function and the impulse response of an audio system.

Making Your Computer Your Slave with Linux

August 25, 2007

Mr. Slave

And learn some stuff too while you’re at it.

Or how I learned to stop fearing my PC

Linux taught me how computers and networking works through hands-on experience, I was/am constantly trying to do stuff with Linux that I have had no experience with. I knew what I had been taught in school about computers, but that often aint nothing compared to what I learn by trying to do things I had never really done before.

Linux will teach you much about computers and their capabilities, which is necessary in the real world for any EE. Embedded Linux is also the way the embedded industry is headed. Here is a simple time-line of my recent (2004), but fun Linux/computing addiction, with example projects along the way. Warning this may get lengthy:

1. Heard about Linux from fellow geek in lab, heard it was a free OS to use along with compatable free versions of Photoshop, MS Word/Office, Matlab, h/pspice, verilog simulator, firefox w/ flashplayer, etc. Check this out for more info:

linuxquestions wiki on this subject

I heard some things were much easier, some things harder, no spyware/viruses, better security, blah blah you’ve heard this all before. You should try dual booting.

2. Installed it on an old PC and used it as my primary desktop machine as dual boot. Googled any problems/errors I had such as printing, etc. Some things were a pain, but I learned some things about software and hardware/networking that I had never known before. Usually its pretty fun and valuable to fix problems you run into yourself.

3. Decided to Setup an ssh server at home (really easy) that I could access anywhere. Created a simple web page that had php scripting enabled (so you can build interactive web sites and/or control your computer from a web page). Setup an email server (easy to do, very tough to keep out spam). Learned much about setting up and traversing firewalls/routers. Learned about setting up ssh tunnels, so you could do anything from anywhere on your private LAN through ssh. Learned lots about security too.

4. Setup a full C/C++ build environment so I can compile any program I have sourcecode to from places like sourceforge.net, etc. Play around with various scripting languages like Perl, Python, especially Bash.

5. Having taken C++, learned to use libraries to build my own short simple but powerful programs that access sound card hardware and other hardware, click buttons on the screen without a mouse (from anywhere on the net), and even wrote some simple networked servers/clients that can talk to each other on a home LAN.

6. Found out that many wireless routers (like the old Linksys WRT54G) run or can run Linux (openwrt.org). Downloaded the Openwrt SDK (Software Development Kit) for building custom software for it in C. Found out that the routers also usually have 2 serial ports and 4-8 GPIO (General Purpose Input Output) for LED’s and switches. I wrote a simple program to stream audio from another PC on a LAN to the serial port on the WRT. I had a $40 wireless speaker with WPA-PSK encryption. Used two or three simple 70-80 line C programs to do it. Fun stuff.

7. Recently started putting small Linux installs on Fanless, Hard disk-drive-less (use a usb stick), computers that cost under $200. They have VGA and full audio outputs and have no moving parts. In the pro-audio world this is pretty fscking awesome b/c it will last 10 years if it is kept out of water/beer (beer is for the equipment installer, not the equipment) and at a reasonable temp.

8. I also use gnu-octave (open source version of matlab) on Linux to crunch numbers / simulate simple DSP algorithms such as Sigma-Delta Modulators, FIR/IIR filters and architectures for FPGA’s or C code, and play w/ the amazing FFT and its DCT cousins (discrete cosine transform) which has applications in audio analysis and compression.

9. I run vmware server under Linux now so that what few Windows apps I must use, I can use them from a virtual machine (simulated computer on a computer like Parallels for the Mac) in Linux. I no longer dual-boot the two OS’s. VMWare can access USB, serial/parallel ports, and sound card access. Can’t kill windows off my PC entirely b/c unfortunately in the pro-audio world, much of the pro audio equipment is MS Windows only configurable, which is sad, but thats what happens when there is a government dependent/sponsored monopoly in a particular industry, they become “defacto standards” whether they are actually better or not. The linux kernel is capable of running uninterrupted for years at a time, and some machines have been doing so. It is very robust.

Also the command prompt or “shell” (Bash) in Linux/Unix is very, very powerful and eye-opening. It is basically a programming/scripting interface to programs. You can do things with it that will blow your mind once you learn your way around. You can use programs that they were never designed for specifically, unlike GUI programs in windows.

Example:
I have done things like encode audio from the soundcard (mic input), as an mp3, streamed it to another computer over a network and played it out the sound at the remote location (home), all with general purpose applications with one long command (mp3 encoder, ssh, mp3 decode to sound card at home). Apps in the *nix world have “standard input” and “options” and “standard output” among other interfaces and can be “connected” together with pipes and manipulated in more ways than you or even the original designers imagined. GUI (Windows) programs can’t compare. Wanna download a file without opening a browser?

file example:
$ curl http://example.com/file.mp3 > file.mp3

puts the file.mp3 in your present directory

What programs are listening on which ports:

$ sudo lsof -nPi

Find all files recursively in a directory with the string “gtk.h” and print the name of the file and line it is on:

$ grep -rn "gtk\.h" *

Linux is for people who want to know their computer better. It is a different approach to computing. It will help you eliminate your fear of the Computer, and even make it your slave. I use Ubuntu now, but almost any distribution gets you going fast (CentOS, PCLinux, Suse, Fedora, etc). Avoid slackware or gentoo unless you are really gung-ho about spending hours reading a manual, installing and getting a usable system. I know that statement will get me death threats, but I believe they have their place, and its not with a newbie unless they have help. If the newbie wants to learn the hard stuff all at once, they can use gentoo or slack, but I still prefer the simplicity of an ubuntu install and maintenence.

This is a living document and more will be added later.

Audio Engineering With Linux

June 24, 2007

Update!

This project will use the alsasound (audio), libgoffice which is used by gnumeric (plots), and the fftw (fast-fourier transform analysis). This project will use these three libraries and gtk (for the gui). There are many different ways to perform this task, I chose these packages because of my experience with all of them. I am using the M-Audio Mobile Pre USB for audio I/O. Laptop soundcards stunk and typically only have one input, but if used properly, it may be possible to do this project with one input.

SM58

I am a Linux user. I use Ubuntu 6.10. I have tried other Linux distros and I currently run several. But my main laptop, is Ubuntu. This is a problem/challenge to the real world and the workplace, as most software is written for MS Windows. An example is <an unnamed pricey proprietary software package>, an audio diagnostics tool.

I usually use this pricey proprietary software package to calibrate professional sound systems using its “Transfer Function” feature (output over input). It works very well and is quick to perform, but very difficult to set up and actually perform accurately. The basic idea is that I need to be able to view the output of my sound card divided by the input to it, in the frequency domain usually done using the FFT. I have written a program that takes samples from the mic input, and send data to the line out. I have also used the fftw library to analyze samples. I have even written a few small GTK (a nice gui toolkit) programs. I think I can pull it off, but it will take some time. I am an old school C programmer. I have used many languages such as PHP, Python, Perl, but I always come back to C.

What I am going to do is write a simple GTK based program that allows me to perform the transfer function on a system. It will need to take several samples at different room locations and average them together so that I can use them to calibrate the system. It will need to be able to time-align the frequency data (delay) so that we end up with accurate curves.

Assuming I am not violating any software patents, I will release the project under the GPL on sourceforge. I have looked for a similar open-source project but it doesn’t seem to exist yet.

As I always do for any design, I will Sketch it out Before Coding™. This helps me avoid a complete rewrite midway through the coding.