3

I am using the following to check if any program is writing to pulseaudio sinks:

pacmd list-sink-inputs

This works great straight off of a terminal. This gives me this output:

1 sink input(s) available.
    index: 4
    driver: <protocol-native.c>
    flags: START_CORKED 
    state: RUNNING
    sink: 0 <alsa_output.pci-0000_00_1b.0.analog-stereo>
    volume: front-left: 24144 /  37% / -26.02 dB,   front-right: 24144 /  37% / -26.02 dB
            balance 0.00
    muted: no
    current latency: 59.33 ms
    requested latency: 25.00 ms
    sample spec: float32le 2ch 48000Hz
    channel map: front-left,front-right
                 Stereo
    resample method: copy
    module: 7
    client: 3 <Firefox>
    properties:
        media.name = "AudioStream"
        application.name = "Firefox"
        native-protocol.peer = "UNIX socket client"
        native-protocol.version = "30"
        application.process.id = "1241"
        application.process.user = "balajeerc"
        application.process.host = "smallguy"
        application.process.binary = "firefox"
        application.language = "en_IN"
        window.x11.display = ":0"
        application.process.machine_id = "82f34b545d7441ad9439148d54b19c2e"
        application.process.session_id = "c2"
        application.icon_name = "firefox"
        module-stream-restore.id = "sink-input-by-application-name:Firefox"

However, when I run this as part of a cron job, it gives me nothing (empty string) even when audio is playing.

Why would this be the case?

EDIT: In response to some of the comments below, I tried a couple more things. I am now running it with full path and logging error using:

/usr/bin/pacmd list-sink-inputs >> $LOG_FILE 2>&1

This throws up the following log which is essentially what is printed to stderr since stdout as I mentioned before is empty:

No PulseAudio daemon running, or not running as session daemon.

My crontab entry is as follows:

*/2 * * * * /home/balajeerc/.i3/utils/idle_check_suspend.sh

This is a user crontab entry, not root.

where idle_check_suspend.sh is the script where my pacmd call is.

System information:

Kernel version: 4.8.0-49-generic
Ubuntu 16.04

pacmd 8.0
Compiled with libpulse 8.0.0
Linked with libpulse 8.0.0
6
  • What exactly is your crontab entry? I suspect that the problem is caused by differences between your shell environment and that in which commands execute in cron. It's worth including the full path to pacmd and redirecting both stdout and stderr.
    – AFH
    May 9 '17 at 18:46
  • @AFH Have tried what you've tested and have updated my post.
    – balajeerc
    May 9 '17 at 19:54
  • I'm observing exactly the same as you with a similar test, but I'm really struggling to get to the bottom of it. Indeed, in the past I had so much trouble with cron that I wrote my own bash scripts to replace it, and I now run this in a terminal on start-up. I have tried a lot of tests in cron: whoami shows my user name, and echo ~ $PWD both show my home directory; /usr/bin/pacmd list-sink-inputs >> $LOG_FILE 2>&1 shows No PulseAudio daemon running, or not running as session daemon., which is the same response as I get from a root terminal. (continued)
    – AFH
    May 9 '17 at 22:59
  • The one clue is that ps -fl shows that the cron script is running with superuser privileges, although the invoked ps runs normally (as does ps from the root terminal) and shows pulseaudio in the process list, with the flag 1 (forked but didn't exec). I cannot make sense of this at the moment, but your question is well worth an up-vote.
    – AFH
    May 9 '17 at 23:10
  • For now the best I can suggest is a work-round: comment out the crontab line, start a new terminal, then run while sleep 120; do /home/balajeerc/.i3/utils/idle_check_suspend.sh; done - I suggest you minimise it in a rarely-used workspace, so you can forget about it.
    – AFH
    May 9 '17 at 23:21
7

For security and convenience, most distributions have pulseaudio use your user's built-in temporary storage for its daemon controls (typically in /run/user/). In cron, it doesn't have the relevant environment variables set, so it doesn't know what path to use. You will need to give it some reference info in your script:

export PULSE_RUNTIME_PATH="/run/user/$(id -u)/pulse/"

Alternatively, per textshell's suggestion, if your system doesn't normally set PULSE_RUNTIME_PATH anyway, pulseaudio can use the XDG_RUNTIME_DIR environment variable:

export XDG_RUNTIME_DIR="/run/user/$(id -u)"

To verify the above variables, echo them within a normal known-working shell session:

$ echo ${XDG_RUNTIME_DIR}
/run/user/1000
$ echo ${PULSE_RUNTIME_PATH}
/run/user/1000/pulse/
$
2
  • 1
    $PULSE_RUNTIME_PATH is rather unusual to have set. But pulseaudio uses a path based on $XDG_RUNTIME_DIR if that is not set. So copying the later environment variable to the cron job also works.
    – textshell
    Apr 16 '20 at 17:31
  • 1
    My system doesn't set PULSE_RUNTIME_PATH by default. I tried setting XDG_RUNTIME_DIR in cron, and in fact, this use to work but stopped recently after an update. I tried setting PULSE_RUNTIME_PATH and that does work.
    – user10489
    Aug 4 at 0:11
0

You likely need to specify the full path to the pacmd program, likely /usr/local/bin/pacmd

1
  • 2
    Tried that. It didn't work. Have updated my post with the result of trying that.
    – balajeerc
    May 9 '17 at 19:54
0

pacmd commands work in user session terminal commands, but can have problems accessing the pulseaudio daemon when used in shell scripts

change command in script for equivalent pactl command

pactl list sink-inputs

as script is checking for null response to confirm no active sink-inputs, may only need shortened (possibly faster) response from:

pactl list short sink-inputs

pactl list short sink-inputs

-1

The pulseaudio server/daemon is run per user but crontab runs as root. So when crontab runs pacmd as root there is no server running for root and the commmands can't be received. So you'll have to user your user's crontab rather than the system one or run your script as the user who you think will be logged on.

1
  • Question says user cron job, not root crontab. Perhaps question was edited after this answer?
    – user10489
    Aug 4 at 0:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.