home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   RBERRYPI      Support for the Raspberry Pi device      21,939 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 21,493 of 21,939   
   Adrian to All   
   Re: aplay oddity   
   24 Oct 25 15:10:39   
   
   MSGID:  6c62d476   
   REPLY: <10dfs4k$2j983$1@dont-email.me> f67fb7e5   
   PID: PyGate 1.5   
   TID: PyGate/Linux 1.5   
   CHRS: CP1252 2   
   TZUTC: 0100   
   REPLYADDR bulleid@ku.gro.lioff   
   REPLYTO 3:633/10 UUCP   
   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)   
   SEEN-BY: 105/81 106/201 128/187 129/14 305 153/7715 154/110 218/700   
   SEEN-BY: 226/30 227/114 229/110 111 200 206 275 300 317 400 426 428   
   SEEN-BY: 229/470 616 664 700 705 266/512 291/111 292/854 320/219 322/757   
   SEEN-BY: 342/200 396/45 460/58 633/10 280 414 418 420 422 509 2744   
   SEEN-BY: 712/848 770/1 902/26 2320/105 5020/400 5075/35   
   PATH: 633/10 280 229/426   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca