You can have all sorts of fun recording phrases and playing them back at opportune moments. Bored with some of the audible cues you get from your system? No problem. Make your own. Two programs which run at the CLI make it extraordinarily easy to do that: rec and play. I'm assuming that you have a sound card and a mic. You'll need them for this week's adventure.
Can you hear me now?
Recording a clip for whatever purpose is as easy as entering:
That starts the recorder running. You'll see the message "Send break (control-c) to end recording" in the terminal window. That's your cue to start speaking into the mic. When you've finished speaking, enter CTL-C. That's like hitting Stop on your VCR. Now you're ready to play back what you've just recorded.
Enter "play clipname.wav" at the command line. If your mic and soundcard (and volume) are properly connected and set up, you'll hear what you've just recorded. Easy cool. But wait, there's more.
Dumbing down the CLI
You can also do sound effects with rec and play. Things like echo and reverb, for example. But before we get into that, let me explain something else about rec and play. They both are actually using another program to do their audio magic. That program is sox. It's a very powerful and full-featured sound program which describes itself as "a general purpose sound converter/player/recorder."
If you open up play in a text editor (located at /usr/bin/play on my system), you'll see that it is a fairly complex shell script which takes your input, edits it, and passes it to sox. Making programs like sox more accessible is a good thing. GUIs are often meant to do that, though they don't always succeed. What I want to point out here, however, is that the same thing happens at the CLI. Tools like play and rec are developed so that more people can use and enjoy sox. Hey, remember what Torvalds said: it's all about having fun. Play and rec allow more people to have fun.
Dumbing down sound processing
People like me need it broken down into easy bits and pieces. I struggled with the man pages for rec and play, and for sox, but still didn't manage to successfully make an echo or reverb effect. Then I found some sample arguments on the web that were being used with sox and gave them a try. Instant success!
play clipname.wav echo .5 .5 100 .5
The man pages for rec and play point you to the sox man page for details of effects like echo and reverb. The sox man page says that the echo effect takes these arguments: gain-in, gain-out, delay, and decay. So in our example, gain-in and gain-out are the same at .5, the delay is 100 (milliseconds according to the book), and decay is .5. It works.
I did the same thing with reverb. Here is the command as I entered it on my system:
play clipname.wav reverb 1 1000 333 333 333 333
Again from the sox man page, the reverb arguments are gain-out, reverb-time, and delay. Note that delay is repeated as many times as you want. I added three more to my play command and liked it better.
Finally, please note that in both examples, the resulting output can also be written to a new file simply by adding a second file name. Like this:
play clipname.wav new-clipname.wav reverb 1 1000 333 333 333 333
Going back to rule numero uno for Linux, it follows that more people can have fun when everyone plays nice. So it only makes sense that we visit the nice/renice commands while we're talking about play. Both nice and renice allow you to adjust the scheduling priority of tasks from the command line. You can use nice to start a task with a modified priority, and you can use renice to adjust the priority of a task that's already running.
To start a task with a scheduling priority other than the default, do this:
As shown above, the adjustment value of nice will be ten. That's the default adjustment when no value was provided. That would give mytask a higher scheduling priority, and thus less of the CPU time. If you wanted mytask to run more quickly than most other things, you would enter:
nice -10 mytask
If a rude application is taking too much of the CPU time, use renice to make it nice by entering:
renice priority rude-app-pid
Normal users can only renice their own tasks, and then only in the 0-19 range. That means you can set it as fast as the default priority (zero) or as slow as you like. Root can make the priority negative to make the task run faster than normal.
I know. You're probably thinking, "Great! But so what?" That's a good question. As a matter of fact, I have never had occasion to use either. Though I know people who claim to have done so. In fact, one of them told me he used it to lower the priority on a task that was hogging the CPU (and therefore not playing nice) more often than he did to speed up a process.
I decided to ask a real Linux heavyweight which way he used it more often: to rein in a runaway or spur on a dullard. I mentioned his name earlier: it's Linus Torvalds. Some of you are probably yelling "FOUL! Fifteen yards for bringing in a ringer noobie!" But remember, Linus was a noobie once himself. I do have to admit that his answer surprised me, though. He said "Never used it that I can remember."
The range of possibilities for the scheduling priority goes from -20 to +19. The lower the value, the faster the task should run. By default, tasks start with a priority of 0. Most tasks, anyway. On my system, XFree86 appears to have been nice'd at startup. Perhaps other tasks nice themselves, too.
Saved by the (sound of the) bell!
Bereft of any nice experience of my own, and disappointed when Torvalds disclaimed any personal usage on his part as well, I happened to stumble across examples of nice mixed in with heavy-duty usage of of sox on a web page about audio recording on Linux. Maybe it marks a real use for the commands after all.
As always, man these commands to learn more and delve deeper into their usage.