[arch-general] problem with pulseaudio when resuming from pm-suspend
Hello, I use pulseaudio on my laptop. I start it by `start-pulseaudio-x11` in something like .xinitrc (I use a standalone wm with lxdm). When I resume from pm-suspend, the system beeper issues several beeps; when I open a urxvt, a bash completion failure will issue a beep too. However when any program that talks to pulseaudio starts (or try again to talk to it), e.g. start pavucontrol, everything is normal again. Any help is appreciated. Thanks. -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591
On Fri, 2012-03-09 at 18:27 +0800, XeCycle wrote:
Hello,
I use pulseaudio on my laptop. I start it by `start-pulseaudio-x11` in something like .xinitrc (I use a standalone wm with lxdm). When I resume from pm-suspend, the system beeper issues several beeps; when I open a urxvt, a bash completion failure will issue a beep too. However when any program that talks to pulseaudio starts (or try again to talk to it), e.g. start pavucontrol, everything is normal again.
Any help is appreciated. Thanks.
Pardon for my question. Do you really need the advantages of PA for your kind of audio usage? For the way I'm using PA it don't has an advantage, but is a PITA only, hence I never install it. - Ralf
On Fri, 2012-03-09 at 12:30 +0100, Ralf Mardorf wrote:
On Fri, 2012-03-09 at 18:27 +0800, XeCycle wrote:
Hello,
I use pulseaudio on my laptop. I start it by `start-pulseaudio-x11` in something like .xinitrc (I use a standalone wm with lxdm). When I resume from pm-suspend, the system beeper issues several beeps; when I open a urxvt, a bash completion failure will issue a beep too. However when any program that talks to pulseaudio starts (or try again to talk to it), e.g. start pavucontrol, everything is normal again.
Any help is appreciated. Thanks.
Pardon for my question. Do you really need the advantages of PA for your kind of audio usage? For the way I'm using PA it don't has an advantage, but is a PITA only, ^^ audio hence I never install it.
- Ralf
Pardon for my question. Do you really need the advantages of PA for your kind of audio usage? For the way I'm using PA it don't has an advantage, but is a PITA only, ^^ audio hence I never install it.
does every single question about pulseaudio really need to be confronted with a holy war against pulseaudio? sheesh... Please, if you're not going to address the question, let it rest. Apologies for the noise.
I use pulseaudio on my laptop. I start it by `start-pulseaudio-x11` in something like .xinitrc (I use a standalone wm with lxdm). When I resume from pm-suspend, the system beeper issues several beeps; when I open a urxvt, a bash completion failure will issue a beep too. However when any program that talks to pulseaudio starts (or try again to talk to it), e.g. start pavucontrol, everything is normal again.
what does lsof /dev/snd/* say when you resme from pm-suspend? == John K Pate http://homepages.inf.ed.ac.uk/s0930006/ -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Am Fri, 09 Mar 2012 11:51:01 +0000 schrieb John K Pate <j.k.pate@sms.ed.ac.uk>:
does every single question about pulseaudio really need to be confronted with a holy war against pulseaudio?
As long as it is such a crap, still doesn't work, doesn't support every sound and audio card, causes more problems than it solves - maybe with a few exceptions -, and is so extremely hyped and forced to being installed as a dependency by several distros and PA fanboys, I guess it will. If PA would be treated as a normal, and especially optional piece of software which can, but doesn't need to be installed, and/or if the PA devs will do their homework and fix all the issues which always lead to those discussions, I guess those discussions will end. But only then. Heiko
On Fri, 2012-03-09 at 13:15 +0100, Heiko Baums wrote:
Am Fri, 09 Mar 2012 11:51:01 +0000 schrieb John K Pate <j.k.pate@sms.ed.ac.uk>:
does every single question about pulseaudio really need to be confronted with a holy war against pulseaudio?
As long as it is such a crap, still doesn't work, doesn't support every sound and audio card, causes more problems than it solves - maybe with a few exceptions -, and is so extremely hyped and forced to being installed as a dependency by several distros and PA fanboys, I guess it will.
If PA would be treated as a normal, and especially optional piece of software which can, but doesn't need to be installed, and/or if the PA devs will do their homework and fix all the issues which always lead to those discussions, I guess those discussions will end. But only then.
Heiko
The OP is willing to blacklist pcspkr and IIUC pulseaudio isn't the cause for this particular problem. For my kind of usage the PC speaker is very important to signal events, since I can't use "desktop sounds". The OP explained why he needs PA, so we now should stop talking about PA. This issue is solved. OTOH, I agree that we always should point to PA, if somebody sent a request regarding to audio issues, while PA is installed. It has nothing to do with a war, it's simply a shot in the dark, that most of the times will fix audio issues. I wonder about that tendency, that referring to PA is unwanted. If somebody would run into issues with e.g. a DE, an app to handle networks, it's ok to recommend testing another DE, app to handle networks etc.. There are just a few borked things, where it's completely unwanted to portend that they are buggy, experimental or known for issues. - Ralf
On Fri, 2012-03-09 at 11:51 +0000, John K Pate wrote:
does every single question about pulseaudio really need to be confronted with a holy war against pulseaudio?
No and it's not a holy war for me. I only try to help when people run into issues that might be related to PA, IOW if there's an issue with audio and PA is installed, I always recommend to get rid of it, if somebody hasn't a good reason to use it, since most of the times getting rid of PA, will solve the troubles. If it does feel like a holy war for you, when other people and I recommend to get rid of PA, if it shouldn't have an advantage for the users needs, than you probably should reconsider your question. - Ralf
John K Pate <j.k.pate@sms.ed.ac.uk> writes: [...]
what does lsof /dev/snd/* say when you resme from pm-suspend?
Before I suspend: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME pulseaudi 1321 xecycle 22u CHR 116,6 0t0 501 /dev/snd/controlC0 pulseaudi 1321 xecycle 27u CHR 116,6 0t0 501 /dev/snd/controlC0 After I resume: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME pulseaudi 1321 xecycle 22u CHR 116,6 0t0 501 /dev/snd/controlC0 pulseaudi 1321 xecycle 27u CHR 116,6 0t0 501 /dev/snd/controlC0 After I resume and start pavucontrol: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME pulseaudi 1321 xecycle 22u CHR 116,6 0t0 501 /dev/snd/controlC0 pulseaudi 1321 xecycle 27u CHR 116,6 0t0 501 /dev/snd/controlC0 Yes, as you see, they're perfectly the same. `diff -s` said so. Thank you. -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591
Ralf Mardorf <ralf.mardorf@alice-dsl.net> writes: [...]
Pardon for my question. Do you really need the advantages of PA for your kind of audio usage?
Yes. I need some low-latency support, but jack introduced more problems than pulseaudio did. And pulseaudio does provide a reasonable latency for me. Another feature is per-application volume setting, e.g. it remembers I usually don't want any audio From Flash.
For the way I'm using PA it don't has an advantage, but is a PITA only, hence I never install it.
- Ralf
-- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591
On Fri, Mar 9, 2012 at 10:27 AM, XeCycle <xecycle@gmail.com> wrote:
I use pulseaudio on my laptop. I start it by `start-pulseaudio-x11` in something like .xinitrc (I use a standalone wm with lxdm). When I resume from pm-suspend, the system beeper issues several beeps; when I open a urxvt, a bash completion failure will issue a beep too. However when any program that talks to pulseaudio starts (or try again to talk to it), e.g. start pavucontrol, everything is normal again.
My guess is that what happens is that pulseaudio blocks the sound device, and that's the reason you don't hear the beep when it is running (i.e. when sounds play). Disabling PA as Ralf suggests would in this case not help at all, and likely just make it worse (I wish people would stop suggesting to disable PA regardless of what the problem is, in most cases this is not going to make things easier). If I understand correctly your underlying problem can be solved by blacklisting the pcspkr module, that should make sure the kernel will no longer beep. Cheers, Tom
Am Fri, 9 Mar 2012 11:45:50 +0000 schrieb Tom Gundersen <teg@jklm.no>:
Disabling PA as Ralf suggests would in this case not help at all, and likely just make it worse (I wish people would stop suggesting to disable PA regardless of what the problem is, in most cases this is not going to make things easier).
I'm not sure about that, but usually you get to hear the opposite. I mean, nowadays if a sound problem occurs, regardless of whether it is caused by ALSA or whatever, it's usually suggested to install and activate PA. This usually doesn't help, too. That said, suggesting to disable PA is most likely a better help than suggesting to enabling it.
If I understand correctly your underlying problem can be solved by blacklisting the pcspkr module, that should make sure the kernel will no longer beep.
In this case you're likely right with your suggestion. Heiko
Tom Gundersen <teg@jklm.no> writes: [...]
If I understand correctly your underlying problem can be solved by blacklisting the pcspkr module, that should make sure the kernel will no longer beep.
Thanks, this worked. -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591
On Fri 09 Mar 2012 11:45 +0000, Tom Gundersen wrote:
On Fri, Mar 9, 2012 at 10:27 AM, XeCycle <xecycle@gmail.com> wrote:
I use pulseaudio on my laptop. I start it by `start-pulseaudio-x11` in something like .xinitrc (I use a standalone wm with lxdm). When I resume from pm-suspend, the system beeper issues several beeps; when I open a urxvt, a bash completion failure will issue a beep too. However when any program that talks to pulseaudio starts (or try again to talk to it), e.g. start pavucontrol, everything is normal again.
My guess is that what happens is that pulseaudio blocks the sound device, and that's the reason you don't hear the beep when it is running (i.e. when sounds play). Disabling PA as Ralf suggests would in this case not help at all, and likely just make it worse (I wish people would stop suggesting to disable PA regardless of what the problem is, in most cases this is not going to make things easier).
I'm confused. Why is pulseaudio so necessary? I just use alsa for sound and have no problems whatsoever. Granted, I don't use one of them fancy shmancy desktop environments.
On Fri, 2012-03-09 at 18:37 -0500, Loui Chang wrote:
I'm confused. Why is pulseaudio so necessary? I just use alsa for sound and have no problems whatsoever. Granted, I don't use one of them fancy shmancy desktop environments.
IMPORTANT! WE NEED TO REPEAT THIS AGAIN AND AGAIN! Those fancy-schmancy DEs make PA a dependency, but that doesn't mean that PA is needed for those DEs. De facto audio out doesn't work with many sound cards, if PA is enabled. If it's disabled audio out does work with Jack + ALSA backend and ALSA only. "Disabling" PA doesn't work as expected for every distro, but usually simply replacing PA by a dummy package has got no unwanted side effect. For Archlinux there's a clean solution at least for GNOME, https://aur.archlinux.org/packages.php?ID=48718 , I don't care about it, but installed a dummy package for PA, so what ever I wish to install, I don't need to take care, if PA is a dependency. AFAIK there's no DE that needs PA. Making PA a dependency for a DE, is like making X a dependency for brltty. - Ralf
On Sat, Mar 10, 2012 at 12:37 AM, Loui Chang <louipc.ist@gmail.com> wrote:
My guess is that what happens is that pulseaudio blocks the sound device, and that's the reason you don't hear the beep when it is running (i.e. when sounds play). Disabling PA as Ralf suggests would in this case not help at all, and likely just make it worse (I wish people would stop suggesting to disable PA regardless of what the problem is, in most cases this is not going to make things easier).
I'm confused. Why is pulseaudio so necessary?
No one is claiming that PA is necessary. Just that removing it without further thought is not going to necessarily make things any easier.
I just use alsa for sound and have no problems whatsoever.
I'd guess that most users of both PA and ALSA have no problems at all. There are a few cases when swapping from one to the other might be a good idea: Move from PA to ALSA: If your hardware/drivers do not work well with PA. There are some examples of this, but for the vast majority of hardware this is not a problem. Move from ALSA to PA: If you have problems getting your mixer levels or other settings right. If you are have issues with too high power consumption. If you need audio to work with fast-user-switching. If you want per-app volume controls. If you want bluetooth audio to work out of the box. If you want low-latency, but don't want to use Jack. Etc... In the beginning PA caused a lot of grief for a lot of people, and some distros (not Arch!) moved to it too soon. These days there should be no need to especially caution against PA, it has its bugs and issues as all software does, but nothing out of the ordinary. -t
On Sat, 2012-03-10 at 01:17 +0100, Tom Gundersen wrote:
No one is claiming that PA is necessary. Just that removing it without further thought is not going to necessarily make things any easier.
Related to this thread: Since PA isn't needed for audio, troubleshooting most of the times will become easier without PA, even if PA doesn't cause the issue itself. OT: Some people, not only deaf people, don't need audio with or without PA, it's abstruse making it a dependency. - Ralf
Some people, not only deaf people, don't need audio with or without PA, it's abstruse making it a dependency. No it's not. The developers decided they want it a part of their desktop environment and now it's a dependency. You obviously have problems with PA, I saw your other thread, but this doesn't mean it's useless. Have you tried reporting your problems to PA and providing data about your cards so someone can fix them? Maybe contact Gnome/KDE and purpose to make
On Mar 10, 2012 2:34 AM, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote: pulseaudio optional or at least, easy to disable? That said, I really like pulseaudio. It fixed every single problem I had with flash playing audio without killing everything else and the application-specific control is nice.
On Sat, 2012-03-10 at 10:35 +0200, Thanasis Georgiou wrote:
Some people, not only deaf people, don't need audio with or without PA, it's abstruse making it a dependency. No it's not. The developers decided they want it a part of their desktop environment and now it's a dependency. You obviously have problems with PA, I saw your other thread, but this doesn't mean it's useless. Have you tried reporting your problems to PA and providing data about your cards so someone can fix them? Maybe contact Gnome/KDE and purpose to make
On Mar 10, 2012 2:34 AM, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote: pulseaudio optional or at least, easy to disable?
That said, I really like pulseaudio. It fixed every single problem I had with flash playing audio without killing everything else and the application-specific control is nice.
At the beginning I only wanted to help, I didn't start that discussion about PA for this thread, other people did start it. --- It's correct that most Linux users are comfortable with PA, but a wide range of computer users don't use Linux, because of audio and video issues. Since I use Xfce I don't know if GNOME3 does feature a button to disable and enable PA. Pro-audio users aren't a minority of computer users, they are just a minority on Linux. Professional sound cards, are cheaper than a consumer stereo, so IMO such cards are also interesting for consumers. You can get semi-professional Envy24 based cards for around 30,-€ at Ebay. It's not wise to assume that PA has a good design. The pro-audio designs for the cards mixers are made to be used easy as anything. You don't need to be an audio engineer to use such a mixer. The "desktop sound" concept is a bad idea. It's a misconception to assume, because PA already isn't easy to understand, that professional stuff must be more complicated. It's the other way around. Professional audio concepts are older than computers are and were designed to keep the usage easy. If PA would work that good as you claim, than I wonder why people all the times have got issues or think that they've got issues regarding to PA. If I recommend to get rid of PA, if somebody shouldn't need it, it seems to be a crime. If it's recommended to get rid of pcspkr, if somebody doesn't need it, it's ok. (I know that PA isn't the cause regarding to this thread.) Anyway, it's the same kind of thing. PA is a Holy Grail, other stuff, e.g. pcspkr isn't. We would have more Linux users = more hardware vendors that would care about Linux, if some developers and maintainers wouldn't ignore the fact that people are interested in multimedia PCs. Since PA is a show-stopper, another e.g. is dropping the nv driver (not done by Arch Linux :), people stay at Apple and Microsoft. The argument of the PA fans is, that it's working for them and for the minority of Linux computer users, but they ignore the signs of the times. The computer is able to replace your stereo, your television etc., if you can use it with good multimedia hardware. Another argument is, that PA should make things easier, but it doesn't, it's design limits functionality and make everything more complicated. Btw. I DON'T HAVE ANY PA ISSUE FOR MY ARCH! I don't use PA and FWIW I use pcspkr without any trouble. --- At the beginning I only wanted to help, I didn't start that discussion about PA for this thread, other people did start it. I hope we can stop it, thanx, Ralf
Am Sat, 10 Mar 2012 10:35:07 +0200 schrieb Thanasis Georgiou <sakisds.s@gmail.com>:
No it's not.
Sorry, but it is.
The developers decided they want it a part of their desktop environment and now it's a dependency.
And that's the problem and the reason, why those flame wars regularly pop up if PA is mentioned. Those dependencies are absolutely not necessary resp. if those DEs are designed to only work with PA then it's a misconception in those DEs. I do see that PA can give some additional features for some users, but those users who really need these features are the vast minority. Who really needs to move a sound gapless from an internal sound card to a USB sound card? Who really needs PA to set different volume levels for different programs? Every program I know has its own volume control. So PA may be seen as a little bit more comfortable, but it's not necessary. Just two examples. The mixing of the audio output of several programs is also not an argument for PA, because ALSA does this perfectly with its dmix by default for years. Well, meanwhile there seems to be an issue with some software not detecting an audio device anymore if another software is already playing sound. Stopping both programs and starting them in reverse order makes both programs play sound at the same time again. This seems to mostly happen with KDE/Qt-Software. But that's a different topic, and most likely a bug in either kdelibs, qt or ALSA, but installing PA is not a solution. So there may be a few users for whom PA makes sense, but not for the most people.
You obviously have problems with PA, I saw your other thread, but this doesn't mean it's useless. Have you tried reporting your problems to PA and providing data about your cards so someone can fix them?
Yes, there is a bug report about the ice1712 (envy24) audio cards in upstream's bug tracker for years. It was recently been fixed by giving a asound.conf for ALSA which cripples those (semi-)professional audio cards to simple stereo cards. I then reopened this bug, explained why this is not a solution, and never heard anything about this again. Instead the PA developers now regularly say that PA is not meant for professional users but only for consumers. This also proves that PA is not working correctly and most likely never will. And this also proves that PA should not be made as a dependency for DEs, because it is not meant for everybody. That's why I regularly say that there wouldn't be a problem if PA is only treated as a normal, and especially optional piece of software, and not as a dependency for anything. Keep in mind that most users use a stereo or maybe surround sound card like SoundBlaster or AC'97, I guess like you. I have no doubt that PA works with such sound cards. But even if probably most users use such cards those are only two cases. There are a lot of ice1712 (envy24) audio cards from the simplest ones like M-Audio Audiophile 24/96 up to the most professional ones like the RME Hammerfall which are totally not supported by PA. And if you knew those audio cards and how they are working you would agree that crippling them to stereo is really not a solution, not even a dirty workaround. I don't know how many other sound cards don't work with PA. ALSA, btw., supports every sound cards incl. those ice1712 cards out of the box, maybe in conjunction with envy24control from alsa-tools. So that the PA developer usually blame ALSA for being the reason for the PA issue is also nonsense. It's not an ALSA issue, it is a PA issue.
Maybe contact Gnome/KDE and purpose to make pulseaudio optional or at least, easy to disable?
This should indeed be done. I personally don't use GNOME or KDE so I can't file a bug report there. But I will do it for KDE or Qt as soon as I see that the current dmix issues are a KDE or Qt issue.
That said, I really like pulseaudio. It fixed every single problem I had with flash playing audio without killing everything else and the application-specific control is nice.
If you had issues with flash playing audio why didn't file a bug report to Adobe or probably ALSA? I never had any problems with the audio output of flash. Using PA is just a workaround but no fix for this issue. Application-specific volume control may be a nice gimmick but is definitely not necessary as I explained above. With that said Ralf is totally right with his explanations. Heiko
OT: Another reply, just to correct a misunderstanding. On Sat, 2012-03-10 at 15:24 +0100, Heiko Baums wrote:
There are a lot of ice1712 (envy24) audio cards from the simplest ones like M-Audio Audiophile 24/96 up to the most professional ones like the RME Hammerfall which are totally not supported by PA.
RME cards don't use Envy24 chips. I own 2 Envy24 cards and use them for MIDI, but the RME card isn't an Envy24. Anyway, everything regarding to the PA issue you claim IMO is true.
participants (7)
-
Heiko Baums
-
John K Pate
-
Loui Chang
-
Ralf Mardorf
-
Thanasis Georgiou
-
Tom Gundersen
-
XeCycle