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