From Newsgroup: comp.sys.raspberry-pi

Pi3 running Bookworm.

I have a python program that runs continuously, that will when it
detects an event call aplay to play a short tune.

This has been working fine, until today. I had to reboot the Pi earlier today, and now the python won't play aplay (the python is running as it
logs when the event happens).

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.
Both command line and python are running under the same user.

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").

Any suggestions on what to hit with the big hammer ?

TIA

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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

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.

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.

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 <https://stackoverflow.com/questions/78913265/pygame-error-alsa-couldnt-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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 23/10/2025 19:09, Adrian wrote:

Pi3 running Bookworm.

I have a python program that runs continuously, that will when it
detects an event call aplay to play a short tune.

This has been working fine, until today.  I had to reboot the Pi earlier today, and now the python won't play aplay (the python is running as it
logs when the event happens).

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.
Both command line and python are running under the same user.

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").

Any suggestions on what to hit with the big hammer ?

TIA

Adrian

I had issues like this that were in the end permissions, although in
this case its hard to see how this happened.

Are you running an audio hat? check its well plugged in
--
“But what a weak barrier is truth when it stands in the way of an hypothesis!”

Mary Wollstonecraft

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

In message <10dei3u$27uve$7@dont-email.me>, Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> 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 ><https://stackoverflow.com/questions/78913265/pygame-error-alsa-couldnt- >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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

In message <10dejui$293ep$1@dont-email.me>, The Natural Philosopher <tnp@invalid.invalid> writes

I had issues like this that were in the end permissions, although in
this case its hard to see how this happened.

Thanks.

That was my initial thought, but then I couldn't see why.

Are you running an audio hat? check its well plugged in

Yes, and it is. The Pi is in a safe place, and is fastened down. Given
that I don't need to make physical contact with the Pi to trigger it, I
can't see why it would work when I've ssh'd in from another machine and
run the command via that terminal, but not when a background process is triggered.

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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 24/10/2025 at 13:18, Adrian wrote:

In message <10dei3u$27uve$7@dont-email.me>, Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> 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
<https://stackoverflow.com/questions/78913265/pygame-error-alsa-couldnt-
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

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

In message <10dfs4k$2j983$1@dont-email.me>, Chris Elvidge
<chris@internal.net> 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?= <ldo@nz.invalid> 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
<https://stackoverflow.com/questions/78913265/pygame-error-alsa-couldnt- >>> 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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 24/10/2025 13:23, Adrian wrote:

In message <10dejui$293ep$1@dont-email.me>, The Natural Philosopher <tnp@invalid.invalid> writes

I had issues like this that were in the end permissions, although in
this case its hard to see how this happened.

Thanks.

That was my initial thought, but then I couldn't see why.

Are you running an audio hat? check its well plugged in

Yes, and it is.  The Pi is in a safe place, and is fastened down.  Given that I don't need to make physical contact with the Pi to trigger it, I can't see why it would work when I've ssh'd in from another machine and
run the command via that terminal, but not when a background process is triggered.

Adrian

What annoys me is that I had almost exactly this, but have no idea how I solved it.

I vaguely remember one of two things - some kind of permissions thing in
the audio device, or needing to install pulse audio
--
To ban Christmas, simply give turkeys the vote.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

In message <10dg96e$2n6ng$1@dont-email.me>, The Natural Philosopher <tnp@invalid.invalid> writes

On 24/10/2025 13:23, Adrian wrote:

In message <10dejui$293ep$1@dont-email.me>, The Natural Philosopher >><tnp@invalid.invalid> writes

I had issues like this that were in the end permissions, although in >>>this case its hard to see how this happened.

Thanks.
That was my initial thought, but then I couldn't see why.

Are you running an audio hat? check its well plugged in

Yes, and it is.� The Pi is in a safe place, and is fastened down.�
Given that I don't need to make physical contact with the Pi to
trigger it, I can't see why it would work when I've ssh'd in from
another machine and run the command via that terminal, but not when a >>background process is triggered.
Adrian

What annoys me is that I had almost exactly this, but have no idea how
I solved it.

I vaguely remember one of two things - some kind of permissions thing
in the audio device, or needing to install pulse audio

What is now puzzling me, is that mid afternoon it started working again
(nohup rather than cron mode). I haven't changed anything since I
fiddled around as described upthread.

Isn't modern technology wonderful.

Thanks to all who have contributed.

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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 24/10/2025 18:11, Adrian wrote:

What is now puzzling me, is that mid afternoon it started working again (nohup rather than cron mode).  I haven't changed anything since I
fiddled around as described upthread.

Isn't modern technology wonderful.

See my thread where the Pico SDK barfed on an installayion that hadn't changed...
--
For every complex problem there is an answer that is clear, simple, and
wrong.

H.L.Mencken

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi


Hello Adrian!

Look through your logs to see what updates have occurred between the two date/time periods.



23 Oct 25 19:09, you wrote to all:

Pi3 running Bookworm.

I have a python program that runs continuously, that will when it
detects an event call aplay to play a short tune.

This has been working fine, until today. I had to reboot the Pi
earlier today, and now the python won't play aplay (the python is
running as it logs when the event happens).

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.
Both command line and python are running under the same user.

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").

Any suggestions on what to hit with the big hammer ?

TIA

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.

Vincent


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Fri, 24 Oct 2025 17:23:42 +0100, The Natural Philosopher wrote:

... or needing to install pulse audio

Lennart Poettering is a genius, isn’t he?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Sat, 25 Oct 2025 07:30:01 +0000, Vincent Coen wrote:

Hello Adrian!

Who's Adrian? This is comp.sys.raspberry-pi.
--
s|b
--- Synchronet 3.21a-Linux NewsLink 1.2