[12:25] BTW MUG Meeting tonight (http://mug.org) [12:26] We're going to be remote for the forseeable future so if you've wanted to come to a meeting this is as good a time as any. ;) [14:13] http://n-gate.com/hackernews/2020/09/07/0/ [14:32] lol, I've read all of that. Funny site though and I like how they put hacker in quotes. [14:33] My favorite client is still materialistic for android. [14:33] Though it could use some updating [14:35] I didn't see this mentioned though. I thought it was big news https://linuxreviews.org/%22Linusgate%22_Leaked:_Over_250_Messages_About_Code_of_Conduct_Complaints_Against_Linus_Torvalds [14:49] I'm sure there's a point in there but damned if I can find it [17:32] Does anyone know what might prevent a program run as a user cron job from playing sound to the ALSA driver? [17:32] The program in question works just fine when run from the terminal. [17:32] env vars [17:33] Ok, thanks. I need to go spelunking through my env to see what might be missing, then. *sigh* [17:35] The odd thing is that it used to work, meaning something changed in my setup since then. [17:37] brian__: Also could be that ALSA is locked by another process [17:41] It's looking like env vars. Running bash with an empty env gets me "Connection refused" and "Inappropriate ioctl for device" messages. [17:42] Does it work from cron when you're logged in? [17:43] No. [17:43] what app? [17:43] how are you opening the sound device / executing th is? :) [17:43] mpg123 or something? [17:44] paplay from the pulseaudio-utils package. [17:45] paplay to the alsa device? [17:47] The actual program is grandfatherclock. I initially thought it was going straight to ALSA when I glanced at the config file, but it's actually calling paplay which then tries to play a .au sound file to Pulse audio. [17:48] ah, OK [17:48] So it's not alsa, but more likely pulseaudio [17:48] Yes. [17:49] is it a system-wide pulseaudio or pulseaudio that's started by your user? [17:49] If it's Ubuntu then you likely have two pulseaudio daemons running [17:49] one for lightdm and one for your user [17:50] My user. [17:50] I just see the one. [17:50] Ok, that makes sense, then. [17:50] you might have some luck adding "--verbose" to see what it's trying to run [17:51] because pulseaudio tries to smooth over a lot of crap happening at the soundcard level [17:52] The "connection refused" is likely that the daemon isn't running [17:52] the inappropriate ioctl makes me wonder what device it's trying to run against, and if it's actually trying some odd fallback or something [17:52] but --verbose should give you more details on what its doing. [17:52] Good luck! [17:52] You're right, I don't think it is. top tells me that pulseaudiop is being run with the --daemonize=no options. [17:53] That's likely the gdm version [17:53] I'm running KDE. [17:53] erm, whatever KDE does then. ;) [17:54] check the user that its running against [17:55] It's running as my user. [17:57] what about PULSE_SERVER envvar? [17:57] Not defined. [18:00] what does pax11publish or xprop -root PULSE_SERVER say? [18:00] not found [18:01] no pax11publish command? hrmf. [18:01] I have it. It just doesn't print anything. [18:02] And now I've messed everything up. My KDE volume control widget is no longer recognizing the ouput device (Pulse Audio). [18:04] I'm going to log out and log back in to try getting KDE's Pulse Audio config to work again. [18:45] Finally got it. I needed to configure pulseaudio to set up a unix socket that clients can use. [18:46] Ah, cool [18:46] Glad it got sorted [22:41] https://octodon.social/@craigmaloney/104831655861756082