Try this: https://www.jookia.org/wiki/System-wide_speakup#Running_espeakup_as_your_user On Wed, May 31, 2023 at 03:05:12PM -0500, Martin McCormick wrote: > I am writing this with a bit of a smile but not much of one. I > have an orca AMD64 system running Bullseye and it's almost > perfect except for audio which seems to be a right of passage. > > Right this moment, I am getting audio via a > HDMI-to-analog converter and it works fine but there is this > perfectly good built-in sound card on the mother board which I > know functions because the HP Rizen system had Windows10 on the > SSD hard drive and that audio was just fine. > > Here's the issue and it looks like a number of people > have it if you do a duckduckgo search and these people are not > trying to get a screen reader to work. They are just trying to > make sound work on an otherwise normal setup. > > In Linux, one should be a member of the audio group so, > if it's your system, you need to use pw to add yourself to the > audio group. > > That used to be good enough and your card 0 according to > aplay -list would work as it should and amixer printed out all > the "Simple Mixer Control's" that you could use for your > particular sound system. > > This system is a bit over a year old and has 16 GB of RAM > so it's not a slouch system but it has a case of the problem I am > describing. > > In one sentence, Audio doesn't work on that system unless > you are logged in as root. > > That's not right since the unix philosophy is to do as > little stuff as root as you have to avoid making big mistakes > like cd /;rm -r * > OOPS! > > Anyway, if you su to root or do sudo amixer, card 0 is > right there and all the controls report sensible value settings. > Do amixer as you and amixer feels compelled to makeup settings > based on nothing present. Your adjustable controls all have > 65536 steps and they don't do anything. > > The research I did shows a different fiddly solution for > everybody who posted and many did get non-root access to their > sound card but I think nobody has the real answer because so many > different people had so many solutions that worked for them but > not others who tried the same things. > > Here's what I have noticed so far. I have some raspberry > Pi's, 1 23-year old I86 Dell running stretch, I think and one > 19-year-old I86 system running buster and if you do ls -l > /dev/snd on any of those systems including the new HP running > bullseye, they all have exactly the same ALSA ownership:group > listing which is root:audio so the problem's not there. > > The older ones work right and bullseye doesn't yet. > > As for the fiddly solutions, some people had timidity > running which is a midi program. They weren't using it so, when > they removed it, they got their proper functionality with user > level access to audio by audio group members. > > On my system, timidity is not even installed and never > was so what now, Coach? > > The othere fiddly solutions were even worse, involving > permission changes or other things that might end up causing more > trouble in the long run. > > A long time ago, any user of the system could call aplay > or whatever the audio player was at the time and pranksters would > telnet in from anywhere and tell the sound application to play > whatever sound or music they thought would bother the heck out of > whoever was physically near the system such as people in a college computer > lab. > > On my system, the first sound card supports speakup plus > mplayer and sox applications that use aplay so everything would > have to be root to work. > > Are there any acceptable solutions to get back user-level > access to the sound card? > > Sorry for the length of this post, but what gives, here? > > Martin >
