recording radio using sox

CrashedAgain · 12-12-2007, 04:52 PM

(this is a followup to previous post http://www.linuxquestions.org/questi...ghlight=kradio)

I am now trying to record radio from command line. I am able to play redio using "fm tools" or "radio"

Code:

crashedagain@Desktop:~$ fm -T forever 94.1 65535
Radio tuned to 94.10 MHz at 100.00% volume
Sleeping forever...CTRL-C exits

and the radio plays. fm is supposed to send the output to stdout so using the sox "rec" command should work

Code:

crashedagain@Desktop:~$ rec -c 2 -t wav /media/hdb2/Radio/test.wav trim 0 15

Input File     : 'default' (alsa)
Sample Size    : 16-bit (2 bytes)
Sample Encoding: signed (2's complement)
Channels       : 2
Sample Rate    : 48000

Time: 00:15.02 [00:00.00] of 00:00.00 (  0.0%) Output Buffer: 720.00K

Done.

a short test file is created, but gives no sound when attempting to play the file.

Checked that the sox "play" command works by playing an existing wav file & all is well.

Viewing the test file with audacity shows just a flat line confirming that it has recorded no sound.

Also tried sox -w -t ossdsp /dev/dsp -w -t wav /media/hdb2/Radio/tes.wav as suggested in http://www.linuxtv.org/v4lwiki/index.php/Radio with the same result...no sound in outputed file.

Also tried using /dev/radio but sox gives "can't open /dev/radio" error.

Can anyone help?

matthewg42 · 12-14-2007, 06:25 AM

Quote:

Originally Posted by CrashedAgain

fm is supposed to send the output to stdout so using the sox "rec" command should work

If this fm program is sending the audio to standard output, you would see a lot of stuff scrolling up the terminal window, and you would be able to record it simply by re-directing to a file using the > operator.

Standard output is not a term used to describe the sound card, or any other audio related thing - it means printed output from a program.

To get an idea what it would look like to see audio data on standard output, just cat a .wav file.

Assuming that the audio is coming out of your soundcard when you use the fm program, there is a chance to capture it, however it depends on what audio driver the program is using. If it uses OSS, I don't know how to do it.

However, if the program uses ALSA, you can record the regular sound card output:

Run alsamixer in a terminal window
press TAB which will switch the view mode to "capture"
use the cursors to move to the "Capture" input and make sure the level is set to a non-0 value (I used about 80. I'm not sure it makes a lot of difference)
With the selection still on the Capture setting, press the SPACE key and verify that a red "CAPTUR" appears under the level bar.
Use the cursors to highlight the Mix setting. Press SPACE until you see CAPTUR under that too
press the ESC key to close alsamixer

You should now be able to capture any audio playing in program which use the ALSA drivers. You don't need sox - you can just use the arecord program (which is part of the ALSA utilities). For example:

Code:

arecord -f cd -d 15 myrecording.wav

Which records at CD quality (stereo, 16 bit 44.1 kHz) for 15 seconds.

CrashedAgain · 12-14-2007, 11:42 AM

That worked! Thanks.

Sox does use the term "stdin" and "stdout" in their manpage, BTW, so I assumed they were appropriate terms for sound also.

Code:

(excerpt from man sox):

-      SoX can be used in pipeline operations by using the special filename ‘-’ which, if used in place of an input filename, will cause SoX will read audio data from
              ‘standard input’ (stdin), and which, if used in place of the output filename, will cause SoX will send audio data to ‘standard  output’  (stdout).   Note  that
              when using this option, the file-type (see -t below) must also be given.

matthewg42 · 12-14-2007, 05:40 PM

Quote:

Originally Posted by CrashedAgain

Sox does use the term "stdin" and "stdout" in their manpage, BTW, so I assumed they were appropriate terms for sound also.

Yes, but only when piped into sox, like

Code:

somecommand | sox -someoptions

ncsuapex · 12-14-2007, 08:02 PM

Ive used this script to record from line in(radio)

sox -t ossdsp -w -s -r 44100 -c 2 /dev/dsp -t raw - | lame -x -m s - .filename`date +%b%d_%H%M%P_%Y`.mp3

command is one line

CrashedAgain · 12-14-2007, 10:12 PM

That works also.

Thanks.

I tested this

Code:

fm -T forever 94.1 | sox -t ossdsp -w -s -r 44100 -c 2 /dev/dsp -t raw - | lame -x -m s - /media/hdb2/Radio/test`date +%b%d_%H%M%P_%Y`.mp3

to start the radio and start recording, and it works.

So does

Code:

fm -T forever 94.1 |arecord -r 11025 | lame -x -m s - /media/hdb2/Radio/test`date +%b%d_%H%M%P_%Y`.mp3

Crtl C stops in both cases.

Now, I would like to set up to automatically start recording at a certain time on a given day of the week then record for x hours then stop.

Presumably this would be done as a cron job, which doesn't look too hard although I've never done one.

ncsuapex · 12-15-2007, 10:39 AM

cron is easy.

30 10 10 11 * sox script

minute hour day month day of week

so the above cron entry would record something at 10:30am on Nov 10th
Cron uses the 24 hour time format, so 11pm would be 23, 11am would be 11

can also use it to stop the recording

30 11 10 11 * killall -9 sox

this would kill all sox recordings at 11:30

CrashedAgain · 12-15-2007, 11:37 AM

so:
my start script:

Code:

#! /bin/sh

fm -T forever 94.1 | sox -t ossdsp -w -s -r 44100 -c 2 /dev/dsp -t raw - | lame -x -m s - /media/hdb2/Radio/test`date +%b%d_%H%M%P_%Y`.mp3

(tested it...it works).

and my stop script

Code:

#! /bin/sh

fm off

killall sox

question: what is the -9 in your "killall -9 sox" command above

and then I would set up the cron (using crontab commands?)

Thanks

ncsuapex · 12-15-2007, 02:46 PM

I forget what the killall -9 actually does.. I think it kills the entire process tree

Yep just use your script names in the crontab and it should work.

matthewg42 · 12-15-2007, 06:12 PM

The -9 option just chooses which signal gets sent to the specified process. -9 (SIGKILL) is special because it cannot be trapped by an application and ignored. For all other signals, the application can choose to ignore them if it likes. -9 is a very rude and immediate way to kill a process which it cannot refuse.

It's usually better to give a process a chance to close down itself because it might have routines to prevent it leaving half-written (and thereby corrupt) files. Imagine a database server which is half way through updating some table... kill -9 might leave some transaction half done or something else bad. By sending the more polite SIGTERM, you can request that a process terminate now. SIGKILL should only be sent if the program fails to respond to SIGTERM.

ncsuapex · 12-15-2007, 07:11 PM

So a killall -15 would be better to use?

matthewg42 · 12-15-2007, 07:28 PM

SIGTERM (number 15) is the default if you don't specify a signal. Thus all these three commands to the same thing (to the process ID 12345):

Code:

kill 12345
kill -15 12345
kill -TERM 12345

matthewg42 · 12-15-2007, 07:31 PM

By the way, when you shut down your machine, did you ever notice - if it is in text mode you will see notices like:

Code:

Sending all processes TERM signal...

Then a short pause, then:

Code:

Sending all processes KILL signal...

First processes are given the chance to terminate nicely, then if they don't they are killed.

CrashedAgain · 12-16-2007, 05:02 PM

Got it all working now.

Only problem is that the radio that I wanted to record was last night & I had to go out...didn't have the cron setup finished so I just quickly up-arrowed back to what I thought was my "start recording" command in console & took off for my appointment. When I got back I found out that I had instead entered one of my short testing sequence commands & I ended up with a recording only 2 minutes long! Oh well, @#$$^*&(##* happens!!

Thank you all for your help.

CrashedAgain · 05-12-2008, 12:43 AM

Having problems again....the above was working, then I upgraded the system (apt-get upgrade). Errors started...

Code:

crashedagain@Desktop:~$ fm -T forever 94.1 | sox -t ossdsp -w -s -r 44100 -c 2 /dev/dsp -t raw - | lame -x -m s - /media/hda5/Radio/CBC_`date +%y_%m_%d_%H%M%P`.mp3
sox soxio: Can't open input file `/dev/dsp': unknown file type `ossdsp'
Assuming raw pcm input file : Forcing byte-swapping
LAME 3.97 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding <stdin> to /media/hda5/Radio/CBC_08_05_11_2325pm.mp3
Encoding as 44.1 kHz 128 kbps stereo MPEG-1 Layer III (11x) qval=3

appears sox no longer recognizing ossdsp & /dev/dsp...so after a bit I got it recording again with sox "rec" command

Code:

crashedagain@Desktop:~$ fm -T forever 94.1 | rec -c 2 -t raw - | lame -x -m s - /media/hda5/Radio/CBC_`date +%y_%m_%d_%H%M%P`.mp3

Input File     : 'default' (alsa)
Sample Size    : 16-bit (2 bytes)
Sample Encoding: signed (2's complement)
Channels       : 2
Sample Rate    : 48000

Time: 00:00.00 [00:00.00] of 00:00.00 (0.00%) Samples out: 0     Clips: 0    Assuming raw pcm input file : Forcing byte-swapping
LAME 3.97 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding <stdin> to /media/hda5/Radio/CBC_08_05_11_2327pm.mp3
Encoding as 44.1 kHz 128 kbps stereo MPEG-1 Layer III (11x) qval=3
Time: 00:03.84 [00:00.00] of 00:00.00 (0.00%) Samples out: 180k  Clips: 0
Aborted.

...but

the recording is noticably slowed down (like a record running slow). I have experimented some & have determined that the slowing is occurring with the "rec" command, not with the lame encoding to .mp3. It MAY be because "rec" sample rate is at 48000 while lame is using 44100...I don't know. I tried to get it to work using "sox" command instead of "rec" but cannot get it to find the proper input. Sox is supposed to recognize "stdin" (which would be alsa) by using "-" as the input file name but all I get are errors:

The syntax is supposed to be sox [global-options] [format-options] infile [format-options] outfile

so, with "-" as the infile and a test name as the outfile, I tried but no go...

Code:

crashedagain@Desktop:~$ fm -T forever 94.1 | sox -t alsa -c 2 - test.aiff
ALSA lib pcm.c:2144:(snd_pcm_open_noupdate) Unknown PCM -
sox soxio: Can't open input file `-': cannot open audio device

What am I doing wrong?