Cron job for starting/stopping recorder

I’m using the recorder app, originally obtained from Recorder | — Community Repository System

Is anyone aware whether this (or another more native alternative) can be controlled from the terminal?
I would like to set up a cron job that will start and stop recording.

Failing the above, perhaps this is an alternative solution to this?

@nephros has answered similar questions admirably in the past: Audio playback at a certain time (cron) - #3 by nephros

In short, use a systemd timer unit as he describes at that link. Or search for other examples of systemd timer on this forum.

Sorry, I just realized you probably want to pass the file parameters for recording time and file to save to based on a script?

@nephros Although the link you provided does help with using systemd as a timer, the post is specific to audio playback. I am looking for something that will allow me to record audio. Therefore, it will probably require parameters for a filename, but this is dependent on what the recorder app requires, if it even allows terminal commands at all.

  • Does Recorder (or a similar SailfishOS native application) allow control over audio recording from the terminal? - Unknown.
  • Is it possible to schedule the starting and stopping of recording via cron? - Yes.

I don’t believe any sfos app with the exception of call recorder, GitHub - dpurgin/harbour-callrecorder: A call recorder for SailfishOS is designed for unattended cli recording. EDIT, and that choses the input sink in a way that doesn’t help you, I believe :slight_smile:

I’ve been working on building the simple recording function from Videoworks (allows you to overdub audio onto a video) into Audioworks and that’s really simple audio recording. I’ll take a look if I can reduce it to a pure cli thing. But that might take a few days.

1 Like

I wonder if parecord would suffice?


Thanks @nephros . I’m not familiar with it, but a quick look at parecord -h, and it appears from the available arguments, that it should do the trick. I will take a further look at it.

Hi @nephros . I got time to try out parecord this morning. It looks like it could do the job. However, there are a few caveats:

  • It appears there is a long-outstanding bug with recording in OGG/OGA or FLAC audio formats. WAV is not feasible for long duration recordings. Any recommendations for high-quality, high compression audio formats that do work?
  • I don’t see a parameter to stop the recording. Would there be a more elegant way of handling this, other than pkill parecord?
1 Like

Did you compile it or find packages that work on SFOS? I’d take a look at the bug.

By default, it does not work on other Linux distributions nor on Sailfish. Since there is no proposed fix for this, a kernel compile would not resolve the issue.
If you know of packages that solve the problem, please enlighten us.

As I noted above, I have functional recording (c++, Videoworks) which I’m working on incorporating in Audioworks hence have another solution in mind.

Regardless, looking at the reports you linked, I’m not inclined to believe it’s been exhaustively tested :slight_smile: Why do you conclude it’s a kernel module problem?
The last viewable bug report says it is:


Which is not in a kernel module.

I may take a crack at it, but will probably build my own solution.

parecord -d jack_out.monitor -r > test.mp3

Works fine. So, just how did you test parecord?

EDIT: so does ogg:

Linux XX 5.15.0-56-lowlatency #62-Ubuntu SMP PREEMPT Wed Nov 23 09:50:07 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

I guess it should also be possible to plug the raw PCM stream into a gstreamer pipe.

Might even get hardware encoding this way.

for me this works:

parec ~defaultuser/SoundRec/$(date +"%Y%m%d-%H%M%S").audio

The file is raw data and I can convert it to whatever using audacity on my pc (Import → Raw data). It creates huge files so watch out. I think I tried the on-the-fly mp3 conversion but the battery drainage was alot for long recordings. If you want a script that detects if parec runs and kills it but if it doesn’t run it start recording, and also changes the microphone sensitivity here it is:


   if [ -n "$(ps -e | grep parec)" ]; then
     killall parec;
     pacmd set-source-volume source.droid 65536;
     exit 0;

   pacmd set-source-volume source.droid 229376
   parec ~defaultuser/SoundRec/$(date +"%Y%m%d-%H%M%S").audio

Change the ~defaultuser / directory accordingly.

Reference source: Running shell script from *.desktop file -


GNU coreutils has timeout which can kill a process after a defined time.

Not installed per default (package gnu-coreutils). BUT: installing this might break some scripts which expect the busybox versions of some of those tools.

1 Like

This approach works for me too, at least on the Volla22…

I checked the sink names first:

pactl list | grep monitor
Monitor Source: sink.primary_output.monitor

to just capture all output (without adjusting the volume).
parecord -d sink.primary_output.monitor -r > (date +"%Y%m%d-%H%M%S").mp3

This approach works for me on the Volla22 also directly to mp3/ogg and so on.
EDIT: SIGKILL / TERM etc all seem to be a fine way to shut down parecord.

1 Like

parecord -d source.droid --file-format=oga test.oga

Is the on-the-fly mp3 conversion some other application you refer to or that within parecord?
I can directly record and output to .mp3 (but wasn’t aware of battery drainage issues), but was looking for an audio file format that has an improved audio quality for the compression it offers - such as OGG/OGA, or FLAC with it being lossless.

As you pointed out, raw audio recording is not suitable as this is for long-duration recording and disk space issues would be a frequent frustration.

Did that work?

Just try recording for a set period of time with flac as the format (you don’t have to specify format, just file suffix) and see if the size will become an issue. Otherwise, use ogg.

Does what work? MP3 recording works, but is not what I was looking for.

FLAC and OGG/OGA recording does not work, with or without the --file-format parameter. The error is what was specified in the reported bug: Failed to open audio file