[arch-general] PulseAudio in [testing]
I've put PulseAudio into [testing] some time ago, but received no feedback on this. This either means it works well, or nobody uses it. So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
On Fri, 26 Nov 2010 21:34:18 +0100, Jan Steffens <jan.steffens@gmail.com> wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
I tested it a while on KDE and as expected it has downsides compared to using plain alsa. :-) I lost all controls in kmix except of only one volume control. Xine based players like e.g. Dragonplayer just crash. But Smplayer is a way better and didn't had any problems. In general I don't see any need to use pulse-audio; except Gnome users who wont have any choice in future. But I guess some day it will just work without problems; atm pulse audio support is in early state in some apps. I am still happy to have my good old Soundblaster Live which does mixing in hardware. ;-) -- Pierre Schmitz, https://users.archlinux.de/~pierre
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
I tested it a while on KDE and as expected it has downsides compared to using plain alsa. :-) I lost all controls in kmix except of only one volume control.
The benefit is that Flash will not f**k and lock your sound card.
But Smplayer is a way better and didn't had any problems.
mplayer aditionally should have pulse enabled. The mixer issue is something to discuss about. "alsamixer -c0" is a good way to regain the control over the hardware mixers, but that's probably not very user-friendly. Otherwise pavucontrol has the option to control the volume of each stream separatelly and also to move a stream from one output to another (imagine moving skype from the internal sound card to a bluetooth or usb headset). -- дамјан
On Sat, 27 Nov 2010 13:27:47 +0100, Damjan <gdamjan@gmail.com> wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
I tested it a while on KDE and as expected it has downsides compared to using plain alsa. :-) I lost all controls in kmix except of only one volume control.
The benefit is that Flash will not f**k and lock your sound card.
These problems are solved since years. I even made a test. Playing two flash videos, playing music through mplayer with alsa and starting an old game which uses oss. All this works just fine with plain alsa. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Mon, Nov 29, 2010 at 8:32 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
These problems are solved since years. I even made a test. Playing two flash videos, playing music through mplayer with alsa and starting an old game which uses oss. All this works just fine with plain alsa.
-- Pierre Schmitz, https://users.archlinux.de/~pierre
Slight detail: ALSA's built-in OSS emulation is inside the kernel, meaning it can only use the hardware directly. This bypasses dmix and other extensions of ALSA userspace. You would need to use aoss if you want to use dmix with OSS applications. ossp's ALSA backend is in a bad state, regrettably.
The benefit is that Flash will not f**k and lock your sound card.
These problems are solved since years. I even made a test. Playing two flash videos, playing music through mplayer with alsa and starting an old game which uses oss. All this works just fine with plain alsa.
No, I ment the situation when Flash locks up. When using the Alsa dmix plugin (which enables software mixing of streams from different apps) the first application that starts playing sound is the "master" one, that controls the hardware. When the master is Flash and it locks up (and it does happen often) you loose all sound on the desktop. -- damjan
On Fri, Nov 26, 2010 at 9:34 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
It work perfectly for me on awesome with gnome-volume-control-applet. Thanks! -- Sébastien Luttringer www.seblu.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 26/11/10, Seblu <seblu@seblu.net> a écrit :
On Fri, Nov 26, 2010 at 9:34 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
It work perfectly for me on awesome with gnome-volume-control-applet.
Do you mean pulseaudio-mixer-applet ? How do you manage to do that ? Because when I launch it, nothing happens (no icon in Awesome systray) and then it dies silently... I don't have several Gnome dependencies but the required ones for this applet. - -- radio ianux - http://ianux.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAkzxKHsACgkQwnCHvrZZer2bSQCeJ1BrIWL3Fw3gyfcPd8Od3P7p 5YoAoJSvzFR/NWi5QrneZf6GeQn/vuXB =TnFm -----END PGP SIGNATURE-----
On Sat, Nov 27, 2010 at 4:49 PM, ianux <ianux@free.fr> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 26/11/10, Seblu <seblu@seblu.net> a écrit :
On Fri, Nov 26, 2010 at 9:34 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
It work perfectly for me on awesome with gnome-volume-control-applet.
Do you mean pulseaudio-mixer-applet ? How do you manage to do that ? Because when I launch it, nothing happens (no icon in Awesome systray) and then it dies silently... I don't have several Gnome dependencies but the required ones for this applet.
- -- radio ianux - http://ianux.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAkzxKHsACgkQwnCHvrZZer2bSQCeJ1BrIWL3Fw3gyfcPd8Od3P7p 5YoAoJSvzFR/NWi5QrneZf6GeQn/vuXB =TnFm -----END PGP SIGNATURE-----
It's a panel applet for gnome-panel, not for systray.
So far so good. Testing enabled and KDE. El 26/11/2010 21:34, "Jan Steffens" <jan.steffens@gmail.com> escribió:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
On Fri, Nov 26, 2010 at 2:34 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
It is working ok for me (gnome). Im still a bit confused about the new packages and which one should i install. Is there any instalation guide ? The wiki is obviously out of date. Ignacio
Στις Παρασκευή 26 Νοέμβριος 2010 22:34:18 Jan Steffens γράψατε:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
I was using pulseaudio from back when it was in the community repo. Still everything goes fine, I am using it with kmix from AUR(pulseaudio enabled) so I can control sound volume on each application and soundcard and of course with xine-lib-pulse for the xine phonon backend. Seems that in KDE 4.6 the support of phonon to pulseaudio will go upstream. So far so good.
Στις Σάββατο 27 Νοέμβριος 2010 02:17:59 Δημακάκος Δημάκης γράψατε:
Στις Παρασκευή 26 Νοέμβριος 2010 22:34:18 Jan Steffens γράψατε:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
I was using pulseaudio from back when it was in the community repo. Still everything goes fine, I am using it with kmix from AUR(pulseaudio enabled) so I can control sound volume on each application and soundcard and of course with xine-lib-pulse for the xine phonon backend. Seems that in KDE 4.6 the support of phonon to pulseaudio will go upstream.
So far so good.
Update. Seems that pulseaudio is ok but for now unusable with the xine backend of phonon. I will try with gstreamer, although I don't like it. All these occured since the today's upgrade to phonon 4.4.3. I have sound by vlc, alsa-plugin of PA but nothing from phono with xine backend. The AUR package xine-lib-pulse doesnot seem to work anymore, so I think xine-lib must be rebuilt with pulseaudio support. Also from further testing seems that vlc backend of phonon works nice. So its definatelly a xine-lib issue.
Στις Σάββατο 27 Νοέμβριος 2010 21:11:10 Δημακάκος Δημάκης γράψατε:
Στις Σάββατο 27 Νοέμβριος 2010 02:17:59 Δημακάκος Δημάκης γράψατε:
Στις Παρασκευή 26 Νοέμβριος 2010 22:34:18 Jan Steffens γράψατε:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
I was using pulseaudio from back when it was in the community repo. Still everything goes fine, I am using it with kmix from AUR(pulseaudio enabled) so I can control sound volume on each application and soundcard and of course with xine-lib-pulse for the xine phonon backend. Seems that in KDE 4.6 the support of phonon to pulseaudio will go upstream.
So far so good.
Update. Seems that pulseaudio is ok but for now unusable with the xine backend of phonon. I will try with gstreamer, although I don't like it. All these occured since the today's upgrade to phonon 4.4.3. I have sound by vlc, alsa-plugin of PA but nothing from phono with xine backend. The AUR package xine-lib-pulse doesnot seem to work anymore, so I think xine-lib must be rebuilt with pulseaudio support. Also from further testing seems that vlc backend of phonon works nice. So its definatelly a xine-lib issue.
Mea culpa, it works fine with xine-lib-pulse, but it is in AUR. Also gstreamer backend doesn't work. Oh, and I guess kmix in testing is pulseaudio enabled, isn't it;
On Fri, 2010-11-26 at 21:34 +0100, Jan Steffens wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
Been using it heavily since I had to compile most of it from AUR. If I ever run into a bug it'll be posted up, so yes, everything works fine from my end. Multiple soundcards (built-in and two different external USB) as well as a BT headset, plus module-combine for easy splitting. On an aside, I'm quite glad its been updated so quickly to .22 =)
On Fri, 2010-11-26 at 21:34 +0100, Jan Steffens wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
I haven't really used it since I came to Arch Linux a couple years ago. But my experience with it on Ubuntu has been all negative.
On Fri, 2010-11-26 at 18:46 -0600, Yaro Kasear wrote:
On Fri, 2010-11-26 at 21:34 +0100, Jan Steffens wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
I haven't really used it since I came to Arch Linux a couple years ago. But my experience with it on Ubuntu has been all negative.
Yaro, not meaning to target you specifically (others hold this sort of attitude towards pulse as well), but have you actually used pulseaudio on Arch? Because pulseaudio on Ubuntu (and a couple of years back) isn't really relevant to the implementation Jan is asking about, on Arch.
On Sat, 2010-11-27 at 09:17 +0800, Ng Oon-Ee wrote:
On Fri, 2010-11-26 at 18:46 -0600, Yaro Kasear wrote:
On Fri, 2010-11-26 at 21:34 +0100, Jan Steffens wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
I haven't really used it since I came to Arch Linux a couple years ago. But my experience with it on Ubuntu has been all negative.
Yaro, not meaning to target you specifically (others hold this sort of attitude towards pulse as well), but have you actually used pulseaudio on Arch? Because pulseaudio on Ubuntu (and a couple of years back) isn't really relevant to the implementation Jan is asking about, on Arch.
Only back when it was still in [community] and suffered pretty much the same problems. Forgive me if I say I don't feel Pulse Audio is really [extra] material, though I suppose I should test it again.
On 11/27/2010 02:46 AM, Yaro Kasear wrote:
On Fri, 2010-11-26 at 21:34 +0100, Jan Steffens wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
I haven't really used it since I came to Arch Linux a couple years ago. But my experience with it on Ubuntu has been all negative.
why are you filling my inbox with useless remark if you don't use pulse? The feedback is intended only for GNOME and KDE users _running_ pulse -- Ionuț
On Sat, Nov 27, 2010 at 2:26 AM, Ionuț Bîru <ibiru@archlinux.org> wrote:
On 11/27/2010 02:46 AM, Yaro Kasear wrote:
On Fri, 2010-11-26 at 21:34 +0100, Jan Steffens wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
I haven't really used it since I came to Arch Linux a couple years ago. But my experience with it on Ubuntu has been all negative.
why are you filling my inbox with useless remark if you don't use pulse?
The feedback is intended only for GNOME and KDE users _running_ pulse
-- Ionuț
No, I would like feedback from everyone using the pulse-related packages from [testing], whether they actually run PulseAudio or not. Allan's feedback is very much appreciated. Thanks to everyone for their feedback.
On Nov 26, 2010, at 7:58 PM, Jan Steffens <jan.steffens@gmail.com> wrote: On Sat, Nov 27, 2010 at 2:26 AM, Ionuț Bîru <ibiru@archlinux.org> wrote: On 11/27/2010 02:46 AM, Yaro Kasear wrote: On Fri, 2010-11-26 at 21:34 +0100, Jan Steffens wrote: I've put PulseAudio into [testing] some time ago, but received no feedback on this. This either means it works well, or nobody uses it. So I'm asking for it now, especially from GNOME and KDE users running PulseAudio. I haven't really used it since I came to Arch Linux a couple years ago. But my experience with it on Ubuntu has been all negative. why are you filling my inbox with useless remark if you don't use pulse? The feedback is intended only for GNOME and KDE users _running_ pulse -- Ionuț No, I would like feedback from everyone using the pulse-related packages from [testing], whether they actually run PulseAudio or not. Allan's feedback is very much appreciated. Thanks to everyone for their feedback. Note: this is a resend... Mailman on "gudrun.archlinux.org" apparantly died w/sig 11... All the "works great here" is very encouraging... I love the ideas behind pulse (esp. networking, and systemd... er unrelated :-). I think I'll put it to the test myself. Good to see the overwhelming positive lean; is pulse being considered for an eventual default by chance? C Anthony [mobile]
On 27/11/10 14:51, C Anthony Risinger wrote:
Good to see the overwhelming positive lean; is pulse being considered for an eventual default by chance?
Almost nothing is default on Arch...
On Nov 26, 2010, at 10:57 PM, Allan McRae <allan@archlinux.org> wrote:
On 27/11/10 14:51, C Anthony Risinger wrote:
Good to see the overwhelming positive lean; is pulse being considered for an eventual default by chance?
Almost nothing is default on Arch...
Beh you know what I mean :-) i.e. "recommeded", only-one-or-the-other packages become PKG/PKG-alsa instead of PKG/PKG-pulse, package groups use pulse builds, etc etc... or am I off base? C Anthony [mobile]
On Fri, 2010-11-26 at 23:02 -0600, C Anthony Risinger wrote:
On Nov 26, 2010, at 10:57 PM, Allan McRae <allan@archlinux.org> wrote:
On 27/11/10 14:51, C Anthony Risinger wrote:
Good to see the overwhelming positive lean; is pulse being considered for an eventual default by chance?
Almost nothing is default on Arch...
Beh you know what I mean :-)
i.e. "recommeded", only-one-or-the-other packages become PKG/PKG-alsa instead of PKG/PKG-pulse, package groups use pulse builds, etc etc... or am I off base?
C Anthony [mobile]
Its a bit similar to asking if compiz will be 'default'. Its not an Arch decision anyway, what will happen in future is that upstream apps will either be exclusively pulse or at least prefer pulse. Meaning libpulse will almost always be pulled in anyway, and at least under gnome a fresh install would use pulse. So you should ask Gnome. And the answer is that yes, it will be default on Gnome. If you do not use Gnome, then only if the apps you pull need it.
2010/11/27 Ng Oon-Ee <ngoonee@gmail.com>:
On Fri, 2010-11-26 at 23:02 -0600, C Anthony Risinger wrote:
On Nov 26, 2010, at 10:57 PM, Allan McRae <allan@archlinux.org> wrote:
On 27/11/10 14:51, C Anthony Risinger wrote:
Good to see the overwhelming positive lean; is pulse being considered for an eventual default by chance?
Almost nothing is default on Arch...
Beh you know what I mean :-)
i.e. "recommeded", only-one-or-the-other packages become PKG/PKG-alsa instead of PKG/PKG-pulse, package groups use pulse builds, etc etc... or am I off base?
C Anthony [mobile]
Its a bit similar to asking if compiz will be 'default'.
ehm... sound handling is a pretty basic requisite for the essential functionality of many applications, not to mention my limited "hand"ful of human interfaces, and is usually related to direct hardware access. not really that comparable imo, buuuut maybe on some vague or undefined level ;-) i'd say the ubiquitous use of opengl would maybe present a similar comparison.
Its not an Arch decision anyway
sure it is. we made a python decision regardless of upstream [app] preparedness. this is just an example of fracturing nature of free software; several options can fill a singular need. applications may choose one, the other, or the superposition that is both/neither. Arch's role comes into play when a particular need can only be filled by at most a single option. not the best analogy, but in python's case this is the `python` name; it could be python2, or python3, but not both, and the package tree must compensate. i was under the impression that pulse/alsa/etc. are of this type; only one is at the bottom level directing hardware, others are supported by layers of compatibility and indirection. by all means lmk if that's not the case, as i haven't used pulse since the 'buntu days, though i try to keep up on it's progression.
what will happen in future is that upstream apps will either be exclusively pulse or at least prefer pulse. Meaning libpulse will almost always be pulled in anyway, and at least under gnome a fresh install would use pulse.
So you should ask Gnome. And the answer is that yes, it will be default on Gnome. If you do not use Gnome, then only if the apps you pull need it.
indeed. well i don't use gnome as i'm part of the e17 crew :-), but yeah, unrelated. what i am asking, is whether or not one-or-the-other-only apps (aren't there such cases?) will assume the name APP, APP-pulse, or APP-alsa, or ...., or .... in time, or what the game plan is for this longish term. when the decision is a compile-time choice (this is what i mean by "default" in Arch), will apps use pulse via alsa, or will apps use alsa via pulse? what is arch's stand here? am i missing some critical information that would render my questions nonsensical? just looking for further understanding, feel free to break into a new thread, throw sharp objects, etc. C Anthony
Excerpts from C Anthony Risinger's message of 2010-11-27 08:11:04 +0100:
2010/11/27 Ng Oon-Ee <ngoonee@gmail.com>:
On Fri, 2010-11-26 at 23:02 -0600, C Anthony Risinger wrote:
On Nov 26, 2010, at 10:57 PM, Allan McRae <allan@archlinux.org> wrote:
On 27/11/10 14:51, C Anthony Risinger wrote:
Good to see the overwhelming positive lean; is pulse being considered for an eventual default by chance?
Almost nothing is default on Arch...
Beh you know what I mean :-)
i.e. "recommeded", only-one-or-the-other packages become PKG/PKG-alsa instead of PKG/PKG-pulse, package groups use pulse builds, etc etc... or am I off base?
C Anthony [mobile]
Its a bit similar to asking if compiz will be 'default'.
ehm... sound handling is a pretty basic requisite for the essential functionality of many applications, not to mention my limited "hand"ful of human interfaces, and is usually related to direct hardware access. not really that comparable imo, buuuut maybe on some vague or undefined level ;-)
i'd say the ubiquitous use of opengl would maybe present a similar comparison.
I disagree, sound handling is only essential for audio playback and production programs, and the later don't and won't use pulse. Programs feeping and beeping away all the time are an annoyance at best, a problem at worst.
Its not an Arch decision anyway
sure it is. we made a python decision regardless of upstream [app] preparedness. this is just an example of fracturing nature of free software; several options can fill a singular need. applications may choose one, the other, or the superposition that is both/neither. Arch's role comes into play when a particular need can only be filled by at most a single option. not the best analogy, but in python's case this is the `python` name; it could be python2, or python3, but not both, and the package tree must compensate. i was under the impression that pulse/alsa/etc. are of this type; only one is at the bottom level directing hardware, others are supported by layers of compatibility and indirection.
by all means lmk if that's not the case, as i haven't used pulse since the 'buntu days, though i try to keep up on it's progression.
what will happen in future is that upstream apps will either be exclusively pulse or at least prefer pulse. Meaning libpulse will almost always be pulled in anyway, and at least under gnome a fresh install would use pulse.
So you should ask Gnome. And the answer is that yes, it will be default on Gnome. If you do not use Gnome, then only if the apps you pull need it.
indeed. well i don't use gnome as i'm part of the e17 crew :-), but yeah, unrelated. what i am asking, is whether or not one-or-the-other-only apps (aren't there such cases?) will assume the name APP, APP-pulse, or APP-alsa, or ...., or .... in time, or what the game plan is for this longish term.
Gnome isn't Linux, Gnome is primarily a DAU-top. I don't see why gnome should govern the direction of every distribution. Yes, ubuntu decided that they want to follow and build on gnome, their release cycle etc., but we're not ubuntu.
when the decision is a compile-time choice (this is what i mean by "default" in Arch), will apps use pulse via alsa, or will apps use alsa via pulse? what is arch's stand here? am i missing some critical information that would render my questions nonsensical?
just looking for further understanding, feel free to break into a new thread, throw sharp objects, etc.
C Anthony
I hope that adding PA at compile-time won't mean PA will be required. The piece you miss: PA depends on alsa, it builds on alsa, it can't replace it. At hardware-near levels there's still alsa at work. If you use alsa via PA, then you go alsa-PA-alsa. Btw., last time I checked it was not recommended to program using the PA API, so unless this changed, developers are still supposed to write their programs for alsa or whatever else. --Philipp
On Sat, Nov 27, 2010 at 1:47 AM, Philipp Überbacher <hollunder@lavabit.com> wrote:
Excerpts from C Anthony Risinger's message of 2010-11-27 08:11:04 +0100:
2010/11/27 Ng Oon-Ee <ngoonee@gmail.com>:
On Fri, 2010-11-26 at 23:02 -0600, C Anthony Risinger wrote:
On Nov 26, 2010, at 10:57 PM, Allan McRae <allan@archlinux.org> wrote:
On 27/11/10 14:51, C Anthony Risinger wrote:
Good to see the overwhelming positive lean; is pulse being considered for an eventual default by chance?
Almost nothing is default on Arch...
Beh you know what I mean :-)
i.e. "recommeded", only-one-or-the-other packages become PKG/PKG-alsa instead of PKG/PKG-pulse, package groups use pulse builds, etc etc... or am I off base?
C Anthony [mobile]
Its a bit similar to asking if compiz will be 'default'.
ehm... sound handling is a pretty basic requisite for the essential functionality of many applications, not to mention my limited "hand"ful of human interfaces, and is usually related to direct hardware access. not really that comparable imo, buuuut maybe on some vague or undefined level ;-)
i'd say the ubiquitous use of opengl would maybe present a similar comparison.
I disagree, sound handling is only essential for audio playback and production programs, and the later don't and won't use pulse. Programs feeping and beeping away all the time are an annoyance at best, a problem at worst.
i guess i was trying to draw the parallel that with some things there can only (easily) be one choice. a better example probably would have been the choice between say nvidia/nouveau -- "there can be only one!"
what will happen in future is that upstream apps will either be exclusively pulse or at least prefer pulse. Meaning libpulse will almost always be pulled in anyway, and at least under gnome a fresh install would use pulse.
So you should ask Gnome. And the answer is that yes, it will be default on Gnome. If you do not use Gnome, then only if the apps you pull need it.
indeed. well i don't use gnome as i'm part of the e17 crew :-), but yeah, unrelated. what i am asking, is whether or not one-or-the-other-only apps (aren't there such cases?) will assume the name APP, APP-pulse, or APP-alsa, or ...., or .... in time, or what the game plan is for this longish term.
Gnome isn't Linux, Gnome is primarily a DAU-top. I don't see why gnome should govern the direction of every distribution. Yes, ubuntu decided that they want to follow and build on gnome, their release cycle etc., but we're not ubuntu.
yes i'd agree 100%; to clarify, i'm not asking about gnome/.../... in particular, my inquiry was based on the observation that only one "sound server" (or user-space library) can comfortably run per system, and i was curious as to how that would unfold in terms of pacman/etc.
when the decision is a compile-time choice (this is what i mean by "default" in Arch), will apps use pulse via alsa, or will apps use alsa via pulse? what is arch's stand here? am i missing some critical information that would render my questions nonsensical?
just looking for further understanding, feel free to break into a new thread, throw sharp objects, etc.
C Anthony
I hope that adding PA at compile-time won't mean PA will be required.
yes this is really the best, and maybe this is the norm; i just thought i remembered some packages being exclusively one or the other (mplayer?), but things may have changed. i don't even have any media players installed; the X360 + local shares do this work for me :-)
The piece you miss: PA depends on alsa, it builds on alsa, it can't replace it. At hardware-near levels there's still alsa at work. If you use alsa via PA, then you go alsa-PA-alsa.
ok, i was thinking that PA was eventually going to have new kernel bits included as well. i know (IIRC) that ALSA is a kernel API, and also a userspace API... distinctly separate. programs are normally linked against the userspace API vs. using the kernel directly, correct? and PA has no intentions of ever reaching the kernel in any way shape or form?
Btw., last time I checked it was not recommended to program using the PA API, so unless this changed, developers are still supposed to write their programs for alsa or whatever else.
ok, i suppose i will need to do some more research on all of these components and how they interoperate, thanks Philipp. my only concern is that 99% of the negative feedback is based on ubuntu this or that, usually from years past... ubuntu pretty much jumped the gun; i really like the growing trend of services with DBUS unification, and i think this is a Good Thing for management/security/flexibility. PA appears to be quite stable at this point, and it's great that apps work with or without. somewhat unrelated, but these same questions will rise again, and more fiercely, once systemd is stable and mainstreamed (which is slated for fedora, and IIRC being considered by debian/ubuntu)... the landscape is changing for the better. C Anthony
On Sat, 2010-11-27 at 13:01 -0600, C Anthony Risinger wrote:
On Sat, Nov 27, 2010 at 1:47 AM, Philipp Überbacher
Gnome isn't Linux, Gnome is primarily a DAU-top. I don't see why gnome should govern the direction of every distribution. Yes, ubuntu decided that they want to follow and build on gnome, their release cycle etc., but we're not ubuntu.
yes i'd agree 100%; to clarify, i'm not asking about gnome/.../... in particular, my inquiry was based on the observation that only one "sound server" (or user-space library) can comfortably run per system, and i was curious as to how that would unfold in terms of pacman/etc.
This has nothing to do with pacman. You can have many sound servers installed, you just have to choose yourself which to run. And ALSA is not a sound server. Pulseaudio and JACK are. I run both, at varying times, on the same machine.
The piece you miss: PA depends on alsa, it builds on alsa, it can't replace it. At hardware-near levels there's still alsa at work. If you use alsa via PA, then you go alsa-PA-alsa.
ok, i was thinking that PA was eventually going to have new kernel bits included as well. i know (IIRC) that ALSA is a kernel API, and also a userspace API... distinctly separate. programs are normally linked against the userspace API vs. using the kernel directly, correct? and PA has no intentions of ever reaching the kernel in any way shape or form?
Refer to your own comments below. How does the kernel even come into a discussion on Pulse anyway?
Btw., last time I checked it was not recommended to program using the PA API, so unless this changed, developers are still supposed to write their programs for alsa or whatever else.
ok, i suppose i will need to do some more research on all of these components and how they interoperate, thanks Philipp.
Yep. Simple version, ALSA manages the hardware itself (a tough job, and causes most breakages currently, hardware support on Linux, same old story), pulseaudio plugs in on top of that to manage ALL apps, so it sits between apps and ALSA. In the same way JACK does.
my only concern is that 99% of the negative feedback is based on ubuntu this or that, usually from years past... ubuntu pretty much jumped the gun; i really like the growing trend of services with DBUS unification, and i think this is a Good Thing for management/security/flexibility.
Yeah, what does Ubuntu have to do with Arch anyway?
PA appears to be quite stable at this point, and it's great that apps work with or without. somewhat unrelated, but these same questions will rise again, and more fiercely, once systemd is stable and mainstreamed (which is slated for fedora, and IIRC being considered by debian/ubuntu)... the landscape is changing for the better.
I've been following systemd as well, looks good (though BSD-style init is what we're all used to here). Will perhaps try it out soon. PA is stable, and IMO has been for more than a year.
2010/11/27 Ng Oon-Ee <ngoonee@gmail.com>:
On Sat, 2010-11-27 at 13:01 -0600, C Anthony Risinger wrote:
On Sat, Nov 27, 2010 at 1:47 AM, Philipp Überbacher
Gnome isn't Linux, Gnome is primarily a DAU-top. I don't see why gnome should govern the direction of every distribution. Yes, ubuntu decided that they want to follow and build on gnome, their release cycle etc., but we're not ubuntu.
yes i'd agree 100%; to clarify, i'm not asking about gnome/.../... in particular, my inquiry was based on the observation that only one "sound server" (or user-space library) can comfortably run per system, and i was curious as to how that would unfold in terms of pacman/etc.
This has nothing to do with pacman. You can have many sound servers installed, you just have to choose yourself which to run. And ALSA is not a sound server. Pulseaudio and JACK are. I run both, at varying times, on the same machine.
well, that's why i said "library"; i know the user space alsa is not a server. the fact is, as you've stated, only one impl. can comfortably run at any given moment... but yeah, it doesn't matter too much i guess :-) i was referencing the fact that package managers (including pacman) are pretty one-track minded, and cannot cope with internal variations of the same package whatsoever (causing a need for dynamic dependency handling). portage sort of handles it, with the SLOTS system, but not really... in pacman (and others) a whole new package must be created. so maybe a totally pointless question in the end, but was curious if the *-pulse suffix would ever be dropped for some other scheme.
The piece you miss: PA depends on alsa, it builds on alsa, it can't replace it. At hardware-near levels there's still alsa at work. If you use alsa via PA, then you go alsa-PA-alsa.
ok, i was thinking that PA was eventually going to have new kernel bits included as well. i know (IIRC) that ALSA is a kernel API, and also a userspace API... distinctly separate. programs are normally linked against the userspace API vs. using the kernel directly, correct? and PA has no intentions of ever reaching the kernel in any way shape or form?
Refer to your own comments below. How does the kernel even come into a discussion on Pulse anyway?
yes there is much to learn :-) i thought pulse ultimately was trying to replace the ALSA kernel API as well, but sounds like i may have been wrong.
Btw., last time I checked it was not recommended to program using the PA API, so unless this changed, developers are still supposed to write their programs for alsa or whatever else.
ok, i suppose i will need to do some more research on all of these components and how they interoperate, thanks Philipp.
Yep. Simple version, ALSA manages the hardware itself (a tough job, and causes most breakages currently, hardware support on Linux, same old story), pulseaudio plugs in on top of that to manage ALL apps, so it sits between apps and ALSA. In the same way JACK does.
but there is still a difference between the alsa kernel API and the user space API... they just happen to share the same name, but they are very different [wikipedia]: "Unlike the kernel API which tries to reflect the capabilities of the hardware directly, ALSA's user space library presents an abstraction which is as similar as possible across disparate hardware." i thought pulse was using the kernel API directly, but again may be wrong. in this respect, PA is a peer to alsa-lib, not alsa... everything (jack/oss4 included?) uses alsa at kernel level.
my only concern is that 99% of the negative feedback is based on ubuntu this or that, usually from years past... ubuntu pretty much jumped the gun; i really like the growing trend of services with DBUS unification, and i think this is a Good Thing for management/security/flexibility.
Yeah, what does Ubuntu have to do with Arch anyway?
heh, indeed :-) that's what i thought.
PA appears to be quite stable at this point, and it's great that apps work with or without. somewhat unrelated, but these same questions will rise again, and more fiercely, once systemd is stable and mainstreamed (which is slated for fedora, and IIRC being considered by debian/ubuntu)... the landscape is changing for the better.
I've been following systemd as well, looks good (though BSD-style init is what we're all used to here). Will perhaps try it out soon. PA is stable, and IMO has been for more than a year.
yeah that's another can of worms, but it's one of about 3-5 technologies i'm really excited to reach fruition. nice that PA is w3rks for you too though, i'm definitely going to give it a shot very soon. thanks Ng, Jan, Philipp and everyone else for your time. C Anthony
On Saturday 27 November 2010 06:30:36 Ng Oon-Ee wrote:
Good to see the overwhelming positive lean; is pulse being considered for an eventual default by chance?
Almost nothing is default on Arch...
So you should ask Gnome. And the answer is that yes, it will be default on Gnome. If you do not use Gnome, then only if the apps you pull need it.
Given that it's been said that if pulse is installed on your system and a program calls its client lib, then this starts the pulse server, which in turn takes over your whole sound system and forces everything else to use it (I'm paraphrasing, but that's what I understood), I for one would not like pulse to be a required dependency of anything. I'm not trying to troll, but that sounds like malware to me. Pete.
On Sat, 2010-11-27 at 11:55 +0000, Peter Lewis wrote:
On Saturday 27 November 2010 06:30:36 Ng Oon-Ee wrote:
Good to see the overwhelming positive lean; is pulse being considered for an eventual default by chance?
Almost nothing is default on Arch...
So you should ask Gnome. And the answer is that yes, it will be default on Gnome. If you do not use Gnome, then only if the apps you pull need it.
Given that it's been said that if pulse is installed on your system and a program calls its client lib, then this starts the pulse server, which in turn takes over your whole sound system and forces everything else to use it (I'm paraphrasing, but that's what I understood), I for one would not like pulse to be a required dependency of anything. I'm not trying to troll, but that sounds like malware to me.
Pete.
In the various branches of this thread there's quite a few misunderstandings of pulse. Not unexpected, but please remember that hearsay isn't the same as actually trying to use something (and perhaps understand it). You cannot (without quite a bit of effort) use pulseaudio and native alsa. That is, don't use some apps using pulse and some not (I do, but that's hackish, and its Jack not alsa). Similarly if you use nvidia you cannot use neovoeu at the same time. Pulse handles audio, nvidia handles your card. And the whole point of how pulseaudio is built in [testing] (libpulse package) is that apps can be built with it (and drag libpulse in) but will not need to use it, unless configured to do it. So no takeover for those who AREN'T using it, which is part of what Jan asked for feedback for (as Allan has replied already).
On Sat, 2010-11-27 at 21:26 +0800, Ng Oon-Ee wrote:
On Sat, 2010-11-27 at 11:55 +0000, Peter Lewis wrote:
On Saturday 27 November 2010 06:30:36 Ng Oon-Ee wrote:
Good to see the overwhelming positive lean; is pulse being considered for an eventual default by chance?
Almost nothing is default on Arch...
So you should ask Gnome. And the answer is that yes, it will be default on Gnome. If you do not use Gnome, then only if the apps you pull need it.
Given that it's been said that if pulse is installed on your system and a program calls its client lib, then this starts the pulse server, which in turn takes over your whole sound system and forces everything else to use it (I'm paraphrasing, but that's what I understood), I for one would not like pulse to be a required dependency of anything. I'm not trying to troll, but that sounds like malware to me.
Pete.
In the various branches of this thread there's quite a few misunderstandings of pulse. Not unexpected, but please remember that hearsay isn't the same as actually trying to use something (and perhaps understand it).
You cannot (without quite a bit of effort) use pulseaudio and native alsa. That is, don't use some apps using pulse and some not (I do, but that's hackish, and its Jack not alsa). Similarly if you use nvidia you cannot use neovoeu at the same time. Pulse handles audio, nvidia handles your card.
And the whole point of how pulseaudio is built in [testing] (libpulse package) is that apps can be built with it (and drag libpulse in) but will not need to use it, unless configured to do it. So no takeover for those who AREN'T using it, which is part of what Jan asked for feedback for (as Allan has replied already).
Thank you. Keep Pulse Audio optional. Please.
On Sat, 2010-11-27 at 11:55 +0000, Peter Lewis wrote:
On Saturday 27 November 2010 06:30:36 Ng Oon-Ee wrote:
Good to see the overwhelming positive lean; is pulse being considered for an eventual default by chance?
Almost nothing is default on Arch...
So you should ask Gnome. And the answer is that yes, it will be default on Gnome. If you do not use Gnome, then only if the apps you pull need it.
Given that it's been said that if pulse is installed on your system and a program calls its client lib, then this starts the pulse server, which in turn takes over your whole sound system and forces everything else to use it (I'm paraphrasing, but that's what I understood), I for one would not like pulse to be a required dependency of anything. I'm not trying to troll, but that sounds like malware to me.
Pete.
I second this one. Every time I've used Pulse on Ubuntu or Arch it's been extremely unpleasant. Pulse has a nasty habit of breaking sound, and its upstream developer also has an extremely nasty habit of blaming these problems on ALSA or drivers or distributors or users or pretty much anything but Pulse Audio. I personally see no point in using Pulse Audio as ALSA works very well without its help, and OSSv4 works the best as an ALSA replacement that carries almost all the Pulse advantages Pulse grabs about (Except for networked sound, to which I see absolutely no point in having.) I would prefer not to see a package require PA to be installed. Failing that, at least not requiring it to be configured or used at all. AFAIK no actual software itself actually requires Pulse Audio to produce sound yet, not even GNOME, though I hear that will change with GNOME 3. Pretty much anything that makes sound will use ALSA anyway, and has no need for PA. I stated it before, but I'll say it here, I don't think Pulse Audio is right for [extra]. Compiz is a lot more stable and still manages to stay in [community]. Pulse goes down a lot and takes sound with it and it's getting put in [extra]? I'm not sure how this makes sense. And I strongly oppose any "default" usage of Pulse Audio the way Ubuntu or Fedora forces it on their users. It just doesn't work that well. Also, forgive me if I am wrong, but isn't that against the Arch way of doing things of just putting in a minimalist installation? I'd hate to see Pulse Audio get installed by default for anything, but as a part of the default Arch install I think is just an all around bad idea.
On Sat, 2010-11-27 at 12:09 -0600, Yaro Kasear wrote: <snip FUD>
I stated it before, but I'll say it here, I don't think Pulse Audio is right for [extra]. Compiz is a lot more stable and still manages to stay in [community]. Pulse goes down a lot and takes sound with it and it's getting put in [extra]? I'm not sure how this makes sense.
And I strongly oppose any "default" usage of Pulse Audio the way Ubuntu or Fedora forces it on their users. It just doesn't work that well. Also, forgive me if I am wrong, but isn't that against the Arch way of doing things of just putting in a minimalist installation? I'd hate to see Pulse Audio get installed by default for anything, but as a part of the default Arch install I think is just an all around bad idea.
I'd suggest reading before posting. 'default' means nothing on Arch (already mentioned), and Pulseaudio is not going to be 'default on your Arch installation' (also already mentioned). Just don't use Gnome. Upstream is going to make Pulseaudio default. KDE as well, maybe.
On Sun, 2010-11-28 at 08:18 +0800, Ng Oon-Ee wrote:
On Sat, 2010-11-27 at 12:09 -0600, Yaro Kasear wrote: <snip FUD>
I stated it before, but I'll say it here, I don't think Pulse Audio is right for [extra]. Compiz is a lot more stable and still manages to stay in [community]. Pulse goes down a lot and takes sound with it and it's getting put in [extra]? I'm not sure how this makes sense.
And I strongly oppose any "default" usage of Pulse Audio the way Ubuntu or Fedora forces it on their users. It just doesn't work that well. Also, forgive me if I am wrong, but isn't that against the Arch way of doing things of just putting in a minimalist installation? I'd hate to see Pulse Audio get installed by default for anything, but as a part of the default Arch install I think is just an all around bad idea.
I'd suggest reading before posting. 'default' means nothing on Arch (already mentioned), and Pulseaudio is not going to be 'default on your Arch installation' (also already mentioned).
Just don't use Gnome. Upstream is going to make Pulseaudio default. KDE as well, maybe.
I don't see KDE upstream doing that. They have Phonon. What's more, most KDE apps today count on Phonon being there. KDE upstream won't do that without expecting to break KDE.
On Sat, 2010-11-27 at 18:21 -0600, Yaro Kasear wrote:
On Sun, 2010-11-28 at 08:18 +0800, Ng Oon-Ee wrote:
Just don't use Gnome. Upstream is going to make Pulseaudio default. KDE as well, maybe.
I don't see KDE upstream doing that. They have Phonon. What's more, most KDE apps today count on Phonon being there. KDE upstream won't do that without expecting to break KDE.
Admittedly my view on this is skewed, since I follow PA's development pretty closely, but one of the devs on PA (Colin Guthrie) has mentioned getting various patches he's done for Mandriva's KDE implementation such that KDE's mixer and such supports pulseaudio natively. Phonon would output directly to pulse in that case, I believe.
On Sun, 2010-11-28 at 11:17 +0800, Ng Oon-Ee wrote:
On Sat, 2010-11-27 at 18:21 -0600, Yaro Kasear wrote:
On Sun, 2010-11-28 at 08:18 +0800, Ng Oon-Ee wrote:
Just don't use Gnome. Upstream is going to make Pulseaudio default. KDE as well, maybe.
I don't see KDE upstream doing that. They have Phonon. What's more, most KDE apps today count on Phonon being there. KDE upstream won't do that without expecting to break KDE.
Admittedly my view on this is skewed, since I follow PA's development pretty closely, but one of the devs on PA (Colin Guthrie) has mentioned getting various patches he's done for Mandriva's KDE implementation such that KDE's mixer and such supports pulseaudio natively. Phonon would output directly to pulse in that case, I believe.
The point of which would be what exactly? All due respect, Phonon is already a sound daemon. To output sound through a sound daemon into ANOTHER sound daemon, particularly one as poor as Pulse Audio, is begging for latency and who knows how many other problems. And, again, it's redundant and unnecessary since Phonon's already a good sound daemon on its own merits.
On 28 November 2010 11:24, Yaro Kasear <yaro@marupa.net> wrote:
On Sun, 2010-11-28 at 11:17 +0800, Ng Oon-Ee wrote:
On Sat, 2010-11-27 at 18:21 -0600, Yaro Kasear wrote:
On Sun, 2010-11-28 at 08:18 +0800, Ng Oon-Ee wrote:
Just don't use Gnome. Upstream is going to make Pulseaudio default. KDE as well, maybe.
I don't see KDE upstream doing that. They have Phonon. What's more, most KDE apps today count on Phonon being there. KDE upstream won't do that without expecting to break KDE.
Admittedly my view on this is skewed, since I follow PA's development pretty closely, but one of the devs on PA (Colin Guthrie) has mentioned getting various patches he's done for Mandriva's KDE implementation such that KDE's mixer and such supports pulseaudio natively. Phonon would output directly to pulse in that case, I believe.
The point of which would be what exactly? All due respect, Phonon is already a sound daemon. To output sound through a sound daemon into ANOTHER sound daemon, particularly one as poor as Pulse Audio, is begging for latency and who knows how many other problems.
And, again, it's redundant and unnecessary since Phonon's already a good sound daemon on its own merits.
In fact, it handles all my audio pretty well, and even lets JACK take over when needed without my intervention. There's no PulseAudio or a kill command in that equation. Anyway, Jan, everything works great, no troubles (with libpulse and without pulseaudio) on KDE. Good job.
On Sun, 2010-11-28 at 17:49 +0800, Ray Rashif wrote:
On 28 November 2010 11:24, Yaro Kasear <yaro@marupa.net> wrote:
On Sun, 2010-11-28 at 11:17 +0800, Ng Oon-Ee wrote:
On Sat, 2010-11-27 at 18:21 -0600, Yaro Kasear wrote:
I don't see KDE upstream doing that. They have Phonon. What's more, most KDE apps today count on Phonon being there. KDE upstream won't do that without expecting to break KDE.
Admittedly my view on this is skewed, since I follow PA's development pretty closely, but one of the devs on PA (Colin Guthrie) has mentioned getting various patches he's done for Mandriva's KDE implementation such that KDE's mixer and such supports pulseaudio natively. Phonon would output directly to pulse in that case, I believe.
The point of which would be what exactly? All due respect, Phonon is already a sound daemon. To output sound through a sound daemon into ANOTHER sound daemon, particularly one as poor as Pulse Audio, is begging for latency and who knows how many other problems.
And, again, it's redundant and unnecessary since Phonon's already a good sound daemon on its own merits.
In fact, it handles all my audio pretty well, and even lets JACK take over when needed without my intervention. There's no PulseAudio or a kill command in that equation.
I'll take both your words on it. Its worth noting that Pulseaudio automatically corks when JACK wants a sound-device (jack2 that is, not jack1). Running phonon atop pulseaudio wouldn't make sense if every app uses phonon. Due to other considerations (for example that all the major distros are pushing pulse), this may not be the case in the future.
Anyway, Jan, everything works great, no troubles (with libpulse and without pulseaudio) on KDE. Good job.
Yes, the lack of complaints (about actual problems) is really surprising.
On Mon, 2010-11-29 at 00:19 +0800, Ng Oon-Ee wrote:
On Sun, 2010-11-28 at 17:49 +0800, Ray Rashif wrote:
On 28 November 2010 11:24, Yaro Kasear <yaro@marupa.net> wrote:
On Sun, 2010-11-28 at 11:17 +0800, Ng Oon-Ee wrote:
On Sat, 2010-11-27 at 18:21 -0600, Yaro Kasear wrote:
I don't see KDE upstream doing that. They have Phonon. What's more, most KDE apps today count on Phonon being there. KDE upstream won't do that without expecting to break KDE.
Admittedly my view on this is skewed, since I follow PA's development pretty closely, but one of the devs on PA (Colin Guthrie) has mentioned getting various patches he's done for Mandriva's KDE implementation such that KDE's mixer and such supports pulseaudio natively. Phonon would output directly to pulse in that case, I believe.
The point of which would be what exactly? All due respect, Phonon is already a sound daemon. To output sound through a sound daemon into ANOTHER sound daemon, particularly one as poor as Pulse Audio, is begging for latency and who knows how many other problems.
And, again, it's redundant and unnecessary since Phonon's already a good sound daemon on its own merits.
In fact, it handles all my audio pretty well, and even lets JACK take over when needed without my intervention. There's no PulseAudio or a kill command in that equation.
I'll take both your words on it. Its worth noting that Pulseaudio automatically corks when JACK wants a sound-device (jack2 that is, not jack1). Running phonon atop pulseaudio wouldn't make sense if every app uses phonon. Due to other considerations (for example that all the major distros are pushing pulse), this may not be the case in the future.
Anyway, Jan, everything works great, no troubles (with libpulse and without pulseaudio) on KDE. Good job.
Yes, the lack of complaints (about actual problems) is really surprising.
It's probably because the masses of people who already know Pulse Audio will break their sound aren't bothering to try it. I have a whole IRC channel filled with people who, if they were to actually test this, would FLOOD this entire discussion with problems that would make the Arch devs reconsider this decision.
It's probably because the masses of people who already know Pulse Audio will break their sound aren't bothering to try it. I have a whole IRC channel filled with people who, if they were to actually test this, would FLOOD this entire discussion with problems that would make the Arch devs reconsider this decision.
dude! no-one cares what you think so quit spamming the mailing list with your nonsense already you clearly don't know what you're talking about so please spreading FUD you're just exposing your ignorance.
On Sun, 2010-11-28 at 16:24 +0000, Nathan Wayde wrote:
It's probably because the masses of people who already know Pulse Audio will break their sound aren't bothering to try it. I have a whole IRC channel filled with people who, if they were to actually test this, would FLOOD this entire discussion with problems that would make the Arch devs reconsider this decision.
dude! no-one cares what you think so quit spamming the mailing list with your nonsense already you clearly don't know what you're talking about so please spreading FUD you're just exposing your ignorance.
FUD would be if it wasn't true. Seriously, Google "pulseaudio problems" sometime. You'll see tons of reasons why this shouldn't be done. There's always dozens of threads at any given time on just about every Linux distribution's forums PURELY about fixing the SAME EXACT problems in Pulse that have been there from the beginning. Do you *really* want me to put up a detailed list of all of Pulse Audio's breakages that have never been fixed? Because I can do it, you know.
On 28-11-2010 16:21, Yaro Kasear wrote:
... if they were to actually test this, would FLOOD this entire discussion with problems that would make the Arch devs reconsider this decision.
From your other posts it seems you have some kind of pet hate for pulse and present arguments that don't really apply currently, I'm sure there are some people here that also have a pet hate for the way that the kde folks seem to have to reinvent the wheel but don't spam the list with it. Please present _objective_ advantages and disadvantages of using
So you are making the assumption that using pulse still causes the same problems it used to cause before (on other distros at that). To top that you are assuming that it is pulse that is (or was) broken and not the alsa drivers that do the actual talking to the hardware. Just because something seems to work or claims to support something it doesn't mean it works well for all the cases, this was most probably the case with alsa drivers and it has improved a lot lately. When I bought the notebook I'm using now I've used ossv4 for some time because I couldn't stand the crappy sound that alsa (and only alsa, apps would output directly to alsa) would put out at the time, I have given alsa and pulse and alsa a try again and it's what I've been using for maybe a year now with _zero_ problems, even with apps that don't know what pulse is. pulse+alsa when compared with ossv4 or alsa + something else instead of just saying that pulse sucks. -- Mauro Santos
Excerpts from Ng Oon-Ee's message of 2010-11-28 17:19:11 +0100:
I'll take both your words on it. Its worth noting that Pulseaudio automatically corks when JACK wants a sound-device (jack2 that is, not jack1). Running phonon atop pulseaudio wouldn't make sense if every app uses phonon. Due to other considerations (for example that all the major distros are pushing pulse), this may not be the case in the future.
Just to make sure no-one gets wrong ideas: jack2, despite its name, isn't going to replace jack. It's another implementation, not a replacement. Both have their share of benefits and drawbacks, and Jack (1) is the most used implementation.
Pulseaudio did expose a lot of bugs in alsa that needed to be fixed in alsa. IIRC they are attempting to move from scheduling sound with the soundcard's hardware interrupts to an entirely cpu based method. I can't remember exactly what the technique is, but it allows for better latency control, better mixing of applications which make different buffer size/latency demands, and consumed less power overall because of increased flexibility over have the processor sleep. Pulseaudio has been buggy because in many cases they have been the very first people to ever make use of some of the more esoteric parts of alsa. Those parts also lacked proper documentation and many drivers didn't even bother with a proper implementation.
On Sun, Nov 28, 2010 at 06:44:10PM -0500, Simon Gomizelj wrote:
Pulseaudio has been buggy because in many cases they have been the very first people to ever make use of some of the more esoteric parts of alsa. Those parts also lacked proper documentation and many drivers didn't even bother with a proper implementation.
True. And what PA probably needs most and ALSA does not provide is a way to provide *lots* of buffering (more than a second, in cases where latency does not matter), while at the same time allowing an app to 'review' or 'rewind' this buffering in order to ensure responsiveness to user commands (such as stop/play for a player). Ciao, -- FA There are three of them, and Alleline.
On Mon, 2010-11-29 at 01:15 +0100, fons@kokkinizita.net wrote:
On Sun, Nov 28, 2010 at 06:44:10PM -0500, Simon Gomizelj wrote:
Pulseaudio has been buggy because in many cases they have been the very first people to ever make use of some of the more esoteric parts of alsa. Those parts also lacked proper documentation and many drivers didn't even bother with a proper implementation.
True. And what PA probably needs most and ALSA does not provide is a way to provide *lots* of buffering (more than a second, in cases where latency does not matter), while at the same time allowing an app to 'review' or 'rewind' this buffering in order to ensure responsiveness to user commands (such as stop/play for a player).
Ciao,
I'm sorry, but did no one notice that I haven't said anything more and have, in fact, dropped this discussion? Who are you arguing with?
On Nov 28, 2010, at 6:30 PM, Yaro Kasear <yaro@marupa.net> wrote:
On Mon, 2010-11-29 at 01:15 +0100, fons@kokkinizita.net wrote:
On Sun, Nov 28, 2010 at 06:44:10PM -0500, Simon Gomizelj wrote:
Pulseaudio has been buggy because in many cases they have been the very first people to ever make use of some of the more esoteric parts of alsa. Those parts also lacked proper documentation and many drivers didn't even bother with a proper implementation.
True. And what PA probably needs most and ALSA does not provide is a way to provide *lots* of buffering (more than a second, in cases where latency does not matter), while at the same time allowing an app to 'review' or 'rewind' this buffering in order to ensure responsiveness to user commands (such as stop/play for a player).
Ciao,
I'm sorry, but did no one notice that I haven't said anything more and have, in fact, dropped this discussion? Who are you arguing with?
Unfortunately it usually takes 10-100x informed responses to negate each FUD riddled one. I would just continue to stand by and absorb the yummy brownies of information. C Anthony [mobile]
On Sun, Nov 28, 2010 at 06:29:56PM -0600, Yaro Kasear wrote:
On Mon, 2010-11-29 at 01:15 +0100, fons@kokkinizita.net wrote:
On Sun, Nov 28, 2010 at 06:44:10PM -0500, Simon Gomizelj wrote:
Pulseaudio has been buggy because in many cases they have been the very first people to ever make use of some of the more esoteric parts of alsa. Those parts also lacked proper documentation and many drivers didn't even bother with a proper implementation.
True. And what PA probably needs most and ALSA does not provide is a way to provide *lots* of buffering (more than a second, in cases where latency does not matter), while at the same time allowing an app to 'review' or 'rewind' this buffering in order to ensure responsiveness to user commands (such as stop/play for a player).
Ciao,
I'm sorry, but did no one notice that I haven't said anything more and have, in fact, dropped this discussion? Who are you arguing with?
I did not respond to you but to Simon Gomizelj's message, and I am not arguing at all. Ciao, -- FA There are three of them, and Alleline.
My experience is that pulseaudio sometimes works for simple desktop audio. Any serious work with audio it just cause (or potentially cause) problems... (again, just my experience)
On Sat, 2010-11-27 at 19:34 -0200, Bernardo Barros wrote:
My experience is that pulseaudio sometimes works for simple desktop audio. Any serious work with audio it just cause (or potentially cause) problems... (again, just my experience)
if (serious audio work); then pulseaudio -k; jackd <insert options here> fi This is OT though. Has the new pulseaudio/libpulse in [testing] affected your system?
2010/11/28 Ng Oon-Ee <ngoonee@gmail.com>:
On Sat, 2010-11-27 at 19:34 -0200, Bernardo Barros wrote:
My experience is that pulseaudio sometimes works for simple desktop audio. Any serious work with audio it just cause (or potentially cause) problems... (again, just my experience)
if (serious audio work); then pulseaudio -k; jackd <insert options here> fi
This is OT though. Has the new pulseaudio/libpulse in [testing] affected your system?
pasuspender jackd This will suspend PulseAudio (corking all streams and releasing all devices) while jackd runs.
On Fri, 2010-11-26 at 21:34 +0100, Jan Steffens wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
Smallish comment, vlc has been rebuilt for pulse support (presumably), but it is not listed in the depends or optdepends (pacman -Qi vlc | grep pulse only shows conflicts and replaces)
On 27-11-2010 01:18, Ng Oon-Ee wrote:
On Fri, 2010-11-26 at 21:34 +0100, Jan Steffens wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
Smallish comment, vlc has been rebuilt for pulse support (presumably), but it is not listed in the depends or optdepends (pacman -Qi vlc | grep pulse only shows conflicts and replaces)
Have you installed vlc-pulse-plugin ? As far as I know that's what will make vlc support pulse. However vlc-pulse-plugin is not listed as an optdepend and maybe it should be. -- Mauro Santos
On Sat, 2010-11-27 at 11:33 +0000, Mauro Santos wrote:
On 27-11-2010 01:18, Ng Oon-Ee wrote:
On Fri, 2010-11-26 at 21:34 +0100, Jan Steffens wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
Smallish comment, vlc has been rebuilt for pulse support (presumably), but it is not listed in the depends or optdepends (pacman -Qi vlc | grep pulse only shows conflicts and replaces)
Have you installed vlc-pulse-plugin ? As far as I know that's what will make vlc support pulse. However vlc-pulse-plugin is not listed as an optdepend and maybe it should be.
Jan replaced vlc-pulse-plugin with just vlc. The vlc package itself supports pulse natively now, no need for that (since we're talking about [testing])
On 27-11-2010 13:19, Ng Oon-Ee wrote:
On Sat, 2010-11-27 at 11:33 +0000, Mauro Santos wrote:
On 27-11-2010 01:18, Ng Oon-Ee wrote:
On Fri, 2010-11-26 at 21:34 +0100, Jan Steffens wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
Smallish comment, vlc has been rebuilt for pulse support (presumably), but it is not listed in the depends or optdepends (pacman -Qi vlc | grep pulse only shows conflicts and replaces)
Have you installed vlc-pulse-plugin ? As far as I know that's what will make vlc support pulse. However vlc-pulse-plugin is not listed as an optdepend and maybe it should be.
Jan replaced vlc-pulse-plugin with just vlc. The vlc package itself supports pulse natively now, no need for that (since we're talking about [testing])
Fair enough :) Maybe not having an optdepend on pulse makes sense as it is not exactly the same thing as a plugin or library that will add functionality just to vlc, I guess it can be compared to jack and oss support. -- Mauro Santos
On 27/11/10 06:34, Jan Steffens wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
I'll just add feedback that I do not use pulse and the packages that have been built with optional pulse backends that I use still work as they did before. So the update seems good for us non-pulse users too. Great work! Allan
On Fri, 2010-11-26 at 21:34 +0100, Jan Steffens wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
Tested yesterday: I was running a pulse-free installation on my laptop. The changes you made in testing don't affect pulse-free systems running GNOME. I tried switching to pulseaudio by installing the pulseaudio-gnome group. That causes a conflict between the gstreamer0.10-pulse package in community and the gstreamer package containing the plugin now, but besides that, no problems have been found and everything works as expected.
On 26.11.2010 21:34, Jan Steffens wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
Works great for me on gnome with pulseaudio setup. Only software left I use that needs to be recompiled is mplayer. But that should obviously be discussed here: https://bugs.archlinux.org/task/21832 a little offtopic: There is lots of hatred of pulseaduio. Many peoble are claim that it doesn't work at all. I have seen some setups of various distributions with pulse in the recent year and there has been only been one real problem: passthrough.... and thats it. Except for that anything just worked with pulse enabled apps and with minor issues on alsa-apps. Cheers, Ulf
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
Great work Jan, it seems your updates have eliminated all the *-pulse packages I had from AUR (except the kde mixer for now). It would be a good time to post a news article about these changes. It should explain the reasons for the change, the fact that without the "pulseaudio" package the server is not installed and can't be started EVER, and also how this obsoletes packages from AUR (on my count: mplayer-pulse, xine-lib-pulse, phonon-pulse, libao-pulse, gstreamer*-pulse, what else?). Thanks again for your effort -- damjan
On Mon, 2010-11-29 at 13:21 +0100, Damjan Georgievski wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
Great work Jan, it seems your updates have eliminated all the *-pulse packages I had from AUR (except the kde mixer for now).
On my system I still have mpd-pulse, gnome-media-pulse, gnome-settings-daemon-pulse, and sdl-pulse. The middle two at least will disappear with gnome updates I'm sure. I wonder whether the other two should just be left as is (without pulse support in the [extra] packages). Not a big issue, compiling from the AUR isn't a pain =)
It would be a good time to post a news article about these changes. It should explain the reasons for the change, the fact that without the "pulseaudio" package the server is not installed and can't be started EVER, and also how this obsoletes packages from AUR (on my count: mplayer-pulse, xine-lib-pulse, phonon-pulse, libao-pulse, gstreamer*-pulse, what else?).
Thanks again for your effort
Ditto
On Mon, Nov 29, 2010 at 6:21 AM, Damjan Georgievski <gdamjan@gmail.com> wrote:
I've put PulseAudio into [testing] some time ago, but received no feedback on this.
This either means it works well, or nobody uses it.
So I'm asking for it now, especially from GNOME and KDE users running PulseAudio.
Great work Jan, it seems your updates have eliminated all the *-pulse packages I had from AUR (except the kde mixer for now).
It would be a good time to post a news article about these changes. It should explain the reasons for the change, the fact that without the "pulseaudio" package the server is not installed and can't be started EVER, and also how this obsoletes packages from AUR (on my count: mplayer-pulse, xine-lib-pulse, phonon-pulse, libao-pulse, gstreamer*-pulse, what else?).
Correct me if I'm wrong, but if pulseaudio is installed, I believe you should be able to prevent it from starting by removing the dbus activation files: etc/xdg/ etc/xdg/autostart/ etc/xdg/autostart/pulseaudio-kde.desktop etc/xdg/autostart/pulseaudio.desktop (unless pulse has some other way of auto-starting the daemon) Cheers, Sander
On Mon, Nov 29, 2010 at 5:49 PM, Sander Jansen <s.jansen@gmail.com> wrote:
Correct me if I'm wrong, but if pulseaudio is installed, I believe you should be able to prevent it from starting by removing the dbus activation files:
etc/xdg/ etc/xdg/autostart/ etc/xdg/autostart/pulseaudio-kde.desktop etc/xdg/autostart/pulseaudio.desktop
(unless pulse has some other way of auto-starting the daemon)
You will also need to uncomment and deactivate the autospawn option in /etc/pulse/client.conf.
On Mon, Nov 29, 2010 at 11:03 AM, Jan Steffens <jan.steffens@gmail.com> wrote:
On Mon, Nov 29, 2010 at 5:49 PM, Sander Jansen <s.jansen@gmail.com> wrote:
Correct me if I'm wrong, but if pulseaudio is installed, I believe you should be able to prevent it from starting by removing the dbus activation files:
etc/xdg/ etc/xdg/autostart/ etc/xdg/autostart/pulseaudio-kde.desktop etc/xdg/autostart/pulseaudio.desktop
(unless pulse has some other way of auto-starting the daemon)
You will also need to uncomment and deactivate the autospawn option in /etc/pulse/client.conf.
since i recently blew up my computer "accidentally on purpose"[1]... i decided to try this since i said i would and so many others to had success. works perfectly under a fresh install, e17 desktop; nice w3rk! i'm liking it quite a bit... sharing/sending sound to other machines is a pretty neat trick; maybe i can set it up under my local headless KVM server and send music/etc to my or my fiancé's laptops... or both... cool. C Anthony [1] me==smart. http://www.spinics.net/lists/linux-btrfs/msg07193.html
On Wed, 2010-12-01 at 21:09 -0600, C Anthony Risinger wrote:
On Mon, Nov 29, 2010 at 11:03 AM, Jan Steffens <jan.steffens@gmail.com> wrote:
On Mon, Nov 29, 2010 at 5:49 PM, Sander Jansen <s.jansen@gmail.com> wrote:
Correct me if I'm wrong, but if pulseaudio is installed, I believe you should be able to prevent it from starting by removing the dbus activation files:
etc/xdg/ etc/xdg/autostart/ etc/xdg/autostart/pulseaudio-kde.desktop etc/xdg/autostart/pulseaudio.desktop
(unless pulse has some other way of auto-starting the daemon)
You will also need to uncomment and deactivate the autospawn option in /etc/pulse/client.conf.
since i recently blew up my computer "accidentally on purpose"[1]... i decided to try this since i said i would and so many others to had success. [1] me==smart. http://www.spinics.net/lists/linux-btrfs/msg07193.html
Ouch. Hope you didn't lose anything too important.
works perfectly under a fresh install, e17 desktop; nice w3rk! i'm liking it quite a bit... sharing/sending sound to other machines is a pretty neat trick; maybe i can set it up under my local headless KVM server and send music/etc to my or my fiancé's laptops... or both... cool.
Yeah, linux users are like goldfish, we don't need anything until we actually try it out and realize is pretty cool =). I'm using PA-specific features almost as much as I use audio on this machine.
From my limited experience with pulseaudio on a machine without X, it seems that anything that has native pulse support in it will automatically start pulse on demand anyways.
2010/12/1 Ng Oon-Ee <ngoonee@gmail.com>
On Wed, 2010-12-01 at 21:09 -0600, C Anthony Risinger wrote:
On Mon, Nov 29, 2010 at 11:03 AM, Jan Steffens <jan.steffens@gmail.com> wrote:
On Mon, Nov 29, 2010 at 5:49 PM, Sander Jansen <s.jansen@gmail.com> wrote:
Correct me if I'm wrong, but if pulseaudio is installed, I believe you should be able to prevent it from starting by removing the dbus activation files:
etc/xdg/ etc/xdg/autostart/ etc/xdg/autostart/pulseaudio-kde.desktop etc/xdg/autostart/pulseaudio.desktop
(unless pulse has some other way of auto-starting the daemon)
You will also need to uncomment and deactivate the autospawn option in /etc/pulse/client.conf.
since i recently blew up my computer "accidentally on purpose"[1]... i decided to try this since i said i would and so many others to had success. [1] me==smart. http://www.spinics.net/lists/linux-btrfs/msg07193.html
Ouch. Hope you didn't lose anything too important.
works perfectly under a fresh install, e17 desktop; nice w3rk! i'm liking it quite a bit... sharing/sending sound to other machines is a pretty neat trick; maybe i can set it up under my local headless KVM server and send music/etc to my or my fiancé's laptops... or both... cool.
Yeah, linux users are like goldfish, we don't need anything until we actually try it out and realize is pretty cool =). I'm using PA-specific features almost as much as I use audio on this machine.
On 02.12.2010 16:23, Simon Gomizelj wrote:
From my limited experience with pulseaudio on a machine without X, it seems that anything that has native pulse support in it will automatically start pulse on demand anyways.
on ArchLinux if you don't install the pulseaudio package, there wont be anything to start, since the daemon is part of that package. And nothing requires that package either. -- дамјан
Of course. My observation was meant to go with the comment above on preventing pulseaudio from starting if it is installed by deleting the dbus activation files. Just pointing out that an application may, potentially, still start it.
On 12/01/2010 08:09 PM, C Anthony Risinger wrote:
since i recently blew up my computer "accidentally on purpose"[1]... i decided to try this since i said i would and so many others to had success.
works perfectly under a fresh install, e17 desktop; nice w3rk! i'm liking it quite a bit... sharing/sending sound to other machines is a pretty neat trick; maybe i can set it up under my local headless KVM server and send music/etc to my or my fiancé's laptops... or both... cool.
C Anthony
[1] me==smart. http://www.spinics.net/lists/linux-btrfs/msg07193.html
Have you seen the PulseAudio volume control applet (for Gnome)? My favorite two parts are being able to control sound for each application separately (Pidgin doesn't need to be as loud as Banshee), and being able to switch output while things are playing (makes using a headset much nicer). I actually stopped using PulseAudio to try OSS, and I'm thinking of going back just for those two things. Brendan Long
Le mercredi 8 à 0:55, Brendan Long a écrit :
Have you seen the PulseAudio volume control applet (for Gnome)? My favorite two parts are being able to control sound for each application separately (Pidgin doesn't need to be as loud as Banshee), and being able to switch output while things are playing (makes using a headset much nicer). I actually stopped using PulseAudio to try OSS, and I'm thinking of going back just for those two things.
In OSS, ossxmix gives a per-application mixer, and also allows you to switch on/off outputs. NB: just launching ossxmix will both start the mixer and create a small applet in GNOME's panel; use ossxmix -S to not place an icon in the panel. -- Fred
participants (27)
-
Allan McRae
-
Anarconda
-
Bernardo Barros
-
Brendan Long
-
C Anthony Risinger
-
Damjan
-
Damjan Georgievski
-
fons＠kokkinizita.net
-
Frédéric Perrin
-
ianux
-
Ignacio Galmarino
-
Ionuț Bîru
-
Jan de Groot
-
Jan Steffens
-
Mauro Santos
-
Nathan Wayde
-
Ng Oon-Ee
-
Peter Lewis
-
Philipp Überbacher
-
Pierre Schmitz
-
Ray Rashif
-
Sander Jansen
-
Seblu
-
Simon Gomizelj
-
Ulf Winkelvos
-
Yaro Kasear
-
Δημακάκος Δημάκης