LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Desktop (https://www.linuxquestions.org/questions/linux-desktop-74/)
-   -   No sound in non-interactive mode (https://www.linuxquestions.org/questions/linux-desktop-74/no-sound-in-non-interactive-mode-4175733106/)

mfoley 01-23-2024 03:27 PM

No sound in non-interactive mode
 
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 (Post 6478952)
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 (Post 6479125)
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 (Post 6479129)
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 (Post 6479233)
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 (Post 6479260)
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.


All times are GMT -5. The time now is 06:58 PM.