aplay oddity

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.

I suspect there is some issue with setup of environment variables (e.g. $HOME) when running the script in the background versus interactively.

I did a search for “alsa Unknown error 524” and found this

This would be consistent with my suspicion that the per-user setup for your background versus interactive cases is not exactly the same.

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

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

I would agree, but see above. And why did it work pre-reboot ?

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

In message <10dejui$293ep$ snipped-for-privacy@dont-email.me, The Natural Philosopher snipped-for-privacy@invalid.invalid writes

Thanks.

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

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

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

Thanks.

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

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

See my thread where the Pico SDK barfed on an installayion that hadn't changed...

Lennart Poettering is a genius, isn’t he?