From: chris@internal.net   
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)