So I've been recording audio from my soundcard using arecord. Have the alsa all set right. I can record stuff. Can play back. No problems there. I use arecord (part of alsa so already included in the distro) to record. I like arecord because it is a simple command line program and I can tell it which sound card to record from. The problem is that if I record for more than ten minutes or so I often get buffer overuns. My goal is to record over 45 minutes of audio without breaks. The overruns make this not possible. I can do this in windows from the same soundcard so I know that my hardware is up to it. I have experimented with the command line parameters in arecord to use a larger buffer for the sound but this seems to have no effect (or I'm doing it wrong).

Most recent attempts used this command line:
In the above example I am recording a 32-bit stereo wave file at 44100 Hz. The card is 24 bit but some trial and error has revealed that arecord seems to prefer to deal with 24 bit data as if it were 32 bit data. The buffer_time is (according to the arecord man page) in "microseconds". I looked that up and found that a microsecond is a millionth of a second. So my 500000 should be a half second of audio buffering.

Again, recording "works", the wav files contain the valid audio, just with skips/breaks caused by the buffer overruns.

Let's see what other info can I give ... oh yeah: slackare 11 using the prebuilt "huge 2.6" kernel.

So to the acutal specific quesions

Question 1) what parameters can I give to arecord to have it not have buffer overruns when recording 45+ minutes of 24bit/32bit audio?

Question 2) Is there some other software (hopefully lean and simple CLI that can record 45+ of 24bit/32bit audio without overruns? (I would really prefer to use arecord though)

One thought - are you sure that the skips/breaks aren't due to spikes in the system load resulting from other processes that are running at the same time? In other words, if I'm putting a heavy load on my CPU and/or RAM and/or hard drive at the same time that I'm watching a video clip or listening to audio, those spikes can easily cause a temporary, noticeable hiccup. What kind of CPU do you have, how much RAM, and how full is your hard drive? Similarly, does this happen even when you have nothing else running while you're recording?

Hmm: to answer your questions ... When recording this way I never have anything else running. The CPU is an AMD 64 of some kind at 2.2. I forget the exact model: forgot the linux command to show that. 512 meg of ram (and it just about never hits the swap). The HD in question is a separate drive dedicated just for recording, so that no "system" processes will tie up the drive.

Today I freed up some space on the drive, leaving 9 gig free out of 40 gig (yesterday about 1.5 gig were free). I then defragged it on the windows side (I dual boot and that drive is a single fat32 partition). Then I made two recordings (arecord in linux, as in my original post) each of which was just over 45 minutes. They had no overruns.

Because of the random nature of this problem it is important not to come to premature conclusions ... but it looks like freeing up space (as you said) and defragging fixed the problem.

Or I got lucky. I will need to do more recordings to know for sure.

I'd be willing to bet that the source of your problem is that the drive simply has too little free space. If you were using 38.5G out of total of 40G, your drive was over 96% full (ouch!), and it would not be surprising for things to start behaving poorly. As you probably know, the general rule of thumb is that once a hard drive reaches about 85% of its storage capacity, performance is liable to start suffering, and the closer you get to 100%, the more probable it becomes that you'll encounter problems. You might want to consider getting a larger drive, or perhaps archive some older recordings off to CD and then deleting them from the hard drive. Good luck with it