PDA

View Full Version : sound stop working after loging off



engamrfuad
5th November 2017, 10:21 AM
i have a toshiba laptop satallite l850-b404 ...im on fedora 26 everything is working fine and awsome but when i logoff and then logon again the sound stops.... and when i try to use alsamixer the output as following :


metallist@raptorx ~]$ sudo alsamixer
[sudo] password for metallist:
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused


i dont know what is the problem ?

AlexTheoto
5th November 2017, 02:01 PM
You don't need root permissions to use alsamixer. Don't use sudo.

donatom
5th November 2017, 07:04 PM
If you don't have pavucontrol (Pulse Volume Control), install it using dnf. When you log back in -- if audio no longer works -- open up pavucontrol. Use upper right arrow to navigate to "Configuration". Make sure your sound card is listed. If not click on listed card and then choose the correct one from the drop-down menu. Then with top left arrow navigate to "Output Devices". Make sure nothing is muted and that the output device listed is the correct one (headphones, etc.) Then click on upper left arrow again to navigate to "Playback". Again make sure nothing is muted. On bottom-right click on "Show" and choose "All Streams"

As AlexTheoto says, do not use root/sudo when you use alsamixer or pavucontrol.

By doing the above, you should be able to get audio back.

It seems that when you log out, your system is for some reason making changes to your pavucontrol, changes that prevent audio from working.

Hope this helps.

engamrfuad
5th November 2017, 08:38 PM
yes true ..i shouldnt use sudo with alsamixer ...i tried toopen pavucontrol ...but is just tell me that pulseaudio failed because PULSE_SERVER in the enviroment/x11 or default-server in the client.conf is misconfigured
so i tried to run start-pulseaudio-x11 manually but that didnt work either ...
i have to restart the maching to work ....

donatom
5th November 2017, 10:45 PM
. . . so i tried to run start-pulseaudio-x11 manually but that didnt work either ...

Try "pulseaudio -k" (kill) and then "pulseaudio -D" (start as daemoh) instead.

FedoraUser101
7th March 2018, 03:29 AM
This is the reason it can't be fixed.

https://bugzilla.redhat.com/show_bug.cgi?id=1510301

These people refuse to do their jobs and fix things they are supposed to, and they are told to, fix. They are using lazy excuses to avoid what they are supposed to fix and making up their own definitions as to what needs to be done by scueing the ones given to them and acting like it's not necessary. They think we should have to manually use pulseaudio kill every logout. There is no solution period.

I'm having the same problems btw. Still no way around it. No solutions work. No command to kill or restart it works without a restart. And from what they said it won't be fixed in F28. So it won't be fixed for years while they sit on their lazy asses not fixing something that would be trivial on their end. Are they paid employees? Do they have a supervisor? This is redhat, so I'm imagining they might have a boss in this case(or similar.). Is there anyone who can force them to get this done and do what they are supposed to?

https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2017-11-09/f27-final-and-server-beta-go-no-go-meeting.2017-11-09-18.02.html


AGREED: 1510301 - RejectedBlocker (Final) - we agreed that this is an annoyance, but clearly doesn't constitute a criteria violation, and it's reasonable to just document 'wait 20 seconds to log back in again (or change the config setting)' (adamw, 18:47:34)

They find this acceptable? This is a joke! It doesn't matter if it's manual or automated to force 20 seconds for a software restart. They are to blame. From what one person said it is clearly a violation of their critera. They just use excuses when they don't want to fix something. And then they never fix it anyway. Gotta love modern programmers. These people existing in software make sure more compitent hard working ones never go into the field. it's doubly bad.


AGREED: 1497897 - RejectedBlocker (Final) - since this doesn't happen consistently (and doesn't seem to affect many people at all), and the entry still works, we don't think this is serious enough to constitute a violation of the criterion. We will document it in CommonBugs (adamw, 18:41:08)

They don't even have the information to know if it's troubling people! It's a lot more than gnome shell. I'm using mate also and it's a problem. I gaurantee you it's all desktops at this point. Every desktop I've tried does this.

This is the same nonesense as to why KDE Plasma is now completely ususable. I don't mean figurativly. I mean anything you use on the desktop freezes and crashes it every single action. You can't even click the menu button to look at applications or try to exit the desktop without rebooting by pressing the button on your machine. It's literally unusable!(And it broke all reference to desktop icons and locations like several other desktop version atm.) Yet they have the gaul to release a KDE plasma version! Do they check anything they release?! it's literally pointless to go into it. It's literally a trap as you can't do anything once in it. All you can do it press the reboot button on the machine. So guess which users can't use the desktop. Ones without access to the physical machine! So, much for secure remote desktop setups for anyone using that.

BTW, this doesn't happens sometimes. It happens every time. Specifically when you logout after the computer has been in and out of sleep or similar. I doubt it even needs that. It's a constant problem. And unfortunately other programs need you to log out to fix their issues. Meaning you have to reboot every time. Either way anyone who logs out after sleep or similar occurs ends up loosing sound. This is as core of an issues as it gets.

I have been going through nearly every desktop I can find because they all have one overwhelming problem or another and I can't use them. This stuff needs to stop!!

What else doesn't work:

Setting:
sudo gedit /etc/pulse/daemon.conf
; exit-idle-time = 1
; scache-idle-time = 1

; exit-idle-time = 0
; scache-idle-time = 20

; exit-idle-time = 0
; scache-idle-time = 0

sudo gedit /etc/systemd/logind.conf

KillUserProcesses=yes

#KillUserProcesses=yes

BTW, I'm actively changing settings and relogging/rebooting my computer over and over to test stuff. Something none of you can spend 2 seconds doing yourselves.

What works:
exit-idle-time = 0

Why does it work when I remove the, ";". I was under the impression that was not to block out the lines of code like a #... Are those not default settings?! If those lines are to be read that may be part of the issue.


Adam Williamson 2017-11-07 14:15:03 EST

-1 blocker. I don't believe this violates the criterion cited, which is: "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present". For a start, pulseaudio is not a system service. For a second, in basic usage - which is really what the criterion covers - it *does* start correctly. It only fails in this more complex scenario (logging out and back in again).

These people are full of crap! In that circumstance it does not start properly. So it fits the critera. That is the point of those guidelines!!!!!!! It has NOTHING to do with if it only start up on the initial boot up or login!!!!!!!! If it doesn't start up at any start it is supposed to be fixed!

BTW, as far as I can tell, this has nothing to do with how long it takes to log out and in. I'm pretty certain that does not effect it.


Petr Schindler 2017-11-08 09:40:35 EST

I was able to reproduce this with KDE. But I don't think that we should block on this. I agree with Adam that to break it user has to do more steps. This could problem on multi-user systems (like in schools). But I don't think that running sounds is the main feature on such systems.

There is quite an easy workaround:
pkill pulseaudio; pulseaudio --start

-1 blocker; +1 FE in case that we won't ship this week.

That is funny because the imbecilic morons teaching our children now increasingly use nothing but video/audio means to raise our lazy brats and teach them to be giant idiots... And it will keep going that way. So that is incorrect and highly unlikely! they also cannot show version of the fat pig and his idiot spider friend without sound. That or they have to resort to using the schools playrights to do the audio live which may be an issue if too many have to watch the video at once. I don't think you can take the time out of all classes for one english class unless they've change the class scheduling suffiently to make everyone watch something at the same time.(I guess they could use remote speakers and time the videos though. So, implement the ability to do that conveniently for them! Using their old fashioned audio systems.)

How much you fix is an example to others and sets the tone. So regardless of the education argument it's better to do the work for the long term. It at least inspires work ethic which is better than everything else.

antikythera
7th March 2018, 09:51 AM
actually, if you follow in comments #16 and #17 the problem pulseaudio issue should have been fixed by a new update pulseaudio-11.1-15.fc27, it may take a while to filter down to all testing-update mirrors. the apparent 'lack of progress' is aggravated by some affected users are also feeding back via bodhi comments so bugzilla threads can become outdated with regards relevant new information supported by necessary attachments needed to fix flaws. so if it now works it will also be a zero-day patch for F28 if not actually included in the ISO

red hat sponsor fedora project and do not own it. you don't actually pay for technical support, what you get is free to use and therefore you have to be patient sometimes when dealing with bugs. red hat provide some man hours from a few of their full-time employees per week. this doesn't mean they are all working on Fedora 40 hours a week.

they are working for the long term but you have to remember this is an entirely independent community driven distribution. RHEL is built from some packages first tried in Fedora but not all of them which is why they provide the lion share of sponsorship.