Friday, December 12, 2008

This is, in the compute biz, what we call a "wid". Wid is short for "What I Did". Not a lot of theory, I just show you what I did to record sound from my crappy on board VIA 8237 sound chip using Linux and a $10 microphone.

The sound isn't professional by any stretch of the imagination, but it's great for voice notes and sending messages.

The Prep.

This assumes that you already have ALSA hooked up and sound is working.

Start your output volume at mid-range. The level coming in from microphones varies wildly. You don't want it too low or you'll miss it if you get it working and you don't want it too high and have it blow a speaker.

Find a test .wav file and play it with the "aplay" command. This is just to make sure everything is working. You can search for wave files on your Linux box with the command

locate wav | egrep 'wav$'

If you can't find one, pull something down from the Net.

Hook Up the Microphone.

Plug in your microphone to the proper port on your sound card. It's usually red or pink and often has a little, hard to read, glyph of a microphone beside it.

Set Up the Mixer.

Start alsamixer.

I use the command line alsamixer to activate the microphone. A graphic mixer might get the job done, but I don't feel like fiddling around them.

I put alsamixer in it's own window so I can tweak things while testing.

Use the TAB key to set the "View" Mode to "All".

Some of the capture options show up in the playback screen. To minimize looking for the right setting, view all of them at once.

Turn on the Required Options.

This is the list of options that I believe need to be set. Because different sound chips boot up in different modes this list may not be complete. Also, the values I list are just values that work for me. There's nothing magic about the them.

Use the arrow keys to move from option to option.

Move to the "Mic" option. Hit the space bar. The work "CAPTUR" should show up in red. I set the level to 71.

Select "Mic Boost". If it's listed as off (under "Item"), then press the "M" key to turn it on.

If you've plugged your microphone into a jack in the front panel of your computer, (make *SURE* the panel is wired up), then use the "M" key to turn on "Mic Front Input".

If you have more than one microphone port, make sure "Mic Select" is set to the proper microphone. I use Mic1.

Select "Capture". Hit the space bar. The work "CAPTUR" should show up in red. I set the level to 67.

Try a Capture.

Now to try a capture. I use the following, which captures sound from the microphone and plays it out the speakers (with a slight delay). It keeps running until you exit with Control-C, so you can keep it running while you tweak things.

arecord -f dat -t wav -D hw:0,0 - | aplay -

The hw:0,0 comes from Card 0, Device 0, which I got from

arecord --list-devices

Don't worry if the sound is too soft. You can fix that with sound processing software. Make sure you have "Mic Boost" on if your chip supports it.

To save your sound to a .wav file, use:

arecord -f dat -t wav -D hw:0,0 foo.wav

From there you convert it as you see fit.

What I Really Use.

At this point almost any sound program should work for you. I'm pretty hardcore command line, so I use "sox" to tweak the sound.

To turn up the sound on a .wav file under Sox use something like

sox foo.wav -v 7 bar.wav

Because sox can also do audio capture while tweaking the volume I do both in one command.

sox -t alsa default -v 7 foo.wav ; aplay foo.wav

Outro.

This is as far as I've gotten and all seems well. I'm sure I'll use this technology to change the world, but for now I'm having too much fun singing bad Sinatra.

Friday, October 10, 2008

Gnome needs a scripting language that fills the same scripting role in Gnome that Bourne shell fills for the command line.

A few days back I wrote a little script that pops up a window, gets some input from the keyboard, runs a program and then exits. I banged it out in about 2 hours in Perl using the Gtk2 library. Piece o' cake.

The problem is that I really can't distribute the program. Even if I assume that all Gnome systems have Perl, it's not safe to assume that they all have the Gtk2 libraries installed.

If I want to make my little script available I'm going to have to rewrite it in C? That can't be right! Linux always has scripts. It's one of the things that separates Linux from the lower beasts!

I decided to check out the current state of Gnome scripting on Google. Um, we're exactly where we were a decade ago. 10 years ago people were bitching about the lack of an official scripting language for Gnome and we're still bitching today.

Let's stop bitching and fix this insult to Gnomehood. For now we'll call the language "gscript" to save typing. If there is already a "gscript", then accept my apologies and lets get on with life.

What Gscript Needs to Be.

Here is a list of what I think gscript needs, in approximate order of importance.

It has to exist. This first entry isn't as stupid as it sounds. Good Gnome interfaces have existed for many of the existing scripting languages for years, but none of these scripts/interfaces are *guaranteed* to be there. Seriously, in the past decade, how many GTK/script have you used? For it to be useful, gscript has to come with Gnome. If you're using Gnome, then gnome-terminal may be optional, gscript is required!

It needs to be a Gnome scripting language, not just another scripting language that comes with Gnome. This is *important*! There has to has interfaces to all major parts of Gnome, not just GTK. Things like GConf and EggTrayIcon and user menus have to be accessible to gscript. When a new version of Gnome comes out, it comes with a synced version of gscript. It's not optional.

It should have useful defaults. Banging out a simple script should be, well simple. About as simple as this:

It should work with both GTK and Gnome. I'm not really sure what separates GTK from Gnome, but if the script doesn't need the Gnome stuff, then it should be able to use just GTK.

It should do things the Gnome way. One of the big bitches about Gnome is there's always a new way to do something. No one ever explains, in simple terms, why the new way is better and how to use it properly. If the right way to read a keypress from an international keyboard is to use the foobar interface, then gscript uses the foobar interface.

Gscript should be simple. We're not trying to replace C or Python or COBOL. The day will never come when 90% of Gnome is written in gscript. It should exist to fill the niche that shell scripts do on the command line. Anything else is gravy.

Gscript shouldn't be too simple. We've all worked with languages that are so simple that they're useless. It should have all the control structures of a real language with scoped variables and real data types. At a minimum it should have native lists, hashes, numbers and strings (anything else?). It should also have modules and classes to handle medium size programming. GTK-Bash would be a lousy choice.

It should be embeddable. Gnome is moving to things like cellphones. Why not kill two birds with one stone? Embeddable languages are useful and this will help keep the language small and simple.

Screw the ASCII code. Enough already! International support should be the default, not an add on. Those strange voices across the big salty pond are other programmers. If they speak Chinese then they should be able to script in Chinese.

Screw C! Most scripters don't come from a C background anymore because they don't need to. Computers are a zillion times faster than they were when I was a whelp, and no one is going to put gscript code in the kernel. Gscript should be fast enough to be useful. After that ease of use and flexibility are paramount.

Lets not create a new language unless we have to. I believe we can leverage an existing language.

If we have to create a new language, lets go for it! A lot of current languages are anachronistic retreads of boring old languages. Why strive to suck?

My Opinion on Existing Options.

Let's run through some of the existing options. Despite my list above, most of what's needed already exists. It's just not included with Gnome by default.

Perl or Python : Both of these play very nice with Gnome/GTK. The problem I see with these two languages are that they're both serious overkill for this problem. Also choosing one over the other would come with a pre-built pissing contest. I don't want to see their GTK libraries curtailed. I personally use Perl::Gtk2 and love it. I just don't think they would be the best fit for gscript.

Tcl/GTk : Tcl tries too hard to be simple, which makes it painful for all but the smallest of programs. If it scaled better it would have taken over the world by now. Gscript should strive to be what Tcl/Tk failed to be.

Zenity : Its great for popping up windows in shell scripts, but it doesn't really let you run actual scripts. A new gscript programmer would be able to implement zenity in about a day.

lua-gtk, guile-gnome and ruby-Gnome2 : Of all the languages I talk about, these 3 strike me as the most plausible. They fit most, if not all of the requirements, they have and existing community and, according to http://www.gtk.org/language-bindings.html, they already have viable bindings. Anyone with experience care to chime in?

Squeek : Aw c'mon. The official Gnome scripting language being Smalltalk would rock! We could write Gnome scripts that expand programmer's minds and then go give the KDE folks noogies. Pull this off and we P0WN by existing. It may not be the most practical of the choices, but I'll bet it would be the most fun.

SomeOther : I'm open to suggestions. Give me your opinions. Any other projects already started? Just remember Gscript is not trying to replace all the other scripting languages. We just need a good choice that we can get officially distributed with Gnome.

In Summary.

Gnome not having an window aware scripting language is a decade old embarrassment. It goes against all that is Linux. The embarrassment is compounded by the fact that we have a lot of options that are ready to go, or could be ready to go in, literally, a matter of days. We just need to choose one.

Once a language is chosen, then the only big step is getting it included with the Gnome base packages. Anyone have an in with the Gnome "powers that be"? If not, then wanna write a script to storm a castle?