Being off the grid and energy concious (duh), I've lately been doing a lot of the dev work on an Odroid XU4 as it's very pi-like but for double the cores, ram, emmc...and so on. Actually a pretty nice little "dev box" that will even do google vid hangouts. But beware, my debug options and filepath options hardcoded in this code assume that - if you want other stuff, you have to set the path for the audio file at least, and if debugging, set the logfile path in the code before using this.
I needed this to use sox (the linux swiss army knife of audio) inside my "fusor master" code, as for whatever reason, spawning other processes from inside a GUI callback event doesn't work out well. So, we can just prespawn the daemon that does the job from either the pre-gui code in the master controller, or simply from /etc/rc.local - and when asked, it will do whatever you asked (as root in the latter case, be careful what you ask for).
The default here is to record stereo from the default input source you've set up the normal way, and put it in the path you've set - or /home/odoid/testaud.mp3 (and if you don't have that path, who knows, it'll fail in some way).
There are two programs here, both perl (well, I'm getting too old and lazy to use either a newer fad language or a down on the metal C).
recd is the daemon. It just runs in the background forever (uses no cycles but some ram) till a UDP command is sent to it.
The commands are simple:
Code: Select all
go - makes it go
stop - stop recording and close the file
die - die, quit, go away, leave town
path:/your/path/whatever/you/want/somefilename.someextension - sets a path for the resulting file. Sox looks at the extension to know if it should for example make a .wav, .flac, .mp3, or whatever
(lots of possibilities here) I did set a 256 char limit though modern opsys' probably lack it these days. I'm just an old fart.
opt: -c2 -q (the default). The -c2 means stereo, the -q means no output on the now-nonexistant terminal we started this from (or initd or holy crap, systemd). Any options to sox (rec)
that are legal will work. Note there is a leading and a trailing space there, which has to be there.
These are sent via UDP on port 53129 (any unused port will work if you change it in the code), and can be sent by any local or remote machine.
For this, (I had to test it somehow) I provided recdt. It assumes the same port number, and localhost, but if you look in the code, it can be set for any resoveable/routable host or broadcast in your lan just as easily.
So, however one does it, one starts recd (could just be the name in rc.local, no & needed as it's a real daemon) or at a prompt.
Then one sends it commands, which can be done by recdt or anything that can send messages to this machine over UDP to this port.
A sample test session here looks like this:
Code: Select all
odroid@odroid:~/bin$ recd
odroid@odroid:~/bin$ recdt
Input command to send recd daemon->go
Input command to send recd daemon->stop
Input command to send recd daemon->die
Input command to send recd daemon->^C
odroid@odroid:~/bin$
In "real life" my fusor master code will create a socket much as recdt does, and provide a path with the current time/date as the filename, so I can later put that path into the mysql database for playback in time-sync with the videos and plottable data. But this may have other uses, hence, I'm giving it out here - whatever license pleases you, this isn't rocket science - share and enjoy. BTW, even at 48khz sample rate, this uses around 2% of a pi-3, at least if it's recording to an external solid state storage. I'm using a "Blue Yeti" USB mic on the real thing - see Amazon, they are quite nice units. In this case, I'll be using the headphone monitor output these also have to get realtime zero lag audio back to the remote control position. A lot of stuff can burn up in the second or so delay involved in streaming audio...and I'm already streaming 3 video streams, so...wire works pretty well for this.
Here it is: