No sound in non-interactive mode

mfoley · 01-23-2024, 03:27 PM

I have Slackware 15.0 kernel 5.15.145. I can run the following at the command line:

Code:

/usr/bin/mplayer /home/mfoley/sounds/tornado2.wav 2>&1 >> $HOME/testing

but when this is is run from a .procmailrc action I get no sound. I've also tried

Code:

TERM=vt100 /usr/bin/mplayer -softvol -volume 100 -ao alsa:device=hw=1.0 /home/mfoley/sounds/tornado2.wav 2>&1 >>$HOME/testing

In the .procmailrc run scipt, this command runs continuously in a while loop. In this case the "testing" file output is:

Code:

MPlayer 20210418-10.3.0 (C) 2000-2021 MPlayer Team

Playing /home/mfoley/sounds/tornado2.wav.
libavformat version 58.76.100 (external)
Audio only file format detected.
Load subtitles in /home/mfoley/sounds/
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 8000 Hz, 1 ch, u8, 64.0 kbit/100.00% (ratio: 8000->8000)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
Audio: no sound
Video: no video


Exiting... (End of file)

continuously every 4 seconds.

Why do I get sound at the command line, but not when non-interacive?

lvm_ · 01-24-2024, 02:01 AM

Probably pulse is not started or something like that. Run mplayer with one or several -v's for more information or master -msglevel option if you want to see only relevant messages.

Petri Kaukasoina · 01-24-2024, 04:45 AM

The non-interactive process can't find the pulseaudio socket. It is in directory $XDG_RUNTIME_DIR/pulse, but XDG_RUNTIME_DIR is probably not defined in the non-interactive procmail process. Check what the value of $XDG_RUNTIME_DIR is in your interactive session and set it to the same value in front of your mplayer command.

mfoley · 01-24-2024, 11:26 PM

Quote:

Originally Posted by Petri Kaukasoina

The non-interactive process can't find the pulseaudio socket. It is in directory $XDG_RUNTIME_DIR/pulse, but XDG_RUNTIME_DIR is probably not defined in the non-interactive procmail process. Check what the value of $XDG_RUNTIME_DIR is in your interactive session and set it to the same value in front of your mplayer command.

Setting XDG_RUNTIME_DIR to run/user/101 worked! Will XDG_RUNTIME_DIR always be this value? Does it change on reboots?

Petri Kaukasoina · 01-25-2024, 12:08 AM

Quote:

Originally Posted by mfoley

Setting XDG_RUNTIME_DIR to run/user/101 worked! Will XDG_RUNTIME_DIR always be this value? Does it change on reboots?

It does not change on reboots. 101 is your UID.

But the directory is created when your session starts (you log in). And it's removed when the session ends. So, immediately after reboot the directory does not exist. Your mail sounds will probably work only while you are logged in.

mfoley · 01-25-2024, 10:00 AM

Quote:

Originally Posted by Petri Kaukasoina

It does not change on reboots. 101 is your UID.

But the directory is created when your session starts (you log in). And it's removed when the session ends. So, immediately after reboot the directory does not exist. Your mail sounds will probably work only while you are logged in.

Well, that's not going to work. The procmailrc script looks for certain email subjects that refer to computer problems, systems down, attempted break-ins, etc. and run a script that sounds an audible alarm. It needs to be able to work without anyone being logged in. This used to work find with Slackware 14.2, kernel 4.4.301.

What alternatives do I have to make this work?

Petri Kaukasoina · 01-25-2024, 11:05 AM

I had a similar problem. I use vnc remotely to access an fvwm screen started at my work computer and there is no session logged in then. So, no /run/user/$UID, because it was deleted when I logged out. I can't remember what the problem was that the missing $XDG_RUNTIME_DIR caused but I solved it by adding these lines in the beginning of ~/.bashrc

Code:

export XDG_CACHE_HOME=/dev/shm/$(whoami)
mkdir -p -m 700 $XDG_CACHE_HOME
export XDG_RUNTIME_DIR=$XDG_CACHE_HOME

/dev/shm is similar to /run/user/$UID, it's tmpfs in RAM, removed in reboot. My .bashrc creates the work directory in it the first time I log in after reboot and it is not removed until the next reboot. You could even mkdir it in /etc/rc.d/rc.local if you need it before logging in the first time.

(I haven't tried it with something like kde or xfce, so YMMV.)

mfoley · 01-25-2024, 12:53 PM

Quote:

Originally Posted by Petri Kaukasoina

I had a similar problem. I use vnc remotely to access an fvwm screen started at my work computer and there is no session logged in then. So, no /run/user/$UID, because it was deleted when I logged out. I can't remember what the problem was that the missing $XDG_RUNTIME_DIR caused but I solved it by adding these lines in the beginning of ~/.bashrc

Code:

export XDG_CACHE_HOME=/dev/shm/$(whoami)
mkdir -p -m 700 $XDG_CACHE_HOME
export XDG_RUNTIME_DIR=$XDG_CACHE_HOME

/dev/shm is similar to /run/user/$UID, it's tmpfs in RAM, removed in reboot. My .bashrc creates the work directory in it the first time I log in after reboot and it is not removed until the next reboot. You could even mkdir it in /etc/rc.d/rc.local if you need it before logging in the first time.

(I haven't tried it with something like kde or xfce, so YMMV.)

So, `whoami` is going to give the user's login id, e.g. "markf". You are therefore creating the directory /dev/shm/markf, and you are exporting that directory as XDG_RUNTIME_DIR.

So basically, XDG_RUNTIME_DIR is an arbitrary directory and could possibly be anthing at all, right? Even /tmp? Why would I need to create something in /dev/shm?

Petri Kaukasoina · 01-25-2024, 01:46 PM

Quote:

Originally Posted by mfoley

So basically, XDG_RUNTIME_DIR is an arbitrary directory and could possibly be anthing at all, right? Even /tmp? Why would I need to create something in /dev/shm?

Right. No need. I think that if you unset XDG_RUNTIME_DIR, /tmp will be used. It should not be a directory which more than one machine mounts. /dev/shm and /tmp are always local. I have just wanted to move everybody's stuff out of filling /tmp.

Petri Kaukasoina · 01-25-2024, 02:01 PM

https://specifications.freedesktop.o...ec-latest.html tells this:

Quote:

$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700.

The lifetime of the directory MUST be bound to the user being logged in. It MUST be created when the user first logs in and if the user fully logs out the directory MUST be removed. If the user logs in more than once he should get pointed to the same directory, and it is mandatory that the directory continues to exist from his first login to his last logout on the system, and not removed in between. Files in the directory MUST not survive reboot or a full logout/login cycle.

The directory MUST be on a local file system and not shared with any other system. The directory MUST by fully-featured by the standards of the operating system. More specifically, on Unix-like operating systems AF_UNIX sockets, symbolic links, hard links, proper permissions, file locking, sparse files, memory mapping, file change notifications, a reliable hard link count must be supported, and no restrictions on the file name character set should be imposed. Files in this directory MAY be subjected to periodic clean-up. To ensure that your files are not removed, they should have their access time timestamp modified at least once every 6 hours of monotonic time or the 'sticky' bit should be set on the file.

If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement directory with similar capabilities and print a warning message. Applications should use this directory for communication and synchronization purposes and should not place larger files in it, since it might reside in runtime memory and cannot necessarily be swapped out to disk.

mfoley · 01-25-2024, 04:23 PM

Really!? This was not needed on Slackware 14.2 (kernel 4.4.301). That procmailrc script worked fine without me beling logged in. This is just the latest in numerous posts I've made at LQ going back years trying to get sound to work on a variety of Linux releases, including via KDE. It has been a constant pain. Fortunately, the LQ experts have always helped me solve the issue. If I installed Windows on this same system I'd have no problem with sound. Why is Windows sound hands-off plug-and-play and Linux is not? (rhetorical)

Oh well, I'll try the suggested /dev/shm idea ASAP and report back.