Digital Audio processing is a resource intensive task that relies heavily on the processing and I/O capabilities of a system. I would strongly recommend a Pentium class machine as a minimum.
A system based around PCI architecture over ISA is preferred, especially if you are using IDE drives.
The I/O performance difference between an ISA and PCI based system is significant, over 132 MBytes/sec for PCI compared with transfer rates as low as 8 MB/s for ISA.
Is this a problem? It can be. On one of my slower machines I can saturate the bus quite easily when encoding an live audio and writing across a NFS mount.
If you are going to be encoding from an analogue audio source via the line or microphone input, a PCI soundcard will give the best results.
Naturally, the better the quality of the soundcard in terms of its signal-to-noise ratio, the better the encoded MP3.
I've been using the Soundblaster PCI128 and just switched over to a Soundblaster Live Value; both cards give good audio performance, but the Live has significantly better S/N ratios, good enough for semi-pro audio work.
Also, the tonal quality of soundcards differ. I prefer the soundcard on my laptop, a VT 82C686, over my Live!, but the Live! is best for audio recording.
Naturally the quality of the soundcard will affected by the speakers/headphones you use.
Most cards allow you to hook-up the output to an amp so you can listen to your files through your HiFi.
Another important issue is the audio cabling. Cheap, poor quality cables and connectors will result in poor recording quality. If your soundcard has the option to use phono, sometimes referred to as RCA connectors, use them.
Gold plated contacts will also help maintain audio quality, as will keeping audio cables away from data cables as there will be a chance of interference between them.
But don't forget, spending a fortune on the best audio cabling will be lost if the rest of the system hasn't been optimised.
For detailed instructions on setting up soundcards, now would be an excellent time to read the Sound-HOWTO which can be found here:
http://www.ibiblio.org/pub/Linux/docs/HOWTO/Sound-HOWTO
When encoding Ogg or MP3 files the performance of the disk, and its interface is critical. If you are using an IDE based based system, mode 4 or UDMA is preferable as the transfer rate is sufficiently high enough to provide reliable data transfer without problems.
By enabling DMA and 32-bit support you can significantly tune the performance of a modern IDE drive.
WARNING - The following tip may, or may not, work with your system and in the worst case cause failures of the drive and controller. I've only run this command with an attached IDE drive, if you run it on a SCSI drive I've no idea what the result will be!
* You Have Been Warned! *
To alter the performance I'm using a disk utility called hdparm, which should be included in your Linux dist. In the following examples I'm changing the values for my main drive which is /dev/hda, you may have to change this to suit your system.
A benchmark run was performed, with the results below.
bash-2.04# /sbin/hdparm -Tt /dev/hda /dev/hda: Timing buffer-cache reads: 128 MB in 0.88 seconds =145.45 MB/sec Timing buffered disk reads: 64 MB in 11.65 seconds = 5.49 MB/sec
Then the drive was enabled for 32-bit support and DMA support using the hdparm command.
bash-2.04# /sbin/hdparm -d 1 -c 1 /dev/hda /dev/hda: setting 32-bit I/O support flag to 1 setting using_dma to 1 (on) I/O support = 1 (32-bit) using_dma = 1 (on)
A benchmark was taken again with the following result:
bash-2.04# hdparm -Tt /dev/hda /dev/hda: Timing buffer-cache reads: 128 MB in 0.89 seconds =143.82 MB/sec Timing buffered disk reads: 64 MB in 3.33 seconds = 19.22 MB/sec
A big increase in the buffered read performance on my system !
The settings were saved with the following command:
bash-2.04# /sbin/hdparm -k 1 /dev/hda /dev/hda: setting keep_settings to 1 (on) keepsettings = 1 (on)
Just to make sure that the settings are enabled at reboot the hdparm was entered into my boot.local (or rc.local on some systems).
There have been a few articles on Linux.com recently covering disk tuning, more can be found at:
http://www.linux.com/enhance/tuneup/database.phtml/Filesystem/
A good intro to hdparm can be found on O'Reily.net:
http://linux.oreillynet.com/pub/a/linux/2000/06/29/hdparm.html
The ideal solution would be to use a SCSI based system as the drives and interface have far better throughput capabilities, a sustained 5MB/sec for SCSI 1 through to 40-80MB/sec for ultra-ultra2/wide SCSI upto Ultra160M SCSI which reaches 160MB/second. IDE can peak at anything from 8.3 MB/s to 66 MB/s for Ultra DMA mode 4 but these speeds are peak, average transfer rates will be slower. If you can find, or afford, an AV SCSI drive, go for it.
AV drives have had the read/write head system optimised for continuous data transfer, other SCSI and IDE drives normally cannot sustain continuous data transfer as the write head heats up!
Naturally a drive that has cache will give more consistent results than one that doesn't, as the cache will act as a buffer if the heads do lift or it cannot handle the throughput.
If your drive isn't up to spec, your recording will suffer from dropouts and glitches, where the drive failed to record the signal. If you are recording one-off events, such as live performances invest in a good SCSI based disk system.
If you thought you could store your Ogg/MP3 collection on floppies you could be in for a surprise :) Disk storage space will become an issue sooner or later if you are building a collection.
If you plan to build up a large collection it may be beneficial to consider using a RAID array to store them.
For more information consult the Linux-RAID FAQ by Gregory Leblanc which can be found below:
http://www.LinuxDoc.org/FAQ/Linux-RAID-FAQ/index.html
For encoding Ogg and MP3's from CD-ROM, the speed or type of drive will determine the time taken to read the raw information from it. A single speed drive will probably be too slow for all but the most patient.
Ripping audio data does seem to stress drives, I've had 2 fail so I don't reccomend using laptop CD drives for too much as they are far more expensive to replace.
CD writer's are now fairly common and can be used for archiving files as well as producing audio CD's from Ogg/MP3's.
A quick note regarding IDE based drives. A lot of the CDR tools assume you have a SCSI based drive, but you can enable SCSI emulation to circumvent this issue. Have a read of the CD-Writing-HOWTO if this affects you.
http://www.ibiblio.org/pub/Linux/docs/HOWTO/CD-Writing-HOWTO
Another cause problems is a heavily loaded system. Background tasks can cause the system to momentarily glitch. Its recommended to run as few background services as you can, especially networked based services. For more information about setting network services, and startup scripts please refer to the SAG and NAG guides.
Virtual memory paging will also cause glitches, so run with as much physical RAM as you can, I'd recommend at least 32 Mb, but you may well need more.
For those wanting to extract the most out of their system, optimising the kernel probably wouldn't do any harm either.
For streaming and listening to Ogg or MP3's over a networked filesystem the better the network card the better the throughput, naturally a 100Mb interface will give better throughput than a 10Mb interface :)
While the hardware specifications above will give you a decent system to encode audio data, don't discount using older, lower spec kit if that's all you have access to.
Using NFS with a few 486's you can record on one, encode one another, stream from another and use one for listening and acting as the fileserver.
It'll be a good challenge for a sys-admin to tweak a low-spec system to give good results, and the end result will probably be a happier Linux box.