Hello,
I use to record long time radio transmission (up to six hours) with
audacity and then export to mp3. However, this is not a practical
solution. I am looking for tools (even command line, I found a sox | lame
pipe) that could do this for me directly while recording. My pc is a
celeron 600 Mhz with 320 RAM, is it enough powerful to do this in
real-time?
(I hope the best mp3 quality - constant rate at 320 Kps).
Thanks,
Gaetano

Try it and see. I'd use the ALSA tool arecord to grab the data from the sound card and pipe that directly into lame, like this:
The -f cd part says to use CD quality (44.1 kHz, 16 bit stereo). Read the arecord manual page and select something else if you prefer. The -b 320 option to lame says "constant bitrate" at the rate you specified.

What I'd do is run top or some similar tool in one terminal, and your encoder in another, and over time see what the CPU load is - this will probably be a CPU-bound task. Lame takes about 25% of my CPU on my 1.7 GHz system... I think it'll be close to 100% for you, but maybe your system is fast enough. Just make sure you don't have heave tasks scheduled with cron to operate half way through your recording!

If you're going to be needing very long recordings, it might be prudent to put the command in a loop which will make it automatically re-start if there is a problem. Maybe like this:

The one I know of is called mp3record. it too is a script that uses sox and lame.

Brian

Thanks! Now I will try

Mmmhh, I have tried with the arecord | lame pipe and
stops the recordings after about three hours, giving
me a whistle sound for some minutes and then returning
to the terminal. I think that arecord, like sox, is
limited by the standard C library to sample at best
2 GB.. What could I do? I think to write a simple
read/write loop with ALSA by myself..

Ouch! I agree that this is likely caused by the 2GiB limit.

The solution which I would try first is to re-build arecord and lame to use 64 bit file pointers. GNU libc compiles with 32 bit file pointers on 32 bit systems unless explicitly told to use 64 bit file pointers. I guess this is a performance thing.

To tell GNU libc that you want to use 64 bit file pointers is easy - just define the symbol _FILE_OFFSET_BITS as 64 at compile time.

In the case of the ALSA utilities package which contains arecord, you can do this by passing an option when you do the configure stage of the build process, like this:
I am using kubuntu, so fetching the source was just a matter of using the command:
The build process actually failed (very unusual for a package retrieved in this way), but it build enough to have an arecord binary which works. You can test to see if it is using 64 bit file pointers like this (from the directory where the new arecord is made):
You should see something like this:
If the O_LARGEFILE is absent, you are still using 32 bit file pointers.

I didn't try the same thing with lame, but I imagine you can use a similar process.

Good luck!

This records from line in

sox -t ossdsp -w -s -r 44100 -c 2 /dev/dsp -t raw - | lame -x -m s - ./filename.mp3


This records from an internet stream

mplayer -dumpstream -dumpfile ./filename.mp3 mms://location.to.stream


substitute your stream you want to record for the mms link

Running strace on the current executables (I did not recompile them),
give me:

for arecord:

open("test.wav", O_WRONLY|O_CREAT|O_LARGEFILE, 0644) = 6

for lame:

open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib/libncurses.so.5", O_RDONLY) = 3
open("/lib/tls/libm.so.6", O_RDONLY) = 3
open("/lib/tls/libc.so.6", O_RDONLY) = 3
open("/lib/tls/libdl.so.2", O_RDONLY) = 3
open("1", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)

So these binaries are already compiled with support for large files?
?!?!?!

Looks like it. It appears I am missing something in my understanding.