Starting darkice automatically on Raspbian Buster Lite

[DC31]

that's because it's not.

for some reason it says its active(exited).
if it was working, it would say active(running) and then give you non-zero tasks & memory data, and the CGRoup would have the active process treespan below it.

sudo journalctl -u (yourservicename)

this code should report back all the journalctl logging for your service

I would also make sure that the command in your EXEC START is fully capable of running the program if you cut & pasted it into the command line

Yes the EXEC START works fine pasted into the command line. The only info reported by journalctl are the same two lines as above starting Sep 21.

 

[DC31]

Gave it another try this morning. It appears that systemd is attempting to start darkice but is failing with the can’t open connector error. When I run the same command at the command line, no error.

darkice.service - Darkice
Loaded: loaded (/etc/systemd/system/darkice.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2019-09-22 07:17:09 EDT; 6s ago
Process: 5318 ExecStart=/usr/bin/darkice (code=exited, status=255/EXCEPTION)
Main PID: 5318 (code=exited, status=255/EXCEPTION)

Sep 22 07:17:09 buster-sdr darkice[5318]: This is free software, and you are welcome to redistribute it
Sep 22 07:17:09 buster-sdr darkice[5318]: under the terms of The GNU General Public License version 3 or
Sep 22 07:17:09 buster-sdr darkice[5318]: any later version.
Sep 22 07:17:09 buster-sdr darkice[5318]: Using config file: /etc/darkice.cfg
Sep 22 07:17:09 buster-sdr darkice[5318]: Using ALSA DSP input device: default
Sep 22 07:17:09 buster-sdr darkice[5318]: Could not set POSIX real-time scheduling, this may cause recording skips.
Sep 22 07:17:09 buster-sdr darkice[5318]: Try to run darkice as the super-user.
Sep 22 07:17:09 buster-sdr darkice[5318]: DarkIce: DarkIce.cpp:1273: can't open connector [0]
Sep 22 07:17:09 buster-sdr systemd[1]: darkice.service: Main process exited, code=exited, status=255/EXCEPTION
Sep 22 07:17:09 buster-sdr systemd[1]: darkice.service: Failed with result 'exit-code'.


Is there some parameter that needs to be set in the service file that I am missing?

 

[a417]

you are running darkice as user=pi, and the suggestion there says to try to run it as a super-user....have you tried that?

 

[a417]

and silly question time, you are referring to darkice1.cfg in your earlier posts, and then darkice.cfgin the last one.

The lines referenced in the error message have something to do with dsp& audio encoding errors (lame,ogg vorbis,acc...etc) I saw that environment variable in the .service file (never having had to use it), are you sure you're pointing darkice at the appropriate device for audio input?

 

[DC31]

and silly question time, you are referring to darkice1.cfg in your earlier posts, and then darkice.cfgin the last one.

The lines referenced in the error message have something to do with dsp& audio encoding errors (lame,ogg vorbis,acc...etc) I saw that environment variable in the .service file (never having had to use it), are you sure you're pointing darkice at the appropriate device for audio input?

No difference when run as sudo. The darkice1.cfg is on the two stretch pi’s. On the Buster pi darkice.cfg is correct. It works fine and streams from the command line. I did the update/upgrade last night to rule that out.

I suspect a problem with pulseaudio. The two Stretch units run Lite. The Buster is GUI. The Buster is a little non-std as it has an sdr dongle run with gqrx. The output of gqrx is routed to darkice through pulse. Still, when I simply type /usr/bin/darkice at the command prompt, it loads and streams. Using pavucontrol can see that pulse is sending the gqrx output to the internal sound card (the inly sound device on the pi) and that darkice is using the monitor of this sink as its input.

All works from the command line but not when started as a systemd service.

I am about to reimage the Buster card and start over from scratch (for reasons unrelated to darkice). I will try starting darkice as a service with a usb sound card before I reinstall pulseaudio.

 

[a417]

interesting audio path you are using, why gqrx -> pulse -> darkice?

and no, not running the command by modifying the ExecStart to include sudo, but removing the "User=pi" from the service file. I've had issues with apps trying to run via ExecStart with sudo prefacing the command, and removing the user designation allowed it to run as root from the get-go.

 

[a417]

for whatever reason, I cant direct link to this stackexchange post I have bookmarked, but Mark Stosberg wrote a GREAT mini-faq on what you're going thru right now.

Mark's post answer


wait, it's working now. I'm going to dump the answer text in here anyway.

1. Different environment variables. systemd documents the environment variables it passes in man systemd.exec in the section Environment variables in spawned processes. If you want to inspect the difference yourself, you can use systemd-run /path/to/binary, it will run your app in a transient scope, as it would be run by a systemd service. You'll get output like: Running as unit: run-u160.service. You can then journalctl -u run-u160.service to review the output. Modify your app to dump out the environment variables it receives and compare the CLI run to the systemd run. If the app isn't conveniently modified, you can just use systemd-run env to see the environment variables that would be passed and review the resulting journal logging for it. If you are trying to start an X11 GUI app, the DISPLAY environment variable needs to be set. In that case, consider using your desktop environment's "autostart" feature instead of systemd.
2. Resource restrictions. See man systemd.resource-control for configuration values which could restrict resource consumption. Use systemctl show your-unit-unit.service to check the full configuration values affecting the service you attempting to start.
3. Non-interactive shell. Your bash CLI environment is an interactive login shell. It has sourced files like .bashrc that systemd has not. Besides setting environment variables, these scripts can do any number of other things, such as connecting an SSH agent so that SSH actions don't require a login. See also Difference between Login Shell and Non-Login Shell?
4. No TTY. Your interactive session is connected to a TTY that some programs like sudo and ssh expect when prompting for passwords. See also sudo: no tty present and no askpass program specified
5. Relative vs. Absolute Paths. Relative binary work in the shell, but as documented in man systemd.service, the first argument to ExecStart= must be an absolute path to a binary.
6. Restricted command line syntax. Shell CLIs support many metacharacters, while systemd has a very restricted command line syntax. Depending on your needs, you may be able to replicate Shell syntax with systemd by explicitly running your command through a shell: ExecStart=/bin/bash -c '/my/bash $(syntax) >/goes-here.txt'

It's a feature that system runs your code in a consistent environment with resource controls. This helps with reproducible, stable results in the long run without overwhelming the hardware

 

[DC31]

I am using that path as that is about the only way that I have found to get the output of gqrx into darkice. Is there a better way? I am using gqrx rather than rtl-fm as I have spent years with that and gotten virtually nowhere. Using gqrx on a pi4, i have finally gotten reasonably good audio from one of my sdr sticks. Change to the latest and greatest sdr stick and that same pi4/gqrx turns completely to garbage.

 

[a417]

yes, use rtl-fm! Haha, sorry, but running GQRX just for audio is 10000 times harder than what you need to do to accomplish this. All of the settings that you have at your disposal in gqrx

Once you calibrate your rtl-sdr and figure out your ppm offset, you can very easily fine tune your rtl-fm using the settings you used on gqrx and get the exact same results. Lets get this going for you.

 

[DC31]

Okay, so I have used gqrx and have the waterfall showing that I am dead center on my frequency. Here is what I get using the latest nooelec dongle:

http://www.twotonedetect.net/audioplayer.php?filename=Charlemont_EMS_2019_09_21_16_18_17.mp3

I spent about 8 hrs making adjustments yesterday...

 

[DC31]

Same antenna, same pi, same gwrx only an older nooelec dongle. Again, freq dead center.

http://www.twotonedetect.net/audioplayer.php?filename=Charlemont_EMS_2019_09_15_11_24_37.mp3

 

[a417]

this is my rtl_tcp for local use on my network for scanning from anywhere on the LAN, you will notice that I have some settings that are modified from default, like my gain and ppm offset.

[Unit]
Description=Run RTL_TCP, serving data on port 2345, utilizing dongle 3
After=network.target
[Service]
Type=simple
ExecStart=/usr/bin/rtl_tcp -a 192.168.1.202 -d 3 -p 2345 -g 48 -p 42
Restart=on-failure
[Install]
WantedBy=multi-user.target

That new SDR sounds like it's out of calibration or has some issues with it, you've got a multitude of issues here all at once, lets solve one at a time.

 

[DC31]

yes, use rtl-fm! Haha, sorry, but running GQRX just for audio is 10000 times harder than what you need to do to accomplish this. All of the settings that you have at your disposal in gqrx

Once you calibrate your rtl-sdr and figure out your ppm offset, you can very easily fine tune your rtl-fm using the settings you used on gqrx and get the exact same results. Lets get this going for you.

You make it sound simple.

I put the exact settings for offset, gain, and squelch in rtl-fm and the audio is totally unintelligible.

pi@buster-sdr:~ $ rtl_fm -f 460.4M -M fm -s 16k -p 56 -g 19.4 -l -37 | aplay -t raw -f S16_LE -r 16000
Found 1 device(s):
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 16000 Hz, Mono
0: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Detached kernel driver
Found Rafael Micro R820T tuner
Tuner gain set to 19.70 dB.
Tuner error set to 56 ppm.
Tuned to 460652000 Hz.
oversampling input by: 63x.
Oversampling output by: 1x.
Buffer size: 8.13ms
Exact sample rate is: 1008000.009613 Hz
Create UDP thread
Created UDP thread
Main socket started! Tuning enabled on UDP/6020
Allocating 15 zero-copy buffers
Sampling at 1008000 S/s.
Output at 16000 Hz.

 

[a417]

sampling rate set the same?

rtl_fm & gqrx default to different sample rates, so it's apples to oranges. w/o specifically setting it, rtl_fm defaults to about 1.024 msps while the gqrx I have defaults to 1.8 msps or 2.0.

max that gain out, that might be in