Subj : Re: aplay oddity To : All From : Adrian Date : Fri Oct 24 2025 15:10:39 In message <10dfs4k$2j983$1@dont-email.me>, Chris Elvidge writes >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 > Thanks. >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 The first comes back as : /run/user/1000 and the second isn't set. However, the speakers are wired in, rather than Bluetooth, which may or may not be relevant. Adrian -- To Reply : replace "bulleid" with "adrian" - all mail to bulleid is rejected Sorry for the rigmarole, If I want spam, I'll go to the shops Every time someone says "I don't believe in trolls", another one dies. --- PyGate Linux v1.5 * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10) .