There is a lot of FUD and general mistrust of PA. It seems to me that it would help a great deal if someone would write a short statement about what PA is and how it should work. If there is known readable references, they would help too, as would noting any known work-arounds for problem.
It would be a great help to those of us who try to give user support. I'd even put it on my own web space and direct folk to it, if that would help.
Anne
Anne Wilson wrote:
There is a lot of FUD and general mistrust of PA. It seems to me that it would help a great deal if someone would write a short statement about what PA is and how it should work. If there is known readable references, they would help too, as would noting any known work-arounds for problem.
It would be a great help to those of us who try to give user support. I'd even put it on my own web space and direct folk to it, if that would help.
There's a lot of good information on the PulseAudio project pages themselves:
http://www.pulseaudio.org/wiki/AboutPulseAudio http://www.pulseaudio.org/wiki/FirstSteps http://www.pulseaudio.org/wiki/PerfectSetup http://www.pulseaudio.org/wiki/FAQ
Maybe someone would be interested in summarising some of this and adding Fedora-specifics on the Fedora wiki to make it a bit less intimidating for novice users?
Regards, Bryn.
On Thu, Nov 27, 2008 at 3:06 PM, Bryn M. Reeves bmr@redhat.com wrote:
Anne Wilson wrote:
There is a lot of FUD and general mistrust of PA. It seems to me that it would help a great deal if someone would write a short statement about what PA is and how it should work. If there is known readable references, they would help too, as would noting any known work-arounds for problem.
It would be a great help to those of us who try to give user support. I'd even put it on my own web space and direct folk to it, if that would help.
There's a lot of good information on the PulseAudio project pages themselves:
http://www.pulseaudio.org/wiki/AboutPulseAudio http://www.pulseaudio.org/wiki/FirstSteps http://www.pulseaudio.org/wiki/PerfectSetup http://www.pulseaudio.org/wiki/FAQ
Maybe someone would be interested in summarising some of this and adding Fedora-specifics on the Fedora wiki to make it a bit less intimidating for novice users?
Regards, Bryn.
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
I think documentation would be great, but what really intimidates novices is the fact that PA, in a lot of scenarios, simply doesn't work (at all or as expected) and many don't stay and fiddle with the settings or whatnot, they just switch to another distro. So the first step is to make an audio system that works ok, then document it.
Bryn M. Reeves wrote:
Anne Wilson wrote:
There is a lot of FUD and general mistrust of PA.
Yes. But I think it is honest "FUD".
It is my experience that PulseAudio generally just works and in most setups makes it much easier to configure sound. But, obviously, with higher level of abstraction it gets harder to debug problems in the hidden layers.
Unfortunately it seems like the experience with the new PulseAudio on some systems really _is_ more glitches and higher cpu load.
The rewritten PulseAudio sound server utilizes new features from the low-lovel audio drivers, and currently it reveales that there is problems with some kernel / alsa drivers. PulseAudio might have trigged the problems, but now it is just the messenger about problems that must be fixed elsewhere.
It seems to me that it would help a great deal if someone would write a short statement about what PA is and how it should work. If there is known readable references, they would help too, as would noting any known work-arounds for problem.
It would be a great help to those of us who try to give user support. I'd even put it on my own web space and direct folk to it, if that would help.
There's a lot of good information on the PulseAudio project pages themselves:
http://www.pulseaudio.org/wiki/AboutPulseAudio http://www.pulseaudio.org/wiki/FirstSteps http://www.pulseaudio.org/wiki/PerfectSetup http://www.pulseaudio.org/wiki/FAQ
Maybe someone would be interested in summarising some of this and adding Fedora-specifics on the Fedora wiki to make it a bit less intimidating for novice users?
I think shomething should be said on http://fedoraproject.org/wiki/Bugs/F10Common - but I don't know what ;-)
On the systems where it works it just works and there isn't much to say about it and no big need for more documentation. And obviously it _should_ work on all systems.
If it doesn't work then it is a bug which should be filed and fixed. Unfortunately there seems to be a backlog with that. (See for example the list on https://admin.fedoraproject.org/pkgdb/packages/bugs/pulseaudio and https://bugzilla.redhat.com/show_bug.cgi?id=462026)
/Mads
On 11/27/2008 02:53 PM, Mads Kiilerich wrote:
The rewritten PulseAudio sound server utilizes new features from the low-lovel audio drivers, and currently it reveales that there is problems with some kernel / alsa drivers. PulseAudio might have trigged the problems, but now it is just the messenger about problems that must be fixed elsewhere.
I think the problem here is that most Distros/Users still use regular ALSA output which now seems to use a different codepath than what PulseAudio uses. As a result the bugs are hard to file against ALSA and get lower priority because the driver technically works for most users. If the ALSA developers could unify this codepath so that the "traditional" way of accessing the driver is basically a layer using the new functionality that codepath would probably receive more attention.
Regards, Dennis
Dennis J. wrote:
On 11/27/2008 02:53 PM, Mads Kiilerich wrote:
The rewritten PulseAudio sound server utilizes new features from the low-lovel audio drivers, and currently it reveales that there is problems with some kernel / alsa drivers. PulseAudio might have trigged the problems, but now it is just the messenger about problems that must be fixed elsewhere.
I think the problem here is that most Distros/Users still use regular ALSA output which now seems to use a different codepath than what PulseAudio uses. As a result the bugs are hard to file against ALSA and get lower priority because the driver technically works for most users. If the ALSA developers could unify this codepath so that the "traditional" way of accessing the driver is basically a layer using the new functionality that codepath would probably receive more attention.
Regards, Dennis
And my suggestion is that pulseaudio should be integrated into ALSA. That is, it becomes invisible to most users, who think they are just using alsa. Alsa would have calls that allow the underlying apis that haven't been abstracted into pulse to be called through pulse or to disable pulse if desired. Or maybe alsa just becomes part of pulse, depending on your advocacy. :-)
In other words it would be a drop in replacement for dmix, the current component of alsa that does part of what pulse does.
The goals mismatch between alsa and pulse disappears under that scenario as well, as they are all just working on sound, not pulse or alsa.
On Thu, 27 Nov 2008 10:37:26 -0700 stan eiqep_eiwo_y@cox.net wrote:
And my suggestion is that pulseaudio should be integrated into ALSA. That is, it becomes invisible to most users
The trouble is, it is really easy to understand why people could grow to hate ALSA. It is way too low level. For instance to get a DVD played with the digital sound directly routed out of the SP/DIF interface on my motherboard, I have to say this:
amixer set IEC958 unmute amixer set 'IEC958 Playback AC97-SPSA' 0 amixer set 'IEC958 Playback Source' PCM exec mplayer dvd://1 -alang en -ao alsa:device=hw=0.0 -ac hwdts,hwac3, \ -monitoraspect 16:9 -fs
That is one heck of a lot of cryptic gibberish when what I ought to be able to do is click a button somewhere that says "Hey! Send the already encoded digital audio to the digital audio interface". (Like I can do in Windows, for instance :-).
The problem is, pulseaudio doesn't seem to be solving problems like this. I can at least spend six weeks searching the web to finally come up with the gibberish I need to make ALSA work for this, but as yet, there appears to be no way to make pulseaudio talk to anything except one primary pair of stereo speakers, and if you have more audio options than that, forget it.
Combine that with the fact that pulseaudio appears to be desperate to solve some kind of problem I not only don't have, but can't understand, and "yum erase pulseaudio" is far and away my best option.
Tom Horsley wrote:
On Thu, 27 Nov 2008 10:37:26 -0700 stan eiqep_eiwo_y@cox.net wrote:
And my suggestion is that pulseaudio should be integrated into ALSA. That is, it becomes invisible to most users
The trouble is, it is really easy to understand why people could grow to hate ALSA. It is way too low level. For instance to get a DVD played with the digital sound directly routed out of the SP/DIF interface on my motherboard, I have to say this:
I think we're saying the same thing. Alsa should stay low level, providing the full functionality that every sound device provides.
pulseaudio should be the interface in alsa that allows you to either have access to that low level capability if you want it, or high level capability like you describe above at the touch of a button. So pulse is a plugin framework into alsa, where if there is no plugin you get alsa, otherwise the high level functionality.
And all of this occurs transparently to the average user that doesn't care. They don't even know there is something called pulse or alsa. Applications just use the alsa api or the pulse plugin functionality as a stop on the way to the alsa api as they see fit and know one knows.
Sound just works. Are we there? No. Are we in sight? On a clear sunny day, if we get tossed in the air. :-^
Tom Horsley wrote:
The trouble is, it is really easy to understand why people could grow to hate ALSA. It is way too low level. For instance to get a DVD played with the digital sound directly routed out of the SP/DIF interface on my motherboard, I have to say this:
amixer set IEC958 unmute amixer set 'IEC958 Playback AC97-SPSA' 0 amixer set 'IEC958 Playback Source' PCM exec mplayer dvd://1 -alang en -ao alsa:device=hw=0.0 -ac hwdts,hwac3, \ -monitoraspect 16:9 -fs
That is one heck of a lot of cryptic gibberish when what I ought to be able to do is click a button somewhere that says "Hey! Send the already encoded digital audio to the digital audio interface". (Like I can do in Windows, for instance :-).
The problem is, pulseaudio doesn't seem to be solving problems like this. I can at least spend six weeks searching the web to finally come up with the gibberish I need to make ALSA work for this, but as yet, there appears to be no way to make pulseaudio talk to anything except one primary pair of stereo speakers, and if you have more audio options than that, forget it.
You seem to know what you are talking about, so you are probably right. If you just want to connect one audio source directly and thus exclusively with one audio device and know how to do it then you don't want pulseaudio.
Pulseaudio wants to help you managing your audio - and does that by managing it for you and mixing all your audio sources and redirecting to your audio devices. Take it or leave it. Pulseaudio makes it easy to redirect wherever you want and mix all your audio. But if you don't want mixing then you don't want pulseaudio.
Yes, we probably also need better documentation of how to disable pulseaudio. But the topic of this thread was how to help and support pulseaudio. Disabling pulseaudio is the last resort answer to that question - and in some cases the right answer.
If you guys want better support for systems without pulseaudio or better alternatives to pulseaudio then you have to contribute to that. Criticizing pulseaudio won't make it go away.
Combine that with the fact that pulseaudio appears to be desperate to solve some kind of problem I not only don't have, but can't understand, and "yum erase pulseaudio" is far and away my best option.
FWIW I don't have your problem. But I use and appreciate the features described in the rationale on https://fedoraproject.org/wiki/Releases/FeaturePulseaudio. Let's make sure Fedora keeps working for both usecases!
/Mads
On Thu, Nov 27, 2008 at 3:01 PM, Anne Wilson cannewilson@googlemail.comwrote:
There is a lot of FUD and general mistrust of PA. It seems to me that it would help a great deal if someone would write a short statement about what PA is and how it should work. If there is known readable references, they would help too, as would noting any known work-arounds for problem.
It would be a great help to those of us who try to give user support. I'd even put it on my own web space and direct folk to it, if that would help.
Anne
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Who spreads FUD about PA and why?
On Thursday 27 November 2008 13:07:15 Aioanei Rares wrote:
On Thu, Nov 27, 2008 at 3:01 PM, Anne Wilson
cannewilson@googlemail.comwrote:
There is a lot of FUD and general mistrust of PA. It seems to me that it would help a great deal if someone would write a short statement about what PA is and how it should work. If there is known readable references, they would help too, as would noting any known work-arounds for problem.
It would be a great help to those of us who try to give user support. I'd even put it on my own web space and direct folk to it, if that would help.
Anne
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Who spreads FUD about PA and why?
That's easy to answer - people who've had a bad experience with it - whether by fault of design or pebcak. What I'm really hoping for is the ability to present a short, easily understand article that helps everyone diagnose whether it is in fact a bug, or something the user has configured that can be changed etc...
I get quite angry at the number of times I see replies like 'disable pulseaudio and you'll have no more problems' - but I have not counter- arguments.
Anne
On Thu, Nov 27, 2008 at 5:12 PM, Anne Wilson cannewilson@googlemail.com wrote:
I get quite angry at the number of times I see replies like 'disable pulseaudio and you'll have no more problems' - but I have not counter- arguments.
I suggest you base at least some of the material on Lennart Poettering blog http://0pointer.de/blog
and in particular the "PulseAudio FUD" post here: http://0pointer.de/blog/projects/jeffrey-stedfast.html
Thank you for guiding this effort
G.
On Fri, Nov 28, 2008 at 08:47:57AM +0100, Gianluca Sforna wrote:
On Thu, Nov 27, 2008 at 5:12 PM, Anne Wilson cannewilson@googlemail.com wrote:
I get quite angry at the number of times I see replies like 'disable pulseaudio and you'll have no more problems' - but I have not counter- arguments.
I suggest you base at least some of the material on Lennart Poettering blog http://0pointer.de/blog
and in particular the "PulseAudio FUD" post here: http://0pointer.de/blog/projects/jeffrey-stedfast.html
That's not a counter argument, it seems to agree. Its developer says that it's not ready for prime time, though he phrases it differently.
Interesting that he feels Fedora, where sound doesn't Just Work unless you use Gnome, did a good job of implementing it, whereas Ubuntu, where sound works without any effort in console, fluxbox, and the like, did a bad job.
I'm not a big fan of alsa either, actually. The BSDs do quite well without it.
On Fri, Nov 28, 2008 at 6:37 AM, Scott Robbins scottro@nyc.rr.com wrote:
On Fri, Nov 28, 2008 at 08:47:57AM +0100, Gianluca Sforna wrote:
On Thu, Nov 27, 2008 at 5:12 PM, Anne Wilson cannewilson@googlemail.com
wrote:
I get quite angry at the number of times I see replies like 'disable pulseaudio and you'll have no more problems' - but I have not counter- arguments.
I suggest you base at least some of the material on Lennart Poettering
blog
and in particular the "PulseAudio FUD" post here: http://0pointer.de/blog/projects/jeffrey-stedfast.html
That's not a counter argument, it seems to agree. Its developer says that it's not ready for prime time, though he phrases it differently.
Interesting that he feels Fedora, where sound doesn't Just Work unless you use Gnome, did a good job of implementing it, whereas Ubuntu, where sound works without any effort in console, fluxbox, and the like, did a bad job.
OK, I've read his FUD rebuttal, I can understand why sound doesn't just work, but I've got one of those laptops where it doesn't work. Personally, I won't go near Gnome (it just doesn't work the way _I_ think, and neither of us is wrong).
I'd like to switch from F8 to F10, but there are a number of pretty simple items on my checklist, and one is sound: a) The KDE launch and shutdown sounds should not stutter. (I usually have them turned off anyway, but it is indicative of a 'problem') b) I need 'audacity' c) I'd like to have xine and mplayer (sometimes one doesn't like my DVDs and the other does) d) playing MP3s (from conference proceedings) (I like xmms) Rarely do I play albums, so all these players that focus on sucking music across the net and showing album covers and building playlists are lost on me; just play the file I've got is enough. e) the 'CD control' button on the front of my Dell Inspiron 6400 should work (at least as well as they did on F8, otherwise its a regression).
So while testing Rawhide and now F10 release, step a) (still) doesn't work. So... If a) doesn't work, then I typically stop there and wait till it does, even if some of the _other_ stuff might work.
Either a) I'm doing something wrong (because it doesn't work 'out of the box' on my machine or b) What do I file Bugzilla's against?
Thanks for listening, Fulko
Fulko Hew wrote:
On Fri, Nov 28, 2008 at 6:37 AM, Scott Robbins <scottro@nyc.rr.com mailto:scottro@nyc.rr.com> wrote:
On Fri, Nov 28, 2008 at 08:47:57AM +0100, Gianluca Sforna wrote: > On Thu, Nov 27, 2008 at 5:12 PM, Anne Wilson <cannewilson@googlemail.com <mailto:cannewilson@googlemail.com>> wrote: > > > > I get quite angry at the number of times I see replies like 'disable > > pulseaudio and you'll have no more problems' - but I have not counter- > > arguments. > > > > I suggest you base at least some of the material on Lennart Poettering blog > http://0pointer.de/blog > > and in particular the "PulseAudio FUD" post here: > http://0pointer.de/blog/projects/jeffrey-stedfast.html That's not a counter argument, it seems to agree. Its developer says that it's not ready for prime time, though he phrases it differently. Interesting that he feels Fedora, where sound doesn't Just Work unless you use Gnome, did a good job of implementing it, whereas Ubuntu, where sound works without any effort in console, fluxbox, and the like, did a bad job.OK, I've read his FUD rebuttal, I can understand why sound doesn't just work, but I've got one of those laptops where it doesn't work. Personally, I won't go near Gnome (it just doesn't work the way _I_ think, and neither of us is wrong).
I'd like to switch from F8 to F10, but there are a number of pretty simple items on my checklist, and one is sound: a) The KDE launch and shutdown sounds should not stutter. (I usually have them turned off anyway, but it is indicative of a 'problem') b) I need 'audacity' c) I'd like to have xine and mplayer (sometimes one doesn't like my DVDs and the other does) d) playing MP3s (from conference proceedings) (I like xmms) Rarely do I play albums, so all these players that focus on sucking music across the net and showing album covers and building playlists are lost on me; just play the file I've got is enough. e) the 'CD control' button on the front of my Dell Inspiron 6400 should work (at least as well as they did on F8, otherwise its a regression).
So while testing Rawhide and now F10 release, step a) (still) doesn't work. So... If a) doesn't work, then I typically stop there and wait till it does, even if some of the _other_ stuff might work.
Either a) I'm doing something wrong (because it doesn't work 'out of the box' on my machine or b) What do I file Bugzilla's against?
Thanks for listening, Fulko
For the record usually the bugs are ALSA related not PA Take a look at https://fedoraproject.org/wiki/QA/Test_Days/2008-10-09
JBG
On Fri November 28 2008 14:05:00 Fulko Hew wrote:
a) The KDE launch and shutdown sounds should not stutter.
I've been seeing this on all my pulseaudio free systems for quite sometime since ~KDE 4.0.x, startup stutters & fails but after that its all good. search the upstream bugzilla for reports.
...dex
--- On Fri, 11/28/08, dexter dex.mbox@googlemail.com wrote:
From: dexter dex.mbox@googlemail.com Subject: Re: PulseAudio info needed To: "For testers of Fedora Core development releases" fedora-test-list@redhat.com Date: Friday, November 28, 2008, 7:13 AM On Fri November 28 2008 14:05:00 Fulko Hew wrote:
a) The KDE launch and shutdown sounds should not
stutter.
I've been seeing this on all my pulseaudio free systems for quite sometime since ~KDE 4.0.x, startup stutters & fails but after that its all good. search the upstream bugzilla for reports.
...dex
--
I have seen the sound stuttering with pulseaudio on, I just left it there and it complains that ..... sound falling back on ..... and then I try playing something and it works. What I notice also except when the sound was not woking on most systems, the sound was muted and we could not hear anything, error probably with udev and thankfully it was fixed :), the alsa output sometimes fails and the system falls back on oss, some snd_hda.?? codecs :( It is not a bulletproof system, but when it works, it works ok, but when it does not work, it gets trashed because people need sound to work, and it definitely gets in the way :(
See this sound stuttering with PA on in both GNOME and KDE. I use both so I won't discriminate against either one :)
Regards,
Antonio
On Fri, Nov 28, 2008 at 10:24 AM, Antonio Olivares olivares14031@yahoo.comwrote:
--- On Fri, 11/28/08, dexter dex.mbox@googlemail.com wrote:
From: dexter dex.mbox@googlemail.com Subject: Re: PulseAudio info needed To: "For testers of Fedora Core development releases" <
fedora-test-list@redhat.com>
Date: Friday, November 28, 2008, 7:13 AM On Fri November 28 2008 14:05:00 Fulko Hew wrote:
a) The KDE launch and shutdown sounds should not
stutter.
I've been seeing this on all my pulseaudio free systems for quite sometime since ~KDE 4.0.x, startup stutters & fails but after that its all good. search the upstream bugzilla for reports.
...dex
--
I have seen the sound stuttering with pulseaudio on, I just left it there and it complains that ..... sound falling back on ..... and then I try playing something and it works. What I notice also except when the sound was not woking on most systems, the sound was muted and we could not hear anything, error probably with udev and thankfully it was fixed :), the alsa output sometimes fails and the system falls back on oss, some snd_hda.?? codecs :( It is not a bulletproof system, but when it works, it works ok, but when it does not work, it gets trashed because people need sound to work, and it definitely gets in the way :(
See this sound stuttering with PA on in both GNOME and KDE. I use both so I won't discriminate against either one :)
Regards,
Antonio
FWIW - Pulseaudio worked great for me in F8 and F9 (except for some minor annoyances such play/pause lag at one point in F8, and Miro -> xine -> PA hangs in both), but in 'glitch-free' F10, on the same hardware (audigy2 card), I could't for the life of me get rid of the constant buffer underruns.
So, a 'yum remove pulseaudio' later, and a few config tweaks in kde, mplayer, and xine, and all's well again.
They say pulseaudio brings out the worst in the emu10k driver; I wonder why it waited until now.
Jason Farrell-2 wrote:
FWIW - Pulseaudio worked great for me in F8 and F9 (except for some minor annoyances such play/pause lag at one point in F8, and Miro -> xine -> PA hangs in both), but in 'glitch-free' F10, on the same hardware (audigy2 card), I could't for the life of me get rid of the constant buffer underruns.
So, a 'yum remove pulseaudio' later, and a few config tweaks in kde, mplayer, and xine, and all's well again.
They say pulseaudio brings out the worst in the emu10k driver; I wonder why it waited until now.
I don't know if this is entirely relevant but I had stuttering audio when playing music in Amarok in a newly installed F10 system. After searching for solutions for ages I eventually found a link which suggested" he PulseAudio sound server has been rewritten to use timer-based audio scheduli ng instead of the traditional interrupt-driven approach. Timer-based scheduling may expose issues in some Alsa drivers. To turn timer-based scheduling off, repl ace the line
load-module module-hal-detect
in /etc/pulse/default.pa by
load-module module-hal-detect tsched=0 "
After doing this and rebooting then sound in pulseaudio was fine on that system.
So sometimes there is documentation, and if we are lucky then it fixes our own problem, but clearly newly developed and released software can and does still have issues. If we report on the BZ appropriately and give suitable diagnostics hopefully the code will get fixed - and yes I saw the ding-dong quoted earlier in this thread.
Sound is not the only issue - there are fixes needed for plymouth, xorg.conf-free X, SElinux etc etc etc....
The cost of making progress......
On Fri, 2008-11-28 at 05:37, Scott Robbins wrote:
That's not a counter argument, it seems to agree. Its developer says that it's not ready for prime time, though he phrases it differently.
Yea, that's what I took away from it.
Bottom line summary:
Pro: Someday PA will be 'insanely great'. Assuming it doesn't get abandoned to a horrible death when the primary devel burns out or realizes there is a reason nobody else has succeeded with an all encompassing 100% solution to audio under Linux. With the PA in F10 and the right hardware you do get glitch free audio so that is one tangible benefit.
Con: Right now, today, it would be hard to identify a real world case where something works with PA and doesn't work without it. The reverse case is all to easy to find. Apparently at various times in the past the problems have been as bad as totally locked desktops. Despite the plans for the future, currently PA doesn't provide any must have features above what exists without it. Unless somebody can identify a real world use case for moving a playing stream from one device to another. Cute? Oh yea. Useful? Not very.
Right now I'd recommend treating PA like SELinux on a desktop. Neither serve a real purpose yet so leave it enabled until something blows up. If you can't fix it in ten minutes with Google ditch it and try again next release.
John Morris wrote: Despite the
plans for the future, currently PA doesn't provide any must have features above what exists without it. Unless somebody can identify a real world use case for moving a playing stream from one device to another. Cute? Oh yea. Useful? Not very.
.. unless you are using bluetooth headphones or streaming sound in a terminal server or ..
It is easy to dismiss features you don't use but as the long discussions about KDE 4 have shown that, even very obscure features in KDE 3 is important to some users.
Right now I'd recommend treating PA like SELinux on a desktop. Neither serve a real purpose yet so leave it enabled until something blows up.
https://fedoraproject.org/wiki/SELinux/FAQ#Is_it_useful_on_a_desktop.3F
Browser plugins are a constant source of security issues. Isolating them via nspluginwrapper and SELinux definitely does serve a real purpose.
Rahul
On Tue, 2008-12-02 at 22:03, Rahul Sundaram wrote:
Unless somebody can identify a real world use case for moving a playing stream from one device to another. Cute? Oh yea. Useful? Not very.
.. unless you are using bluetooth headphones or streaming sound in a terminal server or ..
Moving between a BT headset and external speakers is a useful feature. Haven't had to do it but can't see where that can't be done with ALSA along with the existing hotplug/dbus/udev/blah. Streaming sound over the network has been in ESD (and NAS) for over a decade. Moving a playing stream between them without a glitch is just gravy. If it works it is of course a handy thing to have but if the price is the whole desktop locking up even once a month it's outta there. Stability is far more important.
Browser plugins are a constant source of security issues. Isolating them via nspluginwrapper and SELinux definitely does serve a real purpose.
A real purpose, but for me[1] the potential downside of losing SELinux is worth about the ten minutes I suggested Googling for an answer. Thankfully the SELinux troubleshooter now solves most problems. Life is just too short to spend hours feeding SELinux, Pulseaudio or Networkmanager's seemingly never ending brokenness. When they work, great. And someday they might 'Just Work'. But for now when they break turn em off and get on with life. The system works fine without all of em unless you are on a laptop and need NM to get encrypted access points to work.
[1] Me being someone who doesn't hang out on sites watching flash videos of dancing hamsters and other similar dodgy content likely to be carriers of various nasty bits.
John Morris wrote:
On Tue, 2008-12-02 at 22:03, Rahul Sundaram wrote:
Unless somebody can identify a real world use case for moving a playing stream from one device to another. Cute? Oh yea. Useful? Not very.
.. unless you are using bluetooth headphones or streaming sound in a terminal server or ..
Moving between a BT headset and external speakers is a useful feature. Haven't had to do it but can't see where that can't be done with ALSA along with the existing hotplug/dbus/udev/blah.
If you can get it working seamlessly without PulseAudio, let me know.
Streaming sound over
the network has been in ESD (and NAS) for over a decade.
PulseAudio among other things, is a compatible replacement for ESD which is unmaintained and has other issues. Once you look into all these different use cases, you need a sound server and PulseAudio is what we have to do that. Other sound servers cover some of the niche cases but not everything.
Rahul
Scott Robbins wrote:
That's not a counter argument, it seems to agree. Its developer says that it's not ready for prime time, though he phrases it differently.
Interesting that he feels Fedora, where sound doesn't Just Work unless you use Gnome, did a good job of implementing it
It works just fine in Xfce and for the time I used KDE, it worked there as well. Haven't used other environments long enough but I had no problems in the console either.
Rahul
On Wed, Dec 03, 2008 at 09:25:01AM +0530, Rahul Sundaram wrote:
Scott Robbins wrote:
That's not a counter argument, it seems to agree. Its developer says that it's not ready for prime time, though he phrases it differently.
Interesting that he feels Fedora, where sound doesn't Just Work unless you use Gnome, did a good job of implementing it
It works just fine in Xfce and for the time I used KDE, it worked there as well. Haven't used other environments long enough but I had no problems in the console either.
I didn't play with the xfce spin at all. In KDE, it was stuttery, and in console and fluxbox, it didn't work at all for me.
This is low end hardware, which could certainly be a factor, but sound used to Just Work(TM) in Fedora for me, and now it doesn't.
So, for me at least, I can't say it's a good implementation. Judging from what I'm seeing on the forums since F10, I don't think I'm the only one with issues.
Conversely, it does seem that those who spend the time getting it to work (usually with far more sophisticated sound needs than mine) are liking it. For me, at least in Gnome, it's working better than it did previously. However, it is definitely one of the big issues that we're seeing on the forums.
Did you do anything special to get it working in console, or did it just work for you with no further configuration?
(For what it's worth, in console, I use it with mplayer.)
Scott Robbins wrote:
So, for me at least, I can't say it's a good implementation. Judging from what I'm seeing on the forums since F10, I don't think I'm the only one with issues.
Probably not. Would be useful to direct them to file bug reports. The one thread I saw mixed a lot of things together in ways I couldn't easily follow up.
Forums are great for end users asking questions but if you are there primarily to try and provide answers, then it is tiring.
Did you do anything special to get it working in console, or did it just work for you with no further configuration?
(For what it's worth, in console, I use it with mplayer.)
Yes, mplayer on the console works just fine for me. Did nothing special. I will probably upgrade to current rawhide from Fedora 10 soon anyway for some taste of breakage.
Rahul
On Wed, Dec 03, 2008 at 09:58:58AM +0530, Rahul Sundaram wrote:
Scott Robbins wrote:
So, for me at least, I can't say it's a good implementation. Judging from what I'm seeing on the forums since F10, I don't think I'm the only one with issues.
Probably not. Would be useful to direct them to file bug reports. The one thread I saw mixed a lot of things together in ways I couldn't easily follow up.
Heh, you should be there more often--you'd be even more confused. :)
Forums are great for end users asking questions but if you are there primarily to try and provide answers, then it is tiring.
Yes, this is true, and I think we do our best to make it clear to them that the developers will not see and answer questions there--it's primarily users helping users. Around the time of new releases, we have to emphasize that over and over. My point was simply that it is causing people trouble.
Did you do anything special to get it working in console, or did it just work for you with no further configuration?
(For what it's worth, in console, I use it with mplayer.)
Yes, mplayer on the console works just fine for me. Did nothing special. I will probably upgrade to current rawhide from Fedora 10 soon anyway for some taste of breakage.
Hrrm, interesting. I have a spare partition, I'll do another F10 install over the weekend perhaps and see if my experience matches yours this time. Maybe something I choose in custom package selection did something, I really don't know. I'll try doing a straight default installation.
Scott Robbins wrote:
Hrrm, interesting. I have a spare partition, I'll do another F10 install over the weekend perhaps and see if my experience matches yours this time. Maybe something I choose in custom package selection did something, I really don't know. I'll try doing a straight default installation.
Installation from live USB is pretty straight forward since you don't the choice of fiddling with the package set during installation. Takes about 3 minutes. That's what I do.
Rahul
On Wed, Dec 03, 2008 at 11:01:11AM +0530, Rahul Sundaram wrote:
Scott Robbins wrote:
Hrrm, interesting. I have a spare partition, I'll do another F10 install over the weekend perhaps and see if my experience matches yours this time. Maybe something I choose in custom package selection did something, I really don't know. I'll try doing a straight default installation.
Installation from live USB is pretty straight forward since you don't the choice of fiddling with the package set during installation. Takes about 3 minutes. That's what I do.
I wonder if that has anything to do with it working for you and not me.
I'll probably try both versions and see if there's a difference.
Also, do you boot into runlevel 3 or runlevel 5, which could, I assume, also make a difference?
Thanks.
On Thu, 27 Nov 2008 13:01:09 +0000 Anne Wilson cannewilson@googlemail.com wrote:
as would noting any known work-arounds for problem.
Heck, this works around every problem I have every time:
yum erase pulseaudio
:-).
2008/11/27 Tom Horsley tom.horsley@att.net:
On Thu, 27 Nov 2008 13:01:09 +0000 Anne Wilson cannewilson@googlemail.com wrote:
as would noting any known work-arounds for problem.
Heck, this works around every problem I have every time:
yum erase pulseaudio
:-).
:-) indeed, but I think that's actually the problem that Anne is referring to: generally if anyone has any problems with pulseaudio, the first advice they'll get is almost always to uninstall/disable it. Sure, that may possibly still be necessary with particularly weird hardware or audio programs, but if pulseaudio truly is the way of the future, it would probably be worth having a page somewhere (maybe it exists?) with simple-to-use troubleshooting techniques that could be used before the above blunt hammer.
MEF
On Thursday 27 November 2008 14:16:25 Mary Ellen Foster wrote:
2008/11/27 Tom Horsley tom.horsley@att.net:
On Thu, 27 Nov 2008 13:01:09 +0000
Anne Wilson cannewilson@googlemail.com wrote:
as would noting any known work-arounds for problem.
Heck, this works around every problem I have every time:
yum erase pulseaudio
:-).
: :-) indeed, but I think that's actually the problem that Anne is
referring to: generally if anyone has any problems with pulseaudio, the first advice they'll get is almost always to uninstall/disable it. Sure, that may possibly still be necessary with particularly weird hardware or audio programs, but if pulseaudio truly is the way of the future, it would probably be worth having a page somewhere (maybe it exists?) with simple-to-use troubleshooting techniques that could be used before the above blunt hammer.
Exactly. I'll gladly help all I can. If someone feels capable of writing the necessary but is unsure of the English, I'll help with that. I also know a few kde folk that would help with a translation if it is easier to write in one's native language.
Anne
On 11/27/2008 05:14 PM, Anne Wilson wrote:
On Thursday 27 November 2008 14:16:25 Mary Ellen Foster wrote:
2008/11/27 Tom Horsleytom.horsley@att.net:
On Thu, 27 Nov 2008 13:01:09 +0000
Anne Wilsoncannewilson@googlemail.com wrote:
as would noting any known work-arounds for problem.
Heck, this works around every problem I have every time:
yum erase pulseaudio
:-).
: :-) indeed, but I think that's actually the problem that Anne is
referring to: generally if anyone has any problems with pulseaudio, the first advice they'll get is almost always to uninstall/disable it. Sure, that may possibly still be necessary with particularly weird hardware or audio programs, but if pulseaudio truly is the way of the future, it would probably be worth having a page somewhere (maybe it exists?) with simple-to-use troubleshooting techniques that could be used before the above blunt hammer.
Exactly. I'll gladly help all I can. If someone feels capable of writing the necessary but is unsure of the English, I'll help with that. I also know a few kde folk that would help with a translation if it is easier to write in one's native language.
What needs to happen is for both projects (ALSA and PulseAudio) to properly recognize that there are interaction issues that they need to work on together. Filing bugs against PA results in a "this is not ours but ALSAs problem" but users cannot file proper bugs for ALSA because they have no idea how PA is actually wired into ALSA. So they switch to plain ALSA output and sound starts working again.
On useful piece of documentation would be a PA developer explaining how exactly PulseAudios usage of ALSA differs from the way applications interface with ALSA directly. That way people could actually file bugs against the ALSA drivers and point the developers toward that document.
Take a look at this bug: https://bugzilla.redhat.com/show_bug.cgi?id=462026
This got filed agains alsa-lib, then kicked over to the driver folks who then immediately kicked it back to the alsa-lib folks. The problem seem to occur for at least three different drivers and was attached to the F10Target tracker but clearly didn't make it for the F10 release.
For users there is little more they can do here and none of the development stakeholders really want to "own up" to the problem so it just lingers. Since the involved users clearly want their sound to work they are left with no other choice than turning off PulseAudio.
How is addressing the FUD out there going to fix these real problems?
Regards, Dennis
On Thu, 2008-11-27 at 08:16, Mary Ellen Foster wrote:
Sure, that may possibly still be necessary with particularly weird hardware or audio programs, but if pulseaudio truly is the way of the future, it would probably be worth having a page somewhere (maybe it exists?) with simple-to-use troubleshooting techniques that could be used before the above blunt hammer.
Pulseaudio probably is the future but that doesn't change the current reality that it causes problems for many people and there isn't much upside to have it installed. The only reason for wanting people to use it now is to get bug reports. Considering the complex interactions between it and ALSA what are the odds of getting usable bug reports from new users? So can anyone point out a downside to uninstall being the first recommendation for such users?
This really should be in the Fedora release notes. "PulseAudio is still experimental and does not work for everyone. If you are not a developer and experience sound problems we recommend you first remove the pulseaudio package and log out and back in. No software currently in the Fedora repositories will fail if PulseAudio is removed."
On Thu, Nov 27, 2008 at 09:02:17AM -0500, Tom Horsley wrote:
On Thu, 27 Nov 2008 13:01:09 +0000 Anne Wilson cannewilson@googlemail.com wrote:
as would noting any known work-arounds for problem.
Heck, this works around every problem I have every time:
yum erase pulseaudio
<snicker> Actually, this discussion made me wonder if it's imporved to the point where it doesn't break non-standard, e.g., console or fluxbox sound, so with a bit of trepidation, I reinstalled alsa-pulseaudio-plugins and sound still worked. It got me curious enough to try a new fresh install to see what happens if you don't boot into Gnome.
Which brought up a new issue, NFS installs, but that's for my next post. :) (I don't have the answer yet, since I'm trying to get this done before we leave for the dinner--which reminds me, HAPPY HOLIDAYS to those of you who celebrate. And despite all our grouching, many thanks to all he developers).
On Thursday 27 November 2008 16:12:48 Scott Robbins wrote:
<snicker> Actually, this discussion made me wonder if it's imporved to the point where it doesn't break non-standard, e.g., console or fluxbox sound, so with a bit of trepidation, I reinstalled alsa-pulseaudio-plugins and sound still worked. It got me curious enough to try a new fresh install to see what happens if you don't boot into Gnome.
When it works it's great - and it does work for some of us. I have no problems on a 5-year-old F9 workstation, a 3-year-old laptop and a 1-month-old netbook. Of course satisfied customers don't complain :-)
It's just another thing in linux development that highlights problems that always existed, but no-one was aware of because that function wasn't used in the past. At least, that's my understanding.
Anne
On Thu, Nov 27, 2008 at 04:38:40PM +0000, Anne Wilson wrote:
On Thursday 27 November 2008 16:12:48 Scott Robbins wrote:
When it works it's great - and it does work for some of us. I have no problems on a 5-year-old F9 workstation, a 3-year-old laptop and a 1-month-old netbook. Of course satisfied customers don't complain :-)
It's just another thing in linux development that highlights problems that always existed, but no-one was aware of because that function wasn't used in the past. At least, that's my understanding.
Hrrm, my understanding was that sound worked for me, regardless of whether I use console, fluxbox, gnome or any other desktop or window manager. With the advent of pulse audio, combined with Gnome tying sound into console kit, it doesn't. I just gave it a fresh try on a fresh install. A line from the song I chose, "Good Times" was quite apropos, "Same old, Same old."
Works without a hitch--as long as I decide to use Gnome. Install fluxbox, boot into runlevel 3, doesn't play until I kill pulse audio.
It's the sort of thing that I don't feel like putting effort into solving since I have a quick solution that works for me--make sure pulseaudio doesn't run on boot, remove the alsa pulse audio plugin and edit a file in /etc/security.
I never had to do any of that till last November when they tied sound to consolekit. At that point, I had to edit that file. Then came pulseaudio which added to the breakage.
There's a reason many of us don't like it. :)
To add insult to injury, Ubuntu has figured out a way to make it work transparently whether or not you use Gnome, console, or anything.
So, if there were three or four steps that would take me two minutes to do, that are easily in sight, I'd do it--as it stands though, the steps I take require perhaps two minutes, and I've seen, from comparing it with Ubuntu, where I use it, that there's no major difference for my, admittedly, very simple sound needs, occasionally playing something on youtube or music.
-
"Jóhann B. Guðmundsson" -
Anne Wilson -
Antonio Olivares -
Bryn M. Reeves -
Dennis Jacobfeuerborn -
dexter -
Fulko Hew -
Gianluca Sforna -
Jason Farrell -
John Morris -
Mads Kiilerich -
Mary Ellen Foster -
mike cloaked -
Rahul Sundaram -
Rares Aioanei -
Scott Robbins -
stan -
Tom Horsley