Hi all,
What the good way to get rid of pulseaudio on Fedora 10 please?
Many thanks in advance. Have a nice day. Chris
Kevin Kofler wrote:
Delaunay Christophe wrote:
What the good way to get rid of pulseaudio on Fedora 10 please?
Why do you want to do that in the first place? Chances are removing PulseAudio is not the correct solution for your problem.
I thought most people wanted to get rid of pulseaudio. Its a very troublesome program with poor documentation, and little output to help you resolve problems. If you get it working it seems to offer you nothing you didn't have before you had pulseaudio.
Steve
On Wednesday 27 May 2009, Steve Underwood wrote:
Kevin Kofler wrote:
Delaunay Christophe wrote:
What the good way to get rid of pulseaudio on Fedora 10 please?
Why do you want to do that in the first place? Chances are removing PulseAudio is not the correct solution for your problem.
I thought most people wanted to get rid of pulseaudio. Its a very troublesome program with poor documentation, and little output to help you resolve problems. If you get it working it seems to offer you nothing you didn't have before you had pulseaudio.
Steve
+10
Steve Underwood wrote:
Kevin Kofler wrote:
Delaunay Christophe wrote:
What the good way to get rid of pulseaudio on Fedora 10 please?
Why do you want to do that in the first place? Chances are removing PulseAudio is not the correct solution for your problem.
I thought most people wanted to get rid of pulseaudio. Its a very troublesome program with poor documentation, and little output to help you resolve problems. If you get it working it seems to offer you nothing you didn't have before you had pulseaudio.
Steve
Is it still being run at X level as of F10/F11? That was my only real gripe with it.. Other than that it's gotten stable enough and integrated enough for me to not care about it. Most popular programs already have direct pulse output plugins, but those that don't use its alsa or oss wrappers just fine.
Steve Underwood wrote:
I thought most people wanted to get rid of pulseaudio.
Only because people like you perpetuate some stupid myth that PulseAudio is evil.
Its a very troublesome program with poor documentation, and little output to help you resolve problems. If you get it working it seems to offer you nothing you didn't have before you had pulseaudio.
It makes sound just work, without apps fighting for the sound device (or multiple incompatible sound servers all trying to "fix" this fighting for the sound device). No more annoyances like games failing to play sound because some GUI event sound was still being played when they tried opening the sound device. (I've seen, or rather heard, that happen way too often in pre-PulseAudio times.)
Most sound cards don't do mixing in hardware. A few do support it, but the ALSA driver doesn't. Only few sound cards can do it and have ALSA support for it. So PulseAudio is a mixing solution which works for everyone.
Kevin Kofler
Kevin Kofler wrote:
Steve Underwood wrote:
I thought most people wanted to get rid of pulseaudio.
Only because people like you perpetuate some stupid myth that PulseAudio is evil.
Its a very troublesome program with poor documentation, and little output to help you resolve problems. If you get it working it seems to offer you nothing you didn't have before you had pulseaudio.
It makes sound just work, without apps fighting for the sound device (or multiple incompatible sound servers all trying to "fix" this fighting for the sound device). No more annoyances like games failing to play sound because some GUI event sound was still being played when they tried opening the sound device. (I've seen, or rather heard, that happen way too often in pre-PulseAudio times.)
Most sound cards don't do mixing in hardware. A few do support it, but the ALSA driver doesn't. Only few sound cards can do it and have ALSA support for it. So PulseAudio is a mixing solution which works for everyone.
Kevin Kofler
Strange, I've never had a sound card that didn't have a hardware mixer. And the on-board Intel hd audio that I'm using now does too. I don't think PulseAudio is evil, it just doesn't bring anything to the party.
Regards,
John
On Thu, May 28, 2009 at 12:08:37AM -0700, john wendel wrote:
Kevin Kofler wrote:
Steve Underwood wrote:
I thought most people wanted to get rid of pulseaudio.
Only because people like you perpetuate some stupid myth that PulseAudio is evil.
Its a very troublesome program with poor documentation, and little output to help you resolve problems. If you get it working it seems to offer you nothing you didn't have before you had pulseaudio.
It makes sound just work, without apps fighting for the sound device (or multiple incompatible sound servers all trying to "fix" this fighting for the sound device). No more annoyances like games failing to play sound because some GUI event sound was still being played when they tried opening the sound device. (I've seen, or rather heard, that happen way too often in pre-PulseAudio times.)
Most sound cards don't do mixing in hardware. A few do support it, but the ALSA driver doesn't. Only few sound cards can do it and have ALSA support for it. So PulseAudio is a mixing solution which works for everyone.
Kevin KoflerStrange, I've never had a sound card that didn't have a hardware mixer. And the on-board Intel hd audio that I'm using now does too. I don't think PulseAudio is evil, it just doesn't bring anything to the party.
You're mixing up things :-)
"Mixer" usually means the device/application you use to control volume level settings.
In this context "hardware mixing" meant mixing up multiple audio streams (from different applications) and all of them playing at once.
Your on-board Intel hd audio cannot mix audio streams in hardware.. I think. Some Creative cards can do that.
-- Pasi
2009/5/28 Pasi Kärkkäinen pasik@iki.fi:
On Thu, May 28, 2009 at 12:08:37AM -0700, john wendel wrote:
Kevin Kofler wrote:
It makes sound just work, without apps fighting for the sound device (or multiple incompatible sound servers all trying to "fix" this fighting for the sound device). No more annoyances like games failing to play sound because some GUI event sound was still being played when they tried opening the sound device. (I've seen, or rather heard, that happen way too often in pre-PulseAudio times.)
Most sound cards don't do mixing in hardware. A few do support it, but the ALSA driver doesn't. Only few sound cards can do it and have ALSA support for it. So PulseAudio is a mixing solution which works for everyone.
Kevin Kofler
Strange, I've never had a sound card that didn't have a hardware mixer. And the on-board Intel hd audio that I'm using now does too. I don't think PulseAudio is evil, it just doesn't bring anything to the party.
You're mixing up things :-)
"Mixer" usually means the device/application you use to control volume level settings.
In this context "hardware mixing" meant mixing up multiple audio streams (from different applications) and all of them playing at once.
Your on-board Intel hd audio cannot mix audio streams in hardware.. I think. Some Creative cards can do that.
Most of the modern Intel HDA cards _are_ capable of mixing streams. I have owned one such card since 2007. Also most of the hi-end boards today support multiple streams. However I am not sure whether pulseaudio can stream two different streams to these sound cards and let it playback in two different devices. A very common situation would be something like a skype call on a headphone without interrupting music playback on external speakers.
On Thu, 2009-05-28 at 01:29 -0700, suvayu ali wrote:
Most of the modern Intel HDA cards _are_ capable of mixing streams. I have owned one such card since 2007. Also most of the hi-end boards today support multiple streams. However I am not sure whether pulseaudio can stream two different streams to these sound cards and let it playback in two different devices. A very common situation would be something like a skype call on a headphone without interrupting music playback on external speakers.
You could only do that if you have two *separate* *output* hardware circuits. Lots of cards only have one output system. They might give you separate volume controls for speakers or headphones, but both control the same thing (one output source), they just switch between which control to use depending on whether you've plugged a headphone, in or not. Which makes more sense than at first seems.
e.g. My laptop has silly little speakers that always need full volume, my headphones work normally. It's handy to set the level for each appropriately, and not have to move the volume up and down between them, just because I've plugged a lead in.
2009/5/30 Tim ignored_mailbox@yahoo.com.au:
On Thu, 2009-05-28 at 01:29 -0700, suvayu ali wrote:
Most of the modern Intel HDA cards _are_ capable of mixing streams. I have owned one such card since 2007. Also most of the hi-end boards today support multiple streams. However I am not sure whether pulseaudio can stream two different streams to these sound cards and let it playback in two different devices. A very common situation would be something like a skype call on a headphone without interrupting music playback on external speakers.
You could only do that if you have two *separate* *output* hardware circuits. Lots of cards only have one output system. They might give you separate volume controls for speakers or headphones, but both control the same thing (one output source), they just switch between which control to use depending on whether you've plugged a headphone, in or not. Which makes more sense than at first seems.
e.g. My laptop has silly little speakers that always need full volume, my headphones work normally. It's handy to set the level for each appropriately, and not have to move the volume up and down between them, just because I've plugged a lead in.
I first used this on an Intel 975XBX2 workstation board I bought in 2007. It _is_ capable of multi-streaming, I could set up my drivers to present to the apps as two different output devices. So I had skype configured to use the front jacks and I used the rear jacks to stream to the line-in of my home entertainment system.
So much so, I even had skype ring through the rear jacks so that I could hear even if I didn't have my headphones on but the call itself would use the headphones connected to the front jacks. And I never paused my music palyback during skype calls, I always turned it down rather than stop. (I'm kind of a music addict :) ) My current board is a Gigabyte board with a Realtek audio chipset with similar multi-streaming capabilities. However for some other (unrelated) unsolvable reasons, I have not done this setup yet.
Both of these are integrated audio chips. To get this working all you need are proper drivers. Hardware is _not_ the bottleneck here.
On Sat, May 30, 2009 at 6:36 AM, suvayu ali <fatkasuvayu+linux@gmail.comfatkasuvayu%2Blinux@gmail.com
wrote:
2009/5/30 Tim ignored_mailbox@yahoo.com.au:
On Thu, 2009-05-28 at 01:29 -0700, suvayu ali wrote:
Most of the modern Intel HDA cards _are_ capable of mixing streams. I have owned one such card since 2007. Also most of the hi-end boards today support multiple streams. However I am not sure whether pulseaudio can stream two different streams to these sound cards and let it playback in two different devices. A very common situation would be something like a skype call on a headphone without interrupting music playback on external speakers.
You could only do that if you have two *separate* *output* hardware circuits. Lots of cards only have one output system. They might give you separate volume controls for speakers or headphones, but both control the same thing (one output source), they just switch between which control to use depending on whether you've plugged a headphone, in or not. Which makes more sense than at first seems.
e.g. My laptop has silly little speakers that always need full volume, my headphones work normally. It's handy to set the level for each appropriately, and not have to move the volume up and down between them, just because I've plugged a lead in.
I first used this on an Intel 975XBX2 workstation board I bought in 2007. It _is_ capable of multi-streaming, I could set up my drivers to present to the apps as two different output devices. So I had skype configured to use the front jacks and I used the rear jacks to stream to the line-in of my home entertainment system.
How did you do that? I am using the same card right now and I did not know it was able of doing that. I know it has three different circuits for input, but you are saying it can do the same for output...
Paulo Cavalcanti wrote:
On Sat, May 30, 2009 at 6:36 AM, suvayu ali <fatkasuvayu+linux@gmail.comfatkasuvayu%2Blinux@gmail.com
wrote:
2009/5/30 Tim ignored_mailbox@yahoo.com.au:
On Thu, 2009-05-28 at 01:29 -0700, suvayu ali wrote:
Most of the modern Intel HDA cards _are_ capable of mixing streams. I have owned one such card since 2007. Also most of the hi-end boards today support multiple streams. However I am not sure whether pulseaudio can stream two different streams to these sound cards and let it playback in two different devices. A very common situation would be something like a skype call on a headphone without interrupting music playback on external speakers.
You could only do that if you have two *separate* *output* hardware circuits. Lots of cards only have one output system. They might give you separate volume controls for speakers or headphones, but both control the same thing (one output source), they just switch between which control to use depending on whether you've plugged a headphone, in or not. Which makes more sense than at first seems.
e.g. My laptop has silly little speakers that always need full volume, my headphones work normally. It's handy to set the level for each appropriately, and not have to move the volume up and down between them, just because I've plugged a lead in.
I first used this on an Intel 975XBX2 workstation board I bought in 2007. It _is_ capable of multi-streaming, I could set up my drivers to present to the apps as two different output devices. So I had skype configured to use the front jacks and I used the rear jacks to stream to the line-in of my home entertainment system.
How did you do that? I am using the same card right now and I did not know it was able of doing that. I know it has three different circuits for input, but you are saying it can do the same for output...
At that time I was just starting out with linux. I was running XP 32 bit , 64 bit and F8 on the same machine. I was able to configure it like that for XP 32 bit after exchange of a weeks worth of emails with Intel customer support. It was a matter of installing the _right_ drivers for the card. As far as I recall I didn't have that working on F8 though.
Back then skype used the old OSS implementation, when skype was running it would hold the audio device and not even media players could use the device let alone multi-streaming. Since my use of multi-streaming was kinda skype centric and being a newbie who was unaware of the concept of mailing lists or user forums didn't have a lot to go with.
Trying to repeat that on my current system would be great though. :)
On Thursday 28 May 2009, Pasi Kärkkäinen wrote:
On Thu, May 28, 2009 at 12:08:37AM -0700, john wendel wrote:
Kevin Kofler wrote:
Steve Underwood wrote:
I thought most people wanted to get rid of pulseaudio.
Only because people like you perpetuate some stupid myth that PulseAudio is evil.
Its a very troublesome program with poor documentation, and little output to help you resolve problems. If you get it working it seems to offer you nothing you didn't have before you had pulseaudio.
It makes sound just work, without apps fighting for the sound device (or multiple incompatible sound servers all trying to "fix" this fighting for the sound device). No more annoyances like games failing to play sound because some GUI event sound was still being played when they tried opening the sound device. (I've seen, or rather heard, that happen way too often in pre-PulseAudio times.)
Most sound cards don't do mixing in hardware. A few do support it, but the ALSA driver doesn't. Only few sound cards can do it and have ALSA support for it. So PulseAudio is a mixing solution which works for everyone.
Kevin KoflerStrange, I've never had a sound card that didn't have a hardware mixer. And the on-board Intel hd audio that I'm using now does too. I don't think PulseAudio is evil, it just doesn't bring anything to the party.
You're mixing up things :-)
"Mixer" usually means the device/application you use to control volume level settings.
In this context "hardware mixing" meant mixing up multiple audio streams (from different applications) and all of them playing at once.
Your on-board Intel hd audio cannot mix audio streams in hardware.. I think. Some Creative cards can do that.
-- Pasi
Yes, mine does. Clicking on a link here in kmail ALWAYS runs firefox with two tabs, both linked somehow so that if I scroll one of then and quit that tab, the remaining tab has also been scrolled to the same place. But they are not in synch when the links video plays, so in order to stop the confusion of all the doubletalk, I have to kill one tab, usually the top(2nd) tab. I think that is evidence that my card DOES do hardware mixing.
On Thu, 2009-05-28 at 13:28 -0400, Gene Heskett wrote:
Yes, mine does. Clicking on a link here in kmail ALWAYS runs firefox with two tabs, both linked somehow so that if I scroll one of then and quit that tab, the remaining tab has also been scrolled to the same place. But they are not in synch when the links video plays, so in order to stop the confusion of all the doubletalk, I have to kill one tab, usually the top(2nd) tab. I think that is evidence that my card DOES do hardware mixing.
Actually, I think dmix (alsa's software mixing solution) is enabled by default in alsa now (though I could be wrong).
Jonathan
On Fri, May 29, 2009 at 10:01:24AM +0300, Jonathan Dieter wrote:
On Thu, 2009-05-28 at 13:28 -0400, Gene Heskett wrote:
Yes, mine does. Clicking on a link here in kmail ALWAYS runs firefox with two tabs, both linked somehow so that if I scroll one of then and quit that tab, the remaining tab has also been scrolled to the same place. But they are not in synch when the links video plays, so in order to stop the confusion of all the doubletalk, I have to kill one tab, usually the top(2nd) tab. I think that is evidence that my card DOES do hardware mixing.
Actually, I think dmix (alsa's software mixing solution) is enabled by default in alsa now (though I could be wrong).
Yes, dmix has been the default for a while now.
I'm still not sure about integrated sound cards supporting hardware mixing.. Feel free to prove me wrong.. :)
-- Pasi
On 5/28/09, Kevin Kofler kevin.kofler@chello.at wrote:
Steve Underwood wrote:
I thought most people wanted to get rid of pulseaudio.
Only because people like you perpetuate some stupid myth that PulseAudio is evil.
This is not true (and is an insult, I'd think).
[...]
So PulseAudio is a mixing solution which works for everyone.
You must be joking.
Andras
Andras Simon wrote:
On 5/28/09, Kevin Kofler kevin.kofler@chello.at wrote:
Steve Underwood wrote:
I thought most people wanted to get rid of pulseaudio.
Only because people like you perpetuate some stupid myth that
PulseAudio is
evil.
This is not true (and is an insult, I'd think).
[...]
So PulseAudio is a mixing solution which works for everyone.
You must be joking.
You will probably find that the people who want to get rid of pulseaudio are the vocal minority. For the rest of us, we don't complain because it works perfectly fine for us.
I quite like pulseaudio actually...
-- Sam
On 5/28/09, Sharpe, Sam J sam.sharpe+lists.redhat@gmail.com wrote:
Andras Simon wrote:
On 5/28/09, Kevin Kofler kevin.kofler@chello.at wrote:
Steve Underwood wrote:
I thought most people wanted to get rid of pulseaudio.
Only because people like you perpetuate some stupid myth that
PulseAudio is
evil.
This is not true (and is an insult, I'd think).
[...]
So PulseAudio is a mixing solution which works for everyone.
You must be joking.
You will probably find that the people who want to get rid of pulseaudio are the vocal minority. For the rest of us, we don't complain because it works perfectly fine for us.
You may or may not be right; unless you have numbers, it's really a question of faith. But that was not the question here. "PA works for the majority" is a very different (and possibly true) statement from "PA works for everyone", which is obviously false, and "Most people wanted to get rid of pulseaudio only because people like you perpetuate some stupid myth that PulseAudio is evil" which is worse.
I quite like pulseaudio actually...
Good for you!
Andras
2009/5/28 Andras Simon szajmi@gmail.com:
On 5/28/09, Sharpe, Sam J sam.sharpe+lists.redhat@gmail.com wrote:
Andras Simon wrote:
On 5/28/09, Kevin Kofler kevin.kofler@chello.at wrote:
Steve Underwood wrote:
I thought most people wanted to get rid of pulseaudio.
Only because people like you perpetuate some stupid myth that
PulseAudio is
evil.
This is not true (and is an insult, I'd think).
[...]
So PulseAudio is a mixing solution which works for everyone.
You must be joking.
You will probably find that the people who want to get rid of pulseaudio are the vocal minority. For the rest of us, we don't complain because it works perfectly fine for us.
You may or may not be right; unless you have numbers, it's really a question of faith. But that was not the question here. "PA works for the majority" is a very different (and possibly true) statement from "PA works for everyone", which is obviously false, and "Most people wanted to get rid of pulseaudio only because people like you perpetuate some stupid myth that PulseAudio is evil" which is worse.
It's of course hard to find reliable numbers anywhere... maybe Smolt could be put to fetch some, though (It already reports if SELinux is enabled, for example).
For what it's worth, I've used pulseaudio in Fedora on at least five computers of various ages (built roughly 2000-2008), none of which have had any major trouble with pulseaudio.
I quite like pulseaudio actually...
Good for you!
I like it, too! :-)
Sharpe, Sam J wrote:
Andras Simon wrote:
On 5/28/09, Kevin Kofler kevin.kofler@chello.at wrote:
Steve Underwood wrote:
I thought most people wanted to get rid of pulseaudio.
Only because people like you perpetuate some stupid myth that
PulseAudio is
evil.
This is not true (and is an insult, I'd think).
[...]
So PulseAudio is a mixing solution which works for everyone.
You must be joking.
You will probably find that the people who want to get rid of pulseaudio are the vocal minority. For the rest of us, we don't complain because it works perfectly fine for us.
Vocal minority makes them sound like a bunch of whining trouble makers. In reality they are the people for whom it didn't work out of the box, because when it doesn't work its so ridiculously painful to figure out what is wrong. No documentation. No debug messages.
I quite like pulseaudio actually...
Well, its fine when it works. You really wouldn't notice its there, which is how these things should be.
Steve
On Thu, May 28, 2009 at 8:44 AM, Steve Underwood steveu@coppice.org wrote:
Sharpe, Sam J wrote:
Andras Simon wrote:
On 5/28/09, Kevin Kofler kevin.kofler@chello.at wrote:
Steve Underwood wrote:
I thought most people wanted to get rid of pulseaudio.
Only because people like you perpetuate some stupid myth that
PulseAudio is
evil.
This is not true (and is an insult, I'd think).
[...]
So PulseAudio is a mixing solution which works for everyone.
You must be joking.
You will probably find that the people who want to get rid of pulseaudio are the vocal minority. For the rest of us, we don't complain because it works perfectly fine for us.
Vocal minority makes them sound like a bunch of whining trouble makers. In reality they are the people for whom it didn't work out of the box, because when it doesn't work its so ridiculously painful to figure out what is wrong. No documentation. No debug messages.
In fact, there is no need to remove anything for deactivating pulse audio.
One just need to add "~/.asoundrc" to /etc/asound.conf
..... files [ "/etc/alsa/pulse-default.conf" "~/.asoundrc" ] .....
and create a file ~/.asoundrc with the following contents:
pcm.!default { type hw card 0 device 0 }
ctl.!default { type hw card 0 }
Of course, a sound application (vlc, mplayer, etc.) should not specify pulse audio as the default in this case (it should use alsa, instead).
I think if we had an option in some menu for deactivating pulseaudio in a similar (or better) way, we could avoid a lot of traffic in this list.
Although, I really like pulseaudio and have used it since the beginning, some people seem to be unable to configure/use it appropriately.
Everything needed is in pavucontrol, and one only needs to click the right mouse button of the mouse onto the stream identifier to set defaults or redirect the output to some card, but maybe some folk just did not realize that yet...
On Thu, 28 May 2009 09:17:51 -0300 Paulo Cavalcanti wrote:
but maybe some folk just did not realize that yet
And just how would they realize how simple all that gibberish actually is? It just comes to them in a flash of insight perhaps? Or maybe the zero documentation has something to do with it :-).
On 05/28/2009 06:32 PM, Tom Horsley wrote:
On Thu, 28 May 2009 09:17:51 -0300 Paulo Cavalcanti wrote:
but maybe some folk just did not realize that yet
And just how would they realize how simple all that gibberish actually is? It just comes to them in a flash of insight perhaps? Or maybe the zero documentation has something to do with it :-).
This seems to be a theme you like but PulseAudio has a lot of details in its website
If you have specific questions, join the mailing list and ask or help out and write up some documentation.
A recent interview
http://jaboutboul.blogspot.com/2009/05/sound-of-fedora-11.
Rahul
On Thursday 28 May 2009, Rahul Sundaram wrote:
On 05/28/2009 06:32 PM, Tom Horsley wrote:
On Thu, 28 May 2009 09:17:51 -0300
Paulo Cavalcanti wrote:
but maybe some folk just did not realize that yet
And just how would they realize how simple all that gibberish actually is? It just comes to them in a flash of insight perhaps? Or maybe the zero documentation has something to do with it :-).
This seems to be a theme you like but PulseAudio has a lot of details in its website
And the last time I looked, a bit over a month ago, there was no hint of what to do when it chooses its default output channel wrong, and effectively sends it all to /dev/null. I fail to see what use it is when it ignores the choices I have setup in my modprobe.conf, and which work for every other audio app we have.
If you have specific questions, join the mailing list and ask or help out and write up some documentation.
I tried, the confirmation replay was bounced. Twice. Same thing with trying to join the nut-user list just this week.
A recent interview
http://jaboutboul.blogspot.com/2009/05/sound-of-fedora-11.
Rahul
On Friday 29 May 2009, Kevin Kofler wrote:
Gene Heskett wrote:
And the last time I looked, a bit over a month ago, there was no hint of what to do when it chooses its default output channel wrong, and effectively sends it all to /dev/null.
You pick the correct default in pavucontrol.
Kevin Kofler
And that IIRC, was one of the things in my kmenu that never ran, ever. And while this box isn't exactly a fresh install of F10 now, that was also true for the fresh install back in February after the main drive crapped out, as it was last fall when I first installed F10. I didn't even get a 30 second dancing cursor, it simply did not run. And since kde4, we no longer have the name of the executable listed in the menu's, there seems to be no way to try such stuff from a cli to see what error falls out when it doesn't run. Having nuked pulse as much as I can, it all works now (for me). What do I have to re-install to make these utils such as what you name above, actually work?
According to rpm -qa I still have:
pulseaudio-libs-0.9.14-3.fc10.i386 xmms-pulse-0.9.4-6.fc10.i386 pulseaudio-utils-0.9.14-3.fc10.i386 wine-pulseaudio-1.1.15-1.fc10.i386 pulseaudio-libs-zeroconf-0.9.14-3.fc10.i386 pulseaudio-core-libs-0.9.14-3.fc10.i386 xine-lib-pulseaudio-1.1.16.3-2.fc10.i386 pulseaudio-libs-glib2-0.9.14-3.fc10.i386
installed.
Right now, it (pavucontrol) does run from the cli, but reports connection refused (of course, no 'server' is running), and the gui is locked up so I can't see any output choices and it all exits when I close the error message box.
pavucontrol? That sounds like it is a control for vu meters of some kind, and with zero docs, who would have known that it is supposedly the configuration tool? If there is to be no docs, then how about _sensible_ names? pa'vu'control indeed. :( Sheesh.
As I have stated before, [root@coyote log]# man pulseaudio No manual entry for pulseaudio
What is so damned secret about this that it has to be hidden behind all the smoke and mirrors & gobbledygook doublespeak such that 2 years+ after it is first included in a fedora snapshot, and its just now that I'm finding out that pavucontrol is actually the configuration tool?
This 'junk' needs some man pages. Without the tools to make it work being available for any and all to use, it is of no more use to me than the tits on a boar hog. But I don't expect there ever to be any, its fedora, right? And don't tell me there isn't room on the dvd. There is a good 500 megs left before the iso is bigger than a single layer dvd, and I _can_ burn duals here according to the propaganda about my drive.
Gene Heskett wrote:
And that IIRC, was one of the things in my kmenu that never ran, ever.
Then PulseAudio is not working. (pavucontrol at least used to just segfault if PA was not running or not accepting connections because it didn't find a working hardware device.)
And since kde4, we no longer have the name of the executable listed in the menu's, there seems to be no way to try such stuff from a cli to see what error falls out when it doesn't run.
The pavucontrol name doesn't show up because the .desktop file doesn't contain it. (It only has a Name field containing a generic name and no GenericName field.) Complain to the pavucontrol maintainer(s) about that. Where the names are contained in the .desktop file (i.e. for most KDE apps), Kickoff will show them if you mouse over that item. Alternatively, you can use the classic menu, which can be configured to show any combination of Name and GenericName.
What do I have to re-install to make these utils such as what you name above, actually work?
yum install kde-settings-pulseaudio should drag in all you need. (You need at least pulseaudio and alsa-plugins-pulseaudio.)
Kevin Kofler
On Friday 29 May 2009, Kevin Kofler wrote:
Gene Heskett wrote:
And that IIRC, was one of the things in my kmenu that never ran, ever.
Then PulseAudio is not working. (pavucontrol at least used to just segfault if PA was not running or not accepting connections because it didn't find a working hardware device.)
And since kde4, we no longer have the name of the executable listed in the menu's, there seems to be no way to try such stuff from a cli to see what error falls out when it doesn't run.
The pavucontrol name doesn't show up because the .desktop file doesn't contain it. (It only has a Name field containing a generic name and no GenericName field.) Complain to the pavucontrol maintainer(s) about that. Where the names are contained in the .desktop file (i.e. for most KDE apps), Kickoff will show them if you mouse over that item. Alternatively, you can use the classic menu, which can be configured to show any combination of Name and GenericName.
What do I have to re-install to make these utils such as what you name above, actually work?
yum install kde-settings-pulseaudio should drag in all you need. (You need at least pulseaudio and alsa-plugins-pulseaudio.)
Kevin Kofler
That pulled in: Installing : pulseaudio 1/4 Installing : alsa-plugins-pulseaudio 2/4 Installing : pulseaudio-module-x11 3/4 Installing : kde-settings-pulseaudio
Now what do I service ??? restart to bring it up?
On Fri, May 29, 2009 at 12:25 PM, Gene Heskett gene.heskett@verizon.netwrote:
On Friday 29 May 2009, Kevin Kofler wrote:
Gene Heskett wrote:
And that IIRC, was one of the things in my kmenu that never ran, ever.
Then PulseAudio is not working. (pavucontrol at least used to just
segfault
if PA was not running or not accepting connections because it didn't find
a
working hardware device.)
And since kde4, we no longer have the name of the executable listed in
the
menu's, there seems to be no way to try such stuff from a cli to see
what
error falls out when it doesn't run.
The pavucontrol name doesn't show up because the .desktop file doesn't contain it. (It only has a Name field containing a generic name and no GenericName field.) Complain to the pavucontrol maintainer(s) about that. Where the names are contained in the .desktop file (i.e. for most KDE apps), Kickoff will show them if you mouse over that item. Alternatively, you can use the classic menu, which can be configured to show any combination of Name and GenericName.
What do I have to re-install to make these utils such as what you name above, actually work?
yum install kde-settings-pulseaudio should drag in all you need. (You need at least pulseaudio and alsa-plugins-pulseaudio.)
Kevin KoflerThat pulled in: Installing : pulseaudio 1/4 Installing : alsa-plugins-pulseaudio 2/4 Installing : pulseaudio-module-x11 3/4 Installing : kde-settings-pulseaudio
Now what do I service ??? restart to bring it up?
Just logging out and back in should do it but a full restart wouldn't hurt. Alternatively you could try opening a terminal and type "pulseaudio -D" which would allow you to see error messages if any. This is from memory so someone correct me if I'm wrong as I only have access to windows at work.
Richard
On Fri, 29 May 2009 11:03:44 -0400 Gene Heskett wrote:
And since kde4, we no longer have the name of the executable listed in the menu's, there seems to be no way to try such stuff from a cli to see what error falls out when it doesn't run.
One bit of arcana worth knowing for just this situation is that all the menu items correspond to .desktop files in the /usr/share/applications/ directory. A grep -r in there will often dig up useful info, then once you find the .desktop file, the "Exec" line in it gives the actual command that is executed by the menu item.
No doubt it should be easier to discover this stuff, but I find digging through the applications directory is often the best way to discover info I need :-).
On 5/29/2009 12:23 PM, Tom Horsley wrote:
On Fri, 29 May 2009 11:03:44 -0400 Gene Heskett wrote:
And since kde4, we no longer have the name of the executable listed in the menu's, there seems to be no way to try such stuff from a cli to see what error falls out when it doesn't run.
One bit of arcana worth knowing for just this situation is that all the menu items correspond to .desktop files in the /usr/share/applications/ directory. A grep -r in there will often dig up useful info, then once you find the .desktop file, the "Exec" line in it gives the actual command that is executed by the menu item.
No doubt it should be easier to discover this stuff, but I find digging through the applications directory is often the best way to discover info I need :-).
The menu editor will also show what application is called by what menu selection. Along with any CLI switches if there are any.
On Thursday 28 May 2009, Tom Horsley wrote:
On Thu, 28 May 2009 09:17:51 -0300
Paulo Cavalcanti wrote:
but maybe some folk just did not realize that yet
And just how would they realize how simple all that gibberish actually is? It just comes to them in a flash of insight perhaps? Or maybe the zero documentation has something to do with it :-).
Nah, couldn't be related. When you add that there are exactly zero configuration tools to aid us in making this undocumented POC work, ahh forget it, this is fedora and we are supposed to bleed for the cause, right?
On Friday 29 May 2009, Patrick O'Callaghan wrote:
On Thu, 2009-05-28 at 13:35 -0400, Gene Heskett wrote:
configuration tools to aid us in making this undocumented POC work, ahh forget
Hey, careful with those acronyms there :-)
poc
Chuckle, sorry about that Patrick, not intended of course.
On Fri, 2009-05-29 at 07:42 -0430, Patrick O'Callaghan wrote:
On Thu, 2009-05-28 at 13:35 -0400, Gene Heskett wrote:
configuration tools to aid us in making this undocumented POC work, ahh forget
Hey, careful with those acronyms there :-)
---- Point Of Contention
similar to acronym POS - Point of Sale
;-)
Craig
Craig White craigwhite@azapple.com writes:
similar to acronym POS - Point of Sale
Point of Stumbling?
-wolfgang
On Friday 29 May 2009, Craig White wrote:
On Fri, 2009-05-29 at 07:42 -0430, Patrick O'Callaghan wrote:
On Thu, 2009-05-28 at 13:35 -0400, Gene Heskett wrote:
configuration tools to aid us in making this undocumented POC work, ahh forget
Hey, careful with those acronyms there :-)
Point Of Contention
Chuckle, that it surely is, but that is NOT the acronym I had in mind.
similar to acronym POS - Point of Sale
Likewise I had another phrase in mind. :)
;-)
Craig
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Fri, 2009-05-29 at 17:58 +0200, Kevin Kofler wrote:
Craig White wrote:
Point Of Contention
Or Proof Of Concept, which would actually fit in that sentence. Though I think it's also not what was meant here. ;-)
Not to mention Point Of Contact, a term used in IETF documents. I imagine that when I filled out the DNS and ASN forms many years ago someone probably thought my email was an alias :-)
poc
Gene Heskett gene.heskett@verizon.net writes:
Nah, couldn't be related. When you add that there are exactly zero configuration tools to aid us in making this undocumented POC work, ahh forget it, this is fedora and we are supposed to bleed for the cause, right?
Motto: "What we lack in documentation we make up for in ideology"
Back in my first unix job a zillion years ago the company I worked for had this rule that nothing got installed in a public */bin directory anywhere unless it also had a man page describing all the command line options installed into the appropriate man directory. That worked out really well in the long run. Newbies and wizards alike appreciated being able to just say "man foo" and be reminded of how things worked. I miss that.
-wolfgang
On Friday 29 May 2009, Wolfgang S. Rupprecht wrote:
Gene Heskett gene.heskett@verizon.net writes:
Nah, couldn't be related. When you add that there are exactly zero configuration tools to aid us in making this undocumented POC work, ahh forget it, this is fedora and we are supposed to bleed for the cause, right?
Motto: "What we lack in documentation we make up for in ideology"
Back in my first unix job a zillion years ago the company I worked for had this rule that nothing got installed in a public */bin directory anywhere unless it also had a man page describing all the command line options installed into the appropriate man directory. That worked out really well in the long run. Newbies and wizards alike appreciated being able to just say "man foo" and be reminded of how things worked. I miss that.
-wolfgang
Wolfgang S. Rupprecht Android 1.5 (Cupcake) and Fedora-11
+10,000
On Fri, 2009-05-29 at 08:00 -0700, Wolfgang S. Rupprecht wrote:
Gene Heskett gene.heskett@verizon.net writes:
Nah, couldn't be related. When you add that there are exactly zero configuration tools to aid us in making this undocumented POC work, ahh forget it, this is fedora and we are supposed to bleed for the cause, right?
Motto: "What we lack in documentation we make up for in ideology"
Back in my first unix job a zillion years ago the company I worked for had this rule that nothing got installed in a public */bin directory anywhere unless it also had a man page describing all the command line options installed into the appropriate man directory. That worked out really well in the long run. Newbies and wizards alike appreciated being able to just say "man foo" and be reminded of how things worked. I miss that.
+1
poc
PS Also, the man pages were for the most part well-written and concise.
Wolfgang S. Rupprecht wrote:
Back in my first unix job a zillion years ago the company I worked for had this rule that nothing got installed in a public */bin directory anywhere unless it also had a man page describing all the command line options installed into the appropriate man directory.
That's also Debian's policy. But I don't think we need such a policy in Fedora. It wouldn't even fix this problem as we're not talking about command-line options here, but about GUI features.
Kevin Kofler
Kevin Kofler kevin.kofler@chello.at writes:
Wolfgang S. Rupprecht wrote:
Back in my first unix job a zillion years ago the company I worked for had this rule that nothing got installed in a public */bin directory anywhere unless it also had a man page describing all the command line options installed into the appropriate man directory.
That's also Debian's policy. But I don't think we need such a policy in Fedora. It wouldn't even fix this problem as we're not talking about command-line options here, but about GUI features.
I think you are reading it much to literally.
Good documentation is lacking, people are complaining and we have people saying that "I don't think we need such a policy in Fedora." Amazing.
-wolfgang
Rahul Sundaram sundaram@fedoraproject.org writes:
If you want to help, you don't really need policy. Do you want to help?
In the last few years I haven't written much OSS, but you can be sure that when I do, I do dig out my troff notes and cobble together a man page for it. I do practice what I preach.
Am I going to write man pages for other folks? Nope. Sorry. First and foremost I'm a strong believer in making the developer explain how to use their program. Doing so forces them to rethink the issues, makes them wonder if something is done logically enough, maybe even gets them to think like a user and wonder what they would find annoying with how the program currently works.
-wolfgang
Wolfgang S. Rupprecht wrote:
Am I going to write man pages for other folks? Nope. Sorry. First and foremost I'm a strong believer in making the developer explain how to use their program. Doing so forces them to rethink the issues, makes them wonder if something is done logically enough, maybe even gets them to think like a user and wonder what they would find annoying with how the program currently works.
Except it doesn't. To some developers, everything is obvious, so the documentation will just say "do this the obvious way". They won't even consider the possibility that it could be non-obvious to somebody else.
Kevin Kofler
On Friday 29 May 2009, Kevin Kofler wrote:
Wolfgang S. Rupprecht wrote:
Am I going to write man pages for other folks? Nope. Sorry. First and foremost I'm a strong believer in making the developer explain how to use their program. Doing so forces them to rethink the issues, makes them wonder if something is done logically enough, maybe even gets them to think like a user and wonder what they would find annoying with how the program currently works.
Except it doesn't. To some developers, everything is obvious, so the documentation will just say "do this the obvious way". They won't even consider the possibility that it could be non-obvious to somebody else.
Kevin Kofler
Another +100 Kevin.
Wolfgang S. Rupprecht wrote:
I think you are reading it much to literally.
The policy you're proposing (and incidentally, also the Debian policy) is that literal. Requiring good documentation makes sense (though it's hard to define "good documentation"). Requiring it to be in manpage format and to document the command-line options (and not requiring anything else), even for GUI apps, doesn't.
Good documentation is lacking, people are complaining and we have people saying that "I don't think we need such a policy in Fedora." Amazing.
How useful is a manpage like this? http://manpages.unixforum.co.uk/man-pages/linux/suse-linux-10.1/1/kalzium-ma... (That's exactly what you get if you consult "man kalzium" on an updated Fedora, it's the manpage which Debian contributed to upstream KDE.)
Kevin Kofler
Kevin Kofler kevin.kofler@chello.at writes:
Wolfgang S. Rupprecht wrote:
I think you are reading it much to literally.
The policy you're proposing (and incidentally, also the Debian policy) is that literal. Requiring good documentation makes sense (though it's hard to define "good documentation"). Requiring it to be in manpage format and to document the command-line options (and not requiring anything else), even for GUI apps, doesn't.
If the problem is that troff is too arcane (and I'll be the first to admit it -- I hate it) then that needs fixing. I don't think it would matter that much what the source for the manpage looked like as long as "man someprogram" would dig up the documentation and display it in a similar looking format.
The problem currently is some of the docs are accessible by man(1), some by info(1) and others by grovelling around /usr/share/doc/ . Instead of the computer doing the work and finding the documentation and displaying it, the user must. Old hacks might know all the places to look, but newbies sure wouldn't.
How useful is a manpage like this? http://manpages.unixforum.co.uk/man-pages/linux/suse-linux-10.1/1/kalzium-ma...
;-)
That is a good example of a contentless man page. I assume it was written by some 3rd party that didn't really understand what the program did, how it was meant to be used etc.
-wolfgang
Wolfgang S. Rupprecht wrote:
That is a good example of a contentless man page. I assume it was written by some 3rd party that didn't really understand what the program did, how it was meant to be used etc.
It was written by the Debian maintainer to fulfill a policy exactly like the one you were proposing. Do you see now why having such a policy at distro level makes no sense?
Kevin Kofler
Kevin Kofler kevin.kofler@chello.at writes:
Wolfgang S. Rupprecht wrote:
That is a good example of a contentless man page. I assume it was written by some 3rd party that didn't really understand what the program did, how it was meant to be used etc.
It was written by the Debian maintainer to fulfill a policy exactly like the one you were proposing. Do you see now why having such a policy at distro level makes no sense?
I never said that one should make some 3rd party write a placeholder manpage.
One should waterboard the developer till he/she agrees to write the manpage.
-wolfgang
On 05/29/2009 11:13 PM, Wolfgang S. Rupprecht wrote:
One should waterboard the developer till he/she agrees to write the manpage.
This is unlikely to be effective as a strategy. Hey, it is somewhat ok that you give me software for free with open source code voluntarily but I demand you write full documentation to go along with it or else ..?
Rahul
On Fri, 2009-05-29 at 23:25 +0530, Rahul Sundaram wrote:
On 05/29/2009 11:13 PM, Wolfgang S. Rupprecht wrote:
One should waterboard the developer till he/she agrees to write the manpage.
This is unlikely to be effective as a strategy. Hey, it is somewhat ok that you give me software for free with open source code voluntarily but I demand you write full documentation to go along with it or else ..?
No, but "I demand that you produce decent documentation before I include your package in my distro" might persuade some people.
poc
On Fri, 29 May 2009 23:25:46 +0530 Rahul Sundaram wrote:
but I demand you write full documentation to go along with it or else ..?
Lots of distros already have anal policies about what can or cannot be included (like being licensed only under the One True open source license).
I'd love a linux distro with a policy that says "We refuse to include anything that doesn't have adequate docs." I think that's a wonderful "or else" to resort to.
Unfortunately, such a linux distribution would currently fit on a 128K thumb drive :-).
On 05/29/2009 11:47 PM, Tom Horsley wrote:
On Fri, 29 May 2009 23:25:46 +0530 Rahul Sundaram wrote:
but I demand you write full documentation to go along with it or else ..?
Lots of distros already have anal policies about what can or cannot be included (like being licensed only under the One True open source license).
Not a single distribution has a policy of allowing software only one license. That is not practical. Fedora allows innumerable licenses
http://fedoraproject.org/wiki/Licensing
I'd love a linux distro with a policy that says "We refuse to include anything that doesn't have adequate docs." I think that's a wonderful "or else" to resort to.
Unfortunately, such a linux distribution would currently fit on a 128K thumb drive :-).
(ie) zero effectiveness. The only way to actually get good documentation is to step up and contribute.
Rahul
Rahul Sundaram sundaram@fedoraproject.org writes:
On 05/29/2009 11:13 PM, Wolfgang S. Rupprecht wrote:
One should waterboard the developer till he/she agrees to write the manpage.
This is unlikely to be effective as a strategy. Hey, it is somewhat ok that you give me software for free with open source code voluntarily but I demand you write full documentation to go along with it or else ..?
How to encourage people to do the right thing is an important question. Linux distributions do have a little bit of pull with the developers. It is not exactly like the developers don't get *anything* out of the transaction. They get their egos stroked and get their name in 12pt pixels on a zillion computer screens. More if they write that manpage and fill in the AUTHORS section. ;-)
-wolfgang
Wolfgang S. Rupprecht wrote:
One should waterboard the developer till he/she agrees to write the manpage.
That can't work at a distro level because upstream does not necessarily care about Fedora, some upstreams even actively hate Fedora. We cannot force upstream projects to do anything, we can only decide what to do within our area of responsibility. Lack of documentation is an upstream issue and should be handled upstream, it's not our job to fix it and we aren't in a position to force upstream to fix it.
In addition, I think "manpages are required" is a silly policy, especially for GUI apps.
Kevin Kofler
On Fri, 2009-05-29 at 08:00 -0700, Wolfgang S. Rupprecht wrote:
Gene Heskett gene.heskett@verizon.net writes:
Nah, couldn't be related. When you add that there are exactly zero configuration tools to aid us in making this undocumented POC work, ahh forget it, this is fedora and we are supposed to bleed for the cause, right?
Motto: "What we lack in documentation we make up for in ideology"
Back in my first unix job a zillion years ago the company I worked for had this rule that nothing got installed in a public */bin directory anywhere unless it also had a man page describing all the command line options installed into the appropriate man directory. That worked out really well in the long run. Newbies and wizards alike appreciated being able to just say "man foo" and be reminded of how things worked. I miss that.
---- there are some who light candles and some will just curse the darkness. If you see a void in the documentation, I reasonably certain that your efforts to fill that void would be appreciated.
Craig
On Fri, 2009-05-29 at 09:08 -0700, Craig White wrote:
On Fri, 2009-05-29 at 08:00 -0700, Wolfgang S. Rupprecht wrote:
Gene Heskett gene.heskett@verizon.net writes:
Nah, couldn't be related. When you add that there are exactly zero configuration tools to aid us in making this undocumented POC work, ahh forget it, this is fedora and we are supposed to bleed for the cause, right?
Motto: "What we lack in documentation we make up for in ideology"
Back in my first unix job a zillion years ago the company I worked for had this rule that nothing got installed in a public */bin directory anywhere unless it also had a man page describing all the command line options installed into the appropriate man directory. That worked out really well in the long run. Newbies and wizards alike appreciated being able to just say "man foo" and be reminded of how things worked. I miss that.
there are some who light candles and some will just curse the darkness. If you see a void in the documentation, I reasonably certain that your efforts to fill that void would be appreciated.
I'm afraid this comes across as smugness. While I'm willing to do some polishing of documentation if asked, actually writing docs for something like PA (or NM, another bugbear of many people here) when one has no idea how it actually works is simply not reasonable. The devels have to shoulder this as part of the process of releasing new software, at least in initial versions.
poc
On 05/29/2009 10:23 PM, Patrick O'Callaghan wrote:
I'm afraid this comes across as smugness. While I'm willing to do some polishing of documentation if asked, actually writing docs for something like PA (or NM, another bugbear of many people here) when one has no idea how it actually works is simply not reasonable. The devels have to shoulder this as part of the process of releasing new software, at least in initial versions.
In my experience, if you volunteer to document something, the developers associated with the project are more than willing to answer questions about it. So if you are serious about this, subscribe to the upstream mailing list and volunteer.
Rahul
On Friday 29 May 2009, Craig White wrote:
On Fri, 2009-05-29 at 08:00 -0700, Wolfgang S. Rupprecht wrote:
Gene Heskett gene.heskett@verizon.net writes:
Nah, couldn't be related. When you add that there are exactly zero configuration tools to aid us in making this undocumented POC work, ahh forget it, this is fedora and we are supposed to bleed for the cause, right?
Motto: "What we lack in documentation we make up for in ideology"
Back in my first unix job a zillion years ago the company I worked for had this rule that nothing got installed in a public */bin directory anywhere unless it also had a man page describing all the command line options installed into the appropriate man directory. That worked out really well in the long run. Newbies and wizards alike appreciated being able to just say "man foo" and be reminded of how things worked. I miss that.
there are some who light candles and some will just curse the darkness. If you see a void in the documentation, I reasonably certain that your efforts to fill that void would be appreciated.
The air up there must be pretty thin. How do you expect anyone to write docs when they have no knowledge of it? That is probably how we got here in the first place...
Craig
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On 05/29/2009 10:58 PM, Gene Heskett wrote:
The air up there must be pretty thin. How do you expect anyone to write docs when they have no knowledge of it? That is probably how we got here in the first place...
Start with what you know, use a search engine, go through the upstream development/user list archives and ask questions to the upstream developers by volunteering to write documentation. It requires some work but it can be done and I have done it before.
Rahul
On Thursday 28 May 2009, Andras Simon wrote:
On 5/28/09, Kevin Kofler kevin.kofler@chello.at wrote:
Steve Underwood wrote:
I thought most people wanted to get rid of pulseaudio.
Only because people like you perpetuate some stupid myth that PulseAudio is evil.
This is not true (and is an insult, I'd think).
[...]
So PulseAudio is a mixing solution which works for everyone.
You must be joking.
Andras
+10.
On Thursday 28 May 2009, Kevin Kofler wrote:
Steve Underwood wrote:
I thought most people wanted to get rid of pulseaudio.
Only because people like you perpetuate some stupid myth that PulseAudio is evil.
Its a very troublesome program with poor documentation, and little output to help you resolve problems. If you get it working it seems to offer you nothing you didn't have before you had pulseaudio.
+1000
It makes sound just work, without apps fighting for the sound device (or multiple incompatible sound servers all trying to "fix" this fighting for the sound device). No more annoyances like games failing to play sound because some GUI event sound was still being played when they tried opening the sound device. (I've seen, or rather heard, that happen way too often in pre-PulseAudio times.)
Yeah, but with it working, only the system beep works...
Most sound cards don't do mixing in hardware. A few do support it, but the ALSA driver doesn't. Only few sound cards can do it and have ALSA support for it. So PulseAudio is a mixing solution which works for everyone.
Kevin Kofler
If only it worked...
And I will continue to denigrate it until we have a configuration tool that WILL let us make it work regardless of ones choice of hardware.
On Thursday 28 May 2009, Kevin Kofler wrote:
Steve Underwood wrote:
I thought most people wanted to get rid of pulseaudio.
Only because people like you perpetuate some stupid myth that PulseAudio is evil.
Its a very troublesome program with poor documentation, and little output to help you resolve problems. If you get it working it seems to offer you nothing you didn't have before you had pulseaudio.
+1000
It makes sound just work, without apps fighting for the sound device (or multiple incompatible sound servers all trying to "fix" this fighting for the sound device). No more annoyances like games failing to play sound because some GUI event sound was still being played when they tried opening the sound device. (I've seen, or rather heard, that happen way too often in pre-PulseAudio times.)
Yeah, but with it working, only the system beep works...
Most sound cards don't do mixing in hardware. A few do support it, but the ALSA driver doesn't. Only few sound cards can do it and have ALSA support for it. So PulseAudio is a mixing solution which works for everyone.
Kevin KoflerIf only it worked...
And I will continue to denigrate it until we have a configuration tool that WILL let us make it work regardless of ones choice of hardware.
And therein lies the rub.
There are times when I can start up my X session, and it appears that everything works...then, other times, I start up my X session and I get a popup box indicating that PulseAudo wouldn't work because of something, and it's falling back to another mode of sound.
Hi Kevin,
Many thanks for your interest to my problem. Sorry, I may not have replied as soon as you'd expect. This is because, after reading your response and others, I tried several things which were suggested to me.
But, first, here's my problem:
My PC is quite old. It's a Compaq desktop 5100 with A Pentium II running at 800 mHz, 512 MB of RAM and an Intel I810 audio chip.
On this PC, I first installed a fedora 9 which worked like a charm until recently.
On the gnome desktop, I launch the "orca" screen reader which I configured to say screen content through the ESpeak speech synthesizer.
A month ago, after a yum update, the synth began to drop last syllables of what it had to say. For instance, "Welcome to Orca" became "Welcome to Or".
Yesterday, I upgraded the F9 PC to F10 in order to benefit from many enhancements of Orca and the gnome desktop from 2.22 top 2.24.
As a result, I don't hear ESpeak anymore.
I suspected pulseaudio to be the culprit after doing the following.
(1) I booted the PC in runlevel 3, (console only).
(2) I logged onto my account and issued the following command:
script -c startx
(3) After awhile, I could hear the login sound and then orca was launched and brailled "Welcome to orca" but it did not speak. Also the screen reader continued to braille, it did not say anything.
(4) I logged out X and then, after the X server was shut down, I was back to the console.
(5) In the "typescript" file which was generated by "script", I read that some actions required me to have increased RT_PRIO or RLIMIT_NICE capabilities. It was suggested to add my user account to the "pulse-rt" group.
(6) I did this by logging as root and entering the command:
usermod -a -G pulse-rt <my_login>
Then I logged out from root and back in to my account.
(7) I started the gnome desktop but to no avail. Of course, I didn't have the warning I had before but always no speech.
(8) I then logged in as root and tried to "yum erase pulseaudio". Four dependent packages were also removed. I wrote down their names in order to be able to reinstall them all later.
(9) I then logged out root and logged in back to my account and started the gnome desktop. This time, I did not hear the login sound but after awhile, I heard ESpeak saying "Welcome to orc". The synth did not finish its sentence but it talked. Problem: This is the only sentence I could hear. Then, orca was totally frozen: no more braille, no more speech, just as if orca was deadlocked somewhere.
(10) I reinstalled pusleaudio and its four dependent packages and tried to start gnome again. This time, I heard the login sound but no speech, just like in (7).
(11) I finally tried to modify /etc/asound.conf and to create a ~/.asoundrc in my home directory, as suggested by Paulo Cavalcanti. This time, when I started the gnome desktop, I heard the login sound, then "Welcome to Orc", ESpeak did not finish and Orca was frozen like in (9).
Now, I realize that my problem may not be due to pulseaudio but what should I do to have ESpeak work in F10 like it did in F9 please?
Many thanks in advance. Have a nice day. Chris
-----Original Message----- From: fedora-list-bounces@redhat.com [mailto:fedora-list-bounces@redhat.com] On Behalf Of Kevin Kofler Sent: jeudi 28 mai 2009 00:14 To: fedora-list@redhat.com Subject: Re: I'd like to get rid of pulseaudio but ...
Delaunay Christophe wrote:
What the good way to get rid of pulseaudio on Fedora 10 please?
Why do you want to do that in the first place? Chances are removing PulseAudio is not the correct solution for your problem.
Kevin Kofler
On Thu, May 28, 2009 at 11:26 AM, Delaunay Christophe < christophe.delaunay@thomson.net> wrote:
Hi Kevin,
Many thanks for your interest to my problem. Sorry, I may not have replied as soon as you'd expect. This is because, after reading your response and others, I tried several things which were suggested to me.
But, first, here's my problem:
My PC is quite old. It's a Compaq desktop 5100 with A Pentium II running at 800 mHz, 512 MB of RAM and an Intel I810 audio chip.
On this PC, I first installed a fedora 9 which worked like a charm until recently.
On the gnome desktop, I launch the "orca" screen reader which I configured to say screen content through the ESpeak speech synthesizer.
A month ago, after a yum update, the synth began to drop last syllables of what it had to say. For instance, "Welcome to Orca" became "Welcome to Or".
Yesterday, I upgraded the F9 PC to F10 in order to benefit from many enhancements of Orca and the gnome desktop from 2.22 top 2.24.
As a result, I don't hear ESpeak anymore.
I suspected pulseaudio to be the culprit after doing the following.
(1) I booted the PC in runlevel 3, (console only).
(2) I logged onto my account and issued the following command:
script -c startx
(3) After awhile, I could hear the login sound and then orca was launched and brailled "Welcome to orca" but it did not speak. Also the screen reader continued to braille, it did not say anything.
(4) I logged out X and then, after the X server was shut down, I was back to the console.
(5) In the "typescript" file which was generated by "script", I read that some actions required me to have increased RT_PRIO or RLIMIT_NICE capabilities. It was suggested to add my user account to the "pulse-rt" group.
(6) I did this by logging as root and entering the command:
usermod -a -G pulse-rt <my_login>
Then I logged out from root and back in to my account.
(7) I started the gnome desktop but to no avail. Of course, I didn't have the warning I had before but always no speech.
(8) I then logged in as root and tried to "yum erase pulseaudio". Four dependent packages were also removed. I wrote down their names in order to be able to reinstall them all later.
(9) I then logged out root and logged in back to my account and started the gnome desktop. This time, I did not hear the login sound but after awhile, I heard ESpeak saying "Welcome to orc". The synth did not finish its sentence but it talked. Problem: This is the only sentence I could hear. Then, orca was totally frozen: no more braille, no more speech, just as if orca was deadlocked somewhere.
(10) I reinstalled pusleaudio and its four dependent packages and tried to start gnome again. This time, I heard the login sound but no speech, just like in (7).
(11) I finally tried to modify /etc/asound.conf and to create a ~/.asoundrc in my home directory, as suggested by Paulo Cavalcanti. This time, when I started the gnome desktop, I heard the login sound, then "Welcome to Orc", ESpeak did not finish and Orca was frozen like in (9).
Now, I realize that my problem may not be due to pulseaudio but what should I do to have ESpeak work in F10 like it did in F9 please?
Many thanks in advance. Have a nice day. Chris
I have never used orca before, but it seems to be working fine here with pulseaudio. The difficult part is to make she stop talking ...
I also tried espeak, and it is also reading file names via command line.
Did you make a clean install or used some kind of upgrade from F9 to F10?
Delaunay Christophe wrote:
through the ESpeak speech synthesizer
If you have portaudio-19-6.fc10, espeak should just work with PulseAudio. As I did the fix for portaudio, I'm highly interested in any issues with it.
For instance, "Welcome to Orca" became "Welcome to Or".
I cannot reproduce this here (pulseaudio-0.9.10-2.fc9.i386, portaudio-19-6.fc9.i386, espeak-1.31-5.fc9.i386), at least not from the command line. espeak "Welcome to Orca" works just fine, the "ca" doesn't get truncated.
Unfortunately, I can't test Orca because of: https://bugzilla.redhat.com/show_bug.cgi?id=448198
I also found another Orca bug while testing this: https://bugzilla.redhat.com/show_bug.cgi?id=503193
As a result [of upgrading to F10], I don't hear ESpeak anymore.
Nor can I reproduce this. I can try on my laptop which already runs F10.
Kevin Kofler
-
Andras Simon -
Craig White -
David Boles -
Delaunay Christophe -
Frank Murphy -
Gene Heskett -
John Wendel -
Jonathan Dieter -
Joonas Sarajärvi -
Kevin Kofler -
Konstantin Svist -
Mike Burger -
Pasi Kärkkäinen -
Patrick O'Callaghan -
Paulo Cavalcanti -
Rahul Sundaram -
Richard Shaw -
Sam Sharpe -
Steve Underwood -
Suvayu Ali -
Tim -
Tom Horsley -
Wolfgang S. Rupprecht