Subj : Re: aplay oddity To : All From : Chris Elvidge Date : Fri Oct 24 2025 13:40:52 On 24/10/2025 at 13:18, Adrian wrote: > In message <10dei3u$27uve$7@dont-email.me>, Lawrence > =?iso-8859-13?q?D=FFOliveiro?= writes >> On Thu, 23 Oct 2025 19:09:02 +0100, Adrian wrote: >> >>> If I do a cut and paste of the aplay command, it works fine. So the >>> problem looks as though it is some thing to do with the python call. >> >> I would try to confirm this by running the Python script (or at least >> a copy of the part that does the aplay command) from a terminal >> session. In other words, try to minimize all the differences between >> the situation where you can successfully invoke the command, and the >> one where you can?t. >> > > Thanks for the detailed reply. > > I've just tried that, and running the Python interactively works (I get > sound). So far, so good. > > In the normal way of things, the Python code is started by cron using > @reboot. Being aware that the environment that cron gets can be > different to that of an interactive session, I've just killed off the > background Python code, and restarted it using nohup (which I think > should give the same environment as the command line). That still fails > (code runs, no sound), but now the error message doesn't appear, instead > in the error file, I get the message : > > nohup: ignoring input and appending output to 'nohup.out' > > which it doesn't, that file remains empty. > > So it looks as though the problem is with the Python code running in the > background, rather than the Python code itself. I'm wondering if one of > the updates that has run since the previous reboot (~8 weeks ago) has > come into play because of yesterday's reboot. > > I forgot to mention that the path to the sound file is absolute, rather > than $HOME/... > > When I run Python from the command line, it tells me that I'm running > Python 3.11.2 > > >>> Both command line and python are running under the same user. >> >> I suspect there is some issue with setup of environment variables >> (e.g. $HOME) when running the script in the background versus >> interactively. > > I would agree, but see above. And why did it work pre-reboot ? > >> >>> What I'm seeing logged by the python code is the following error : >>> >>> ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave >>> aplay: main:831 audio open error: Unknown error 524 >>> >>> I've tried rebooting again, and an Internet search doesn't come up >>> with anything for my particular problem (they all seem to be >>> "nothing working"). >> >> I did a search for ?alsa Unknown error 524? and found this >> > open-audio-device-unknown-error-524-what-is-going> >> where the error was fixed by putting something into the systemwide >> ALSA config. >> >> This would be consistent with my suspicion that the per-user setup >> for your background versus interactive cases is not exactly the same. > > Thanks. I tried adding those entries, but it makes no difference. > > And to repeat, the background and foreground sessions are run by the > same user, so I think the problem is "how it is being run" rather than > "who is running it". > > Adrian Check your XDG_RUNTIME_DIR and/or PULSE_COOKIE settings. I had to set theses to get vlc to play properly from a task set from a non-terminal run file though a bluetooth speaker. HIH -- Chris Elvidge, England I WILL NOT INSTIGATE REVOLUTION Bart Simpson on chalkboard in episode 7G06 --- PyGate Linux v1.5 * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10) .