Folks,
As some of you might remember, I have experienced hell with Fedora sound ever since, well, FC3 or maybe earlier. Every time I complained, I was told to file bug reports, which I did, and nothing much was done about it.
I am an old time Linux user & hacker, been using Linux since 1996. It's now 2008, we're about to release F9, and sound is still a big mess. This is not about filing bug reports, it's a systemic problem that must be addressed.
The long and short of it is that sound works sometimes, and then stops working. It just does. Maybe from an update, but it just stops working. Then you start fscking around with all sort of settings, and _maybe_ you get it working again. Maybe not.
But every time there is any change or you reboot the system, it is a Russian roulette if the sound will still work. It is believably f-r-u-s-t-r-a-t-i-n-g.
For example today: sound stopped working 2 days ago through my regular speakers (the USB headphones always work!). This morning there was another big pile of updates, so I decided to reboot the system, maybe that would fix it. 2h(!) later, I have no sound, and instead of working, I'm writing a long message to fedora-devel :)
Cause: pulseaudio refuses to make use of the built-in (Intel) sound card. And I can't figure out how to force it! BTW: I use Gnome, I have ESD checked (that's an obvious label!) so pulseaudio is enabled.
It will just use the USB headphones. If I use Rhythmbox, it uses the default desktop output, and that goes to my USB headphones.
Audacious on the other hand, behaves like this: * if output is set to ALSA:default, it will go to my headphones * if output is set to PulseAudio, it will stutter like crazy * if output is set to ALSA:hw:1,0 it will go to the system speakers
So built-in sound works just fine, just PulseAudio refuses to use it.
Can we stop breaking working systems with every other set of updates?!? How can one depend on F8 for regular day-to-day work if w continue in this fashion?
On Thu, Mar 13, 2008 at 9:00 AM, Lubomir Kundrak lkundrak@redhat.com wrote:
On Thu, 2008-03-13 at 11:02 -0400, Dimi Paun wrote:
Folks,
...
Do you have a bug report id? If not, please don't bother us with your sound problems. If yes, there's no need to spam -devel list with your pet bug.
https://bugzilla.redhat.com/show_bug.cgi?id=428537
There was also someone in Fedora People mentioning the same problem a day or so ago, but I don't recall who.
darrell
On Thu, 2008-03-13 at 17:00 +0100, Lubomir Kundrak wrote:
Do you have a bug report id? If not, please don't bother us with your sound problems. If yes, there's no need to spam -devel list with your pet bug.
So you think that while running a stable (not Rawhide) version of Fedora, it is normal for me to file a sound-related bug report every few days when it stops working, for the past 4 years or so?
And the bug should say what? Sound doesn't work? I tried: kernel guys says it's ALSA, ALSA says it's SELinux, others say it's PA. It is hopeless -- a single such report takes many hours to follow up, and if I'm lucky, I'm told to download some sources and compile them myself to test them out (which I'll _not_ do on my RPM-managed production system).
I don't have problems with filing bug reports, but please realize it's not sustainable to ask a user to _continuously_ file the same bug report for a critical system component such as sound. This is not a pet bug (as you so graciously remarked), but a critical component on which many business processes revolve (think Skype+conference).
We can't keep breaking working systems in a stable release with such ease as it seems to happen now. This is F8, not Rawhide. It's the sort of problem that has to be addressed here, not in a bug report.
On Thu, Mar 13, 2008 at 9:23 AM, Dimi Paun dimi@lattica.com wrote:
On Thu, 2008-03-13 at 17:00 +0100, Lubomir Kundrak wrote:
Do you have a bug report id? If not, please don't bother us with your sound problems. If yes, there's no need to spam -devel list with your pet bug.
So you think that while running a stable (not Rawhide) version of Fedora, it is normal for me to file a sound-related bug report every few days when it stops working, for the past 4 years or so?
And the bug should say what? Sound doesn't work? I tried: kernel guys says it's ALSA, ALSA says it's SELinux, others say it's PA. It is hopeless -- a single such report takes many hours to follow up, and if I'm lucky, I'm told to download some sources and compile them myself to test them out (which I'll _not_ do on my RPM-managed production system).
I don't have problems with filing bug reports, but please realize it's not sustainable to ask a user to _continuously_ file the same bug report for a critical system component such as sound. This is not a pet bug (as you so graciously remarked), but a critical component on which many business processes revolve (think Skype+conference).
We can't keep breaking working systems in a stable release with such ease as it seems to happen now. This is F8, not Rawhide. It's the sort of problem that has to be addressed here, not in a bug report.
I've found pulse/sound to be pretty good, except for an issue with how the pulseaudio daemon starts: https://bugzilla.redhat.com/show_bug.cgi?id=425763
It seems that sometimes on reboot, pulse gets confused and thinks there already is a copy of the daemon running, and so doesn't start one.
If you have the "sometimes pulse works and sometimes it doesn't on reboot" situation, you may want to jump on the above BZ. [There is a hack described there that seems to paper over the issue for me.]
tom
On Thu, 2008-03-13 at 09:36 -0700, Tom London wrote:
I've found pulse/sound to be pretty good, except for an issue with how the pulseaudio daemon starts: https://bugzilla.redhat.com/show_bug.cgi?id=425763
It seems that sometimes on reboot, pulse gets confused and thinks there already is a copy of the daemon running, and so doesn't start one.
If you have the "sometimes pulse works and sometimes it doesn't on reboot" situation, you may want to jump on the above BZ. [There is a hack described there that seems to paper over the issue for me.]
I've run in to this myself. Pulse dies or hangs for some reason, leaving the lockfile. Then it refuses to start again. Drove me nuts, it took an strace run to figure out the lockfile was in /tmp, and not ~/. This is not documented in any obvious place. And there's no command line option to force start or force cleanup. Epic fail.
Don't we have *libraries* that get this lockfile stuff right? Seems like something rather fundamental to unix programming. And yet people still manage to do it wrong.
On Thu, 13.03.08 12:19, Callum Lerwick (seg@haxxed.com) wrote:
It seems that sometimes on reboot, pulse gets confused and thinks there already is a copy of the daemon running, and so doesn't start one.
If you have the "sometimes pulse works and sometimes it doesn't on reboot" situation, you may want to jump on the above BZ. [There is a hack described there that seems to paper over the issue for me.]
I've run in to this myself. Pulse dies or hangs for some reason, leaving the lockfile. Then it refuses to start again. Drove me nuts, it took an strace run to figure out the lockfile was in /tmp, and not ~/. This is not documented in any obvious place. And there's no command line option to force start or force cleanup. Epic fail.
Don't we have *libraries* that get this lockfile stuff right? Seems like something rather fundamental to unix programming. And yet people still manage to do it wrong.
The problem here is that /var/run is usually cleaned up during bootup, so it's usually fine to just do a kill(pid, 0) to detect whether a daemon is already running. However, PA runs as user daemon and thus cannot write to /var/run. I thus chose /tmp/ copying X and esd a bit. Which is admittedly a bad idea, and also introduces a (minor) security issue.
Recent version of PA check the proc name of the PID they read from the file before thinking that it is already running. The bug is fixed.
Lennart
On Thu, Mar 13, 2008 at 3:51 PM, Lennart Poettering mzerqung@0pointer.de wrote:
On Thu, 13.03.08 12:19, Callum Lerwick (seg@haxxed.com) wrote:
It seems that sometimes on reboot, pulse gets confused and thinks there already is a copy of the daemon running, and so doesn't start one.
If you have the "sometimes pulse works and sometimes it doesn't on reboot" situation, you may want to jump on the above BZ. [There is a hack described there that seems to paper over the issue for me.]
I've run in to this myself. Pulse dies or hangs for some reason, leaving the lockfile. Then it refuses to start again. Drove me nuts, it took an strace run to figure out the lockfile was in /tmp, and not ~/. This is not documented in any obvious place. And there's no command line option to force start or force cleanup. Epic fail.
Don't we have *libraries* that get this lockfile stuff right? Seems like something rather fundamental to unix programming. And yet people still manage to do it wrong.
The problem here is that /var/run is usually cleaned up during bootup, so it's usually fine to just do a kill(pid, 0) to detect whether a daemon is already running. However, PA runs as user daemon and thus cannot write to /var/run. I thus chose /tmp/ copying X and esd a bit. Which is admittedly a bad idea, and also introduces a (minor) security issue.
Recent version of PA check the proc name of the PID they read from the file before thinking that it is already running. The bug is fixed.
Lennart
Cool. Don't see this in the changelog for pulseaudio package. Which version has it, and I'll test.
tom
On Thu, 2008-03-13 at 23:51 +0100, Lennart Poettering wrote:
The problem here is that /var/run is usually cleaned up during bootup, so it's usually fine to just do a kill(pid, 0) to detect whether a daemon is already running. However, PA runs as user daemon and thus cannot write to /var/run. I thus chose /tmp/ copying X and esd a bit. Which is admittedly a bad idea, and also introduces a (minor) security issue.
The best thing to do is to use the DBus session bus. Have pulseaudio grab a bus name such as org.pulseaudio.SessionDaemon.
Pid files and using /tmp is inherently racy and broken.
On Fri, 14.03.08 12:27, Colin Walters (walters@redhat.com) wrote:
On Thu, 2008-03-13 at 23:51 +0100, Lennart Poettering wrote:
The problem here is that /var/run is usually cleaned up during bootup, so it's usually fine to just do a kill(pid, 0) to detect whether a daemon is already running. However, PA runs as user daemon and thus cannot write to /var/run. I thus chose /tmp/ copying X and esd a bit. Which is admittedly a bad idea, and also introduces a (minor) security issue.
The best thing to do is to use the DBus session bus. Have pulseaudio grab a bus name such as org.pulseaudio.SessionDaemon.
Uh? Grab a name for nothing? Also, this would prohibit multiple instances of PA for different users.
Pid files and using /tmp is inherently racy and broken.
Sure, I acknowledge that.
Lennart
On Tue, Mar 25, 2008 at 8:57 PM, Lennart Poettering mzerqung@0pointer.de wrote:
Uh? Grab a name for nothing?
Not for nothing - the DBus name acts as an atomic instance lock. It might also make sense to use DBus for some of the daemon control IPC.
Also, this would prohibit multiple instances of PA for different users.
Pulseaudio runs as part of the session, no? I'm talking about grabbing a name on the session bus.
On Tue, 25.03.08 21:02, Colin Walters (walters@verbum.org) wrote:
On Tue, Mar 25, 2008 at 8:57 PM, Lennart Poettering mzerqung@0pointer.de wrote:
Uh? Grab a name for nothing?
Not for nothing - the DBus name acts as an atomic instance lock. It might also make sense to use DBus for some of the daemon control IPC.
Also, this would prohibit multiple instances of PA for different users.
Pulseaudio runs as part of the session, no? I'm talking about grabbing a name on the session bus.
Sorry. I am confused.
However, I'd still need a dir to place my UNIX socket.
Lennart
On Tue, Mar 25, 2008 at 9:11 PM, Lennart Poettering mzerqung@0pointer.de wrote:
However, I'd still need a dir to place my UNIX socket.
Algorithm is this:
1) Attempt to grab the org.freedesktop.PulseAudio name, if successful goto 2, else goto 3 2) Create the unix socket in a new directory created with mkdtemp, drop to main loop answering requests 3) Call the method org.freedesktop.PulseAudio.GetUnixSocket on the existing instance, which returns a string, goto 4 4) Connect to the socket address returned by invocation of that method
Colin Walters (walters@verbum.org) said:
However, I'd still need a dir to place my UNIX socket.
Algorithm is this:
- Attempt to grab the org.freedesktop.PulseAudio name, if successful
goto 2, else goto 3 2) Create the unix socket in a new directory created with mkdtemp, drop to main loop answering requests 3) Call the method org.freedesktop.PulseAudio.GetUnixSocket on the existing instance, which returns a string, goto 4 4) Connect to the socket address returned by invocation of that method
Wait, why can't this socket be abstract? Why do you need a dir?
Bill
On Tue, Mar 25, 2008 at 11:52 PM, Bill Nottingham notting@redhat.com wrote:
Wait, why can't this socket be abstract? Why do you need a dir?
Abstract is a good idea, yep.
On Wed, Mar 26, 2008 at 8:36 AM, Colin Walters walters@verbum.org wrote:
On Tue, Mar 25, 2008 at 11:52 PM, Bill Nottingham notting@redhat.com wrote:
Wait, why can't this socket be abstract? Why do you need a dir?
Abstract is a good idea, yep.
(Though you still need the concrete fallback for non-Linux)
On Wed, 2008-03-26 at 01:57 +0100, Lennart Poettering wrote:
On Fri, 14.03.08 12:27, Colin Walters (walters@redhat.com) wrote:
On Thu, 2008-03-13 at 23:51 +0100, Lennart Poettering wrote:
The problem here is that /var/run is usually cleaned up during bootup, so it's usually fine to just do a kill(pid, 0) to detect whether a daemon is already running. However, PA runs as user daemon and thus cannot write to /var/run. I thus chose /tmp/ copying X and esd a bit. Which is admittedly a bad idea, and also introduces a (minor) security issue.
The best thing to do is to use the DBus session bus. Have pulseaudio grab a bus name such as org.pulseaudio.SessionDaemon.
Uh? Grab a name for nothing? Also, this would prohibit multiple instances of PA for different users.
Another very useful way to deal with this situation (which is what Samba does) is to take an fcntl lock on the PID file. This will nicely go away with the process, and clearly no other process will grab a lock on a pulse-audio.pid file.
Andrew Bartlett
On Wed, 26.03.08 12:04, Andrew Bartlett (abartlet@samba.org) wrote:
The best thing to do is to use the DBus session bus. Have pulseaudio grab a bus name such as org.pulseaudio.SessionDaemon.
Uh? Grab a name for nothing? Also, this would prohibit multiple instances of PA for different users.
Another very useful way to deal with this situation (which is what Samba does) is to take an fcntl lock on the PID file. This will nicely go away with the process, and clearly no other process will grab a lock on a pulse-audio.pid file.
We already use POSIX locking for making sure that access to the PID file is properly serialized.
Lennart
On Wed, 2008-03-26 at 02:13 +0100, Lennart Poettering wrote:
On Wed, 26.03.08 12:04, Andrew Bartlett (abartlet@samba.org) wrote:
The best thing to do is to use the DBus session bus. Have pulseaudio grab a bus name such as org.pulseaudio.SessionDaemon.
Uh? Grab a name for nothing? Also, this would prohibit multiple instances of PA for different users.
Another very useful way to deal with this situation (which is what Samba does) is to take an fcntl lock on the PID file. This will nicely go away with the process, and clearly no other process will grab a lock on a pulse-audio.pid file.
We already use POSIX locking for making sure that access to the PID file is properly serialized.
Seriously; use D-Bus and abstract sockets, and then you can avoid all the icky, nasty races that are inherent with PID files. PID files need to die.
Dan
Lennart
-- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4
On Thu, 13 Mar 2008 09:36:40 -0700, Tom London wrote:
I've found pulse/sound to be pretty good, except for an issue with how the pulseaudio daemon starts: https://bugzilla.redhat.com/show_bug.cgi?id=425763
It seems that sometimes on reboot, pulse gets confused and thinks there already is a copy of the daemon running, and so doesn't start one.
As I've added to one of the tickets about that, here it was reproducible. At boot-time, the /tmp/pulse-$USER/pid file still existed and contained the pid number from before the shutdown, but a different process now got that pid.
There are several older and newer duplicates of that ticket. They have been closed in a chaotic way. One still open is: http://bugzilla.redhat.com/405351
Dimi Paun wrote:
On Thu, 2008-03-13 at 17:00 +0100, Lubomir Kundrak wrote:
Do you have a bug report id? If not, please don't bother us with your sound problems. If yes, there's no need to spam -devel list with your pet bug.
So you think that while running a stable (not Rawhide) version of Fedora, it is normal for me to file a sound-related bug report every few days when it stops working, for the past 4 years or so?
And the bug should say what? Sound doesn't work? I tried: kernel guys says it's ALSA, ALSA says it's SELinux, others say it's PA. It is hopeless -- a single such report takes many hours to follow up, and if I'm lucky, I'm told to download some sources and compile them myself to test them out (which I'll _not_ do on my RPM-managed production system).
I don't have problems with filing bug reports, but please realize it's not sustainable to ask a user to _continuously_ file the same bug report for a critical system component such as sound. This is not a pet bug (as you so graciously remarked), but a critical component on which many business processes revolve (think Skype+conference).
We can't keep breaking working systems in a stable release with such ease as it seems to happen now. This is F8, not Rawhide. It's the sort of problem that has to be addressed here, not in a bug report.
Well it was sometime during FC6 I decided to try PulseAudio :) and I wanted to try it not because it let me change volume of every application separately but because it was possible to make all the users on the system use the same daemon. That way the system woldn't refuse to open the sound device for user A when user B was playing something (or just had artsd started). There were no problems with multiple applications using the same device (thanks to ALSA dmix). It didn't work as good as I thought it could and the latency was quite annoying. It behaved really funny when you just started an audio player and started seeking in the track. So I quit it. When I read PulseAudio was to be integrated in Fedora I thought it was being done for the same reason I tried to do it. But obviously it wasn't. It wasn't started as a system-wide daemon. So it didn't do what I wanted to and the latency remained huge. But it wasn't a big problem until I started developing a VoIP solution for the company I work for. I installed Twinkle (Sip SoftPhone) to test it. I installed it both at home and at work. Alsa emulation didn't work for it at all nor did oss :). It did work at home using :0 device when PA wasn't playing anything but refused to do the same thing at work. Skype and a few other softphones i tried didn't work too. Removing PA was the only step needed to solve it at home. At work it was a bit harder. I had to remove PA and make Twinkle use ALSA for output and OSS for input :D . I really like the idea of a single sound server (I always admired X11) but IMHO PA is not ready yet to be enable by default. BTW SELinux is disabled on both systems and I do "yum update" DAILY.
Suren
On Thu, 2008-03-13 at 12:23 -0400, Dimi Paun wrote:
On Thu, 2008-03-13 at 17:00 +0100, Lubomir Kundrak wrote:
Do you have a bug report id? If not, please don't bother us with your sound problems. If yes, there's no need to spam -devel list with your pet bug.
So you think that while running a stable (not Rawhide) version of Fedora, it is normal for me to file a sound-related bug report every few days when it stops working, for the past 4 years or so?
Now tell me you were not aware of the volume of updates that come with Fedora? If you were and you were not aware things may break then you are either naive or have some other problem. Noone forces you to install those, you could use yum-security plugin for example. And if even security updates break your system (the pulseaudio one was security) -- and you have no interest in contributing to development -- ever heard of Red Hat Enterprise Linux? You made the wrong choice.
Moreover, if you looked into history of this list, you would certainly discover what was the reason for the pulseaudio update (and find whom to blame :), but you certainly didn't bother. All you used this list for was "You keep breaking my system", which is very rude towards people who devote their time to developing it. If you helped them troubleshoot the problem (with a bug report and useful debugging information), that would be another story.
And the bug should say what? Sound doesn't work? I tried: kernel guys says it's ALSA, ALSA says it's SELinux, others say it's PA. It is hopeless -- a single such report takes many hours to follow up, and if I'm lucky, I'm told to download some sources and compile them myself to test them out (which I'll _not_ do on my RPM-managed production system).
If you're not informed and skilled enough to debug the problem, the developers would certainly be interested to help you. That's what bug reports are for, no need to pollute mailing list with it.
I don't have problems with filing bug reports, but please realize it's not sustainable to ask a user to _continuously_ file the same bug report for a critical system component such as sound. This is not a pet bug (as you so graciously remarked), but a critical component on which many business processes revolve (think Skype+conference).
Lubomir Kundrak wrote:
So you think that while running a stable (not Rawhide) version of Fedora, it is normal for me to file a sound-related bug report every few days when it stops working, for the past 4 years or so?
Now tell me you were not aware of the volume of updates that come with Fedora? If you were and you were not aware things may break then you are either naive or have some other problem. Noone forces you to install those, you could use yum-security plugin for example. And if even security updates break your system (the pulseaudio one was security) -- and you have no interest in contributing to development -- ever heard of Red Hat Enterprise Linux? You made the wrong choice.
Or, if you want something free, there is CentOS.
Moreover, if you looked into history of this list, you would certainly discover what was the reason for the pulseaudio update (and find whom to blame :), but you certainly didn't bother.
Is the reason a broken system is shipping supposed to be relevant to an end user?
If you're not informed and skilled enough to debug the problem, the developers would certainly be interested to help you. That's what bug reports are for, no need to pollute mailing list with it.
And when the bug reports have no activity for months?
On 2008-03-13, 16:00 GMT, Lubomir Kundrak wrote:
Do you have a bug report id? If not, please don't bother us with your sound problems. If yes, there's no need to spam -devel list with your pet bug.
I don't think we have any rights to write stuff like that when bugs for ConsoleKit dealing with this are NEW even though they were filed in October (bugs 332781, 401951, 432399, 432956, 428032, 401951 for example).
Matej
Dimi Paun wrote:
Folks,
As some of you might remember, I have experienced hell with Fedora sound ever since, well, FC3 or maybe earlier. Every time I complained, I was told to file bug reports, which I did, and nothing much was done about it.
I am an old time Linux user & hacker, been using Linux since 1996. It's now 2008, we're about to release F9, and sound is still a big mess. This is not about filing bug reports, it's a systemic problem that must be addressed.
Lennart is working hard on getting "linux sound system" into the 21 century..
The long and short of it is that sound works sometimes, and then stops working. It just does. Maybe from an update, but it just stops working. Then you start fscking around with all sort of settings, and _maybe_ you get it working again. Maybe not.
But every time there is any change or you reboot the system, it is a Russian roulette if the sound will still work. It is believably f-r-u-s-t-r-a-t-i-n-g.
For example today: sound stopped working 2 days ago through my regular speakers (the USB headphones always work!). This morning there was another big pile of updates, so I decided to reboot the system, maybe that would fix it. 2h(!) later, I have no sound, and instead of working, I'm writing a long message to fedora-devel :)
Go Selinux Go Policykit ( yet another step closer to Vista/M$ way.. )
Cause: pulseaudio refuses to make use of the built-in (Intel) sound card. And I can't figure out how to force it! BTW: I use Gnome, I have ESD checked (that's an obvious label!) so pulseaudio is enabled.
Maybe because something is denying it access to the built-in soundcard
It will just use the USB headphones. If I use Rhythmbox, it uses the default desktop output, and that goes to my USB headphones.
Audacious on the other hand, behaves like this:
- if output is set to ALSA:default, it will go to my headphones
- if output is set to PulseAudio, it will stutter like crazy
- if output is set to ALSA:hw:1,0 it will go to the system speakers
So built-in sound works just fine, just PulseAudio refuses to use it.
I would say it was not allowed to use it, it wants to but cant...
Can we stop breaking working systems with every other set of updates?!? How can one depend on F8 for regular day-to-day work if w continue in this fashion?
Best regards. Johann B.
On Thu, 2008-03-13 at 11:02 -0400, Dimi Paun wrote:
Folks,
As some of you might remember, I have experienced hell with Fedora sound ever since, well, FC3 or maybe earlier. Every time I complained, I was told to file bug reports, which I did, and nothing much was done about it.
I am an old time Linux user & hacker, been using Linux since 1996. It's now 2008, we're about to release F9, and sound is still a big mess. This is not about filing bug reports, it's a systemic problem that must be addressed.
The long and short of it is that sound works sometimes, and then stops working. It just does. Maybe from an update, but it just stops working. Then you start fscking around with all sort of settings, and _maybe_ you get it working again. Maybe not.
But every time there is any change or you reboot the system, it is a Russian roulette if the sound will still work. It is believably f-r-u-s-t-r-a-t-i-n-g.
For example today: sound stopped working 2 days ago through my regular speakers (the USB headphones always work!). This morning there was another big pile of updates, so I decided to reboot the system, maybe that would fix it. 2h(!) later, I have no sound, and instead of working, I'm writing a long message to fedora-devel :)
Cause: pulseaudio refuses to make use of the built-in (Intel) sound card. And I can't figure out how to force it! BTW: I use Gnome, I have ESD checked (that's an obvious label!) so pulseaudio is enabled.
It will just use the USB headphones. If I use Rhythmbox, it uses the default desktop output, and that goes to my USB headphones.
Audacious on the other hand, behaves like this:
- if output is set to ALSA:default, it will go to my headphones
- if output is set to PulseAudio, it will stutter like crazy
That might just be Audacious' plugin sucking as well. Tried with something like Totem or Rhythmbox that uses the (well-tested) GStreamer plugin from PA upstream?
- if output is set to ALSA:hw:1,0 it will go to the system speakers
1) Is the ALSA Pulseaudio plugin installed? 2) Did you try selecting another default output in pavucontrol? (output devices->right-click, select the default, yes the UI sucks) 3) Did you try running pulseaudio by itself on the command-line to see whether it prints out any errors?
That last one seems like the first thing you should have done before blaming PulseAudio...
On Thu, Mar 13, 2008 at 3:29 PM, Bastien Nocera bnocera@redhat.com wrote:
On Thu, 2008-03-13 at 11:02 -0400, Dimi Paun wrote:
Folks,
As some of you might remember, I have experienced hell with Fedora sound ever since, well, FC3 or maybe earlier. Every time I complained, I was told to file bug reports, which I did, and nothing much was done about it.
I am an old time Linux user & hacker, been using Linux since 1996. It's now 2008, we're about to release F9, and sound is still a big mess. This is not about filing bug reports, it's a systemic problem that must be addressed.
The long and short of it is that sound works sometimes, and then stops working. It just does. Maybe from an update, but it just stops working. Then you start fscking around with all sort of settings, and _maybe_ you get it working again. Maybe not.
But every time there is any change or you reboot the system, it is a Russian roulette if the sound will still work. It is believably f-r-u-s-t-r-a-t-i-n-g.
For example today: sound stopped working 2 days ago through my regular speakers (the USB headphones always work!). This morning there was another big pile of updates, so I decided to reboot the system, maybe that would fix it. 2h(!) later, I have no sound, and instead of working, I'm writing a long message to fedora-devel :)
Cause: pulseaudio refuses to make use of the built-in (Intel) sound card. And I can't figure out how to force it! BTW: I use Gnome, I have ESD checked (that's an obvious label!) so pulseaudio is enabled.
It will just use the USB headphones. If I use Rhythmbox, it uses the default desktop output, and that goes to my USB headphones.
Audacious on the other hand, behaves like this:
- if output is set to ALSA:default, it will go to my headphones
- if output is set to PulseAudio, it will stutter like crazy
That might just be Audacious' plugin sucking as well. Tried with something like Totem or Rhythmbox that uses the (well-tested) GStreamer plugin from PA upstream?
The Audacious default buffer size is 3000 ms. This cause the stuttering while playing mp3 files. Just lowering the buffer size to 300 fixes this issue. This has also been added to the pulseaudio perfect setup page.
On Thu, 2008-03-13 at 18:29 +0000, Bastien Nocera wrote:
Audacious on the other hand, behaves like this:
- if output is set to ALSA:default, it will go to my headphones
- if output is set to PulseAudio, it will stutter like crazy
That might just be Audacious' plugin sucking as well. Tried with something like Totem or Rhythmbox that uses the (well-tested) GStreamer plugin from PA upstream?
Yes, I do. In fact, in desperation I've installed anything pulse I could find out there: [root@dimi ~]# yum list '*pulse*' Installed Packages alsa-plugins-pulseaudio.i386 1.0.15-2.fc8 installed pulseaudio.i386 0.9.8-5.fc8 installed pulseaudio-core-libs.i386 0.9.8-5.fc8 installed pulseaudio-esound-compat.i386 0.9.8-5.fc8 installed pulseaudio-libs.i386 0.9.8-5.fc8 installed pulseaudio-libs-glib2.i386 0.9.8-5.fc8 installed pulseaudio-libs-zeroconf.i386 0.9.8-5.fc8 installed pulseaudio-module-bluetooth.i386 0.9.8-5.fc8 installed pulseaudio-module-gconf.i386 0.9.8-5.fc8 installed pulseaudio-module-jack.i386 0.9.8-5.fc8 installed pulseaudio-module-lirc.i386 0.9.8-5.fc8 installed pulseaudio-module-x11.i386 0.9.8-5.fc8 installed pulseaudio-module-zeroconf.i386 0.9.8-5.fc8 installed pulseaudio-utils.i386 0.9.8-5.fc8 installed
But as I explained, the gstreamer plugin for PA would just output the sound to my USB headphones, not the system speakers.
- if output is set to ALSA:hw:1,0 it will go to the system
speakers
- Is the ALSA Pulseaudio plugin installed?
Yes, see above.
- Did you try selecting another default output in pavucontrol?
(output devices->right-click, select the default, yes the UI sucks)
Funny enough, I didn't know where to get it. It wasn't installed on my system, I installed anything and everything I could find with 'pulse' in name, no luck.
Google, etc, now I discovered that it's in a package called pavucontrol. Really nice name. How could mere mortals figure this one out? The naming leaves a lot to be desired...
- Did you try running pulseaudio by itself on the command-line to see
whether it prints out any errors?
That last one seems like the first thing you should have done before blaming PulseAudio...
Maybe, but hacking pulseaudio on the command line is not something that pops into my mind, I'll admit.
On Thu, 13.03.08 17:11, Dimi Paun (dimi@lattica.com) wrote:
But as I explained, the gstreamer plugin for PA would just output the sound to my USB headphones, not the system speakers.
You can right click on a stream in pavucontrol and move it to another output device. PA will then remember that for the next time.
You can also right click on a device in pavucontrol and make it the default for all future applications.
Google, etc, now I discovered that it's in a package called pavucontrol. Really nice name. How could mere mortals figure this one out? The naming leaves a lot to be desired...
It's installed by default and appears as "PulseAudio Volume Control" in the menus. What more are you asking for? Would a name like "gnome-volume-control-and-default-audio-device-setting-and-stream-to-another-device-moving-program" suit you better? ;-)
Yes, I do admit that having the default device setting stuff and the moving stuff in a volume control is not exactly obvious.
Lennart
On 2008-03-13, 23:10 GMT, Lennart Poettering wrote:
It's installed by default and appears as "PulseAudio Volume Control" in the menus. What more are you asking for?
I would think that calling the package pulseaudio-pavucontrol or something like that would help. The fact that is in comps doesn't help for all those who upgrade with yum (I know, I shouldn't do it and I usually don't, but many people do).
Matej
On Fri, 2008-03-14 at 13:07 +0100, Matej Cepl wrote:
It's installed by default and appears as "PulseAudio Volume Control" in the menus. What more are you asking for?
I would think that calling the package pulseaudio-pavucontrol or something like that would help. The fact that is in comps doesn't help for all those who upgrade with yum (I know, I shouldn't do it and I usually don't, but many people do).
Yes, this is exactly what happened to me -- I upgraded my system (but mind you, via Anaconda, not yum), and none of the PA utilities were installed. Being new to PA, I tried to install everything that's needed, and to find that out, I did:
$ yum list '*pulse*'
That worked well, except for the pa* utilities. Now, without those you are pretty much doomed, and I didn't even know for the longest time that I should have been using them...
On Thu, 2008-03-13 at 17:11 -0400, Dimi Paun wrote:
On Thu, 2008-03-13 at 18:29 +0000, Bastien Nocera wrote:
Audacious on the other hand, behaves like this:
- if output is set to ALSA:default, it will go to my headphones
- if output is set to PulseAudio, it will stutter like crazy
That might just be Audacious' plugin sucking as well. Tried with something like Totem or Rhythmbox that uses the (well-tested) GStreamer plugin from PA upstream?
Yes, I do. In fact, in desperation I've installed anything pulse I could find out there: [root@dimi ~]# yum list '*pulse*' Installed Packages alsa-plugins-pulseaudio.i386 1.0.15-2.fc8 installed pulseaudio.i386 0.9.8-5.fc8 installed pulseaudio-core-libs.i386 0.9.8-5.fc8 installed pulseaudio-esound-compat.i386 0.9.8-5.fc8 installed pulseaudio-libs.i386 0.9.8-5.fc8 installed pulseaudio-libs-glib2.i386 0.9.8-5.fc8 installed pulseaudio-libs-zeroconf.i386 0.9.8-5.fc8 installed pulseaudio-module-bluetooth.i386 0.9.8-5.fc8 installed pulseaudio-module-gconf.i386 0.9.8-5.fc8 installed pulseaudio-module-jack.i386 0.9.8-5.fc8 installed pulseaudio-module-lirc.i386 0.9.8-5.fc8 installed pulseaudio-module-x11.i386 0.9.8-5.fc8 installed pulseaudio-module-zeroconf.i386 0.9.8-5.fc8 installed pulseaudio-utils.i386 0.9.8-5.fc8 installed
But as I explained, the gstreamer plugin for PA would just output the sound to my USB headphones, not the system speakers.
Even after what I mentioned in 2) ?
- if output is set to ALSA:hw:1,0 it will go to the system
speakers
- Is the ALSA Pulseaudio plugin installed?
Yes, see above.
- Did you try selecting another default output in pavucontrol?
(output devices->right-click, select the default, yes the UI sucks)
Funny enough, I didn't know where to get it. It wasn't installed on my system, I installed anything and everything I could find with 'pulse' in name, no luck.
Google, etc, now I discovered that it's in a package called pavucontrol. Really nice name. How could mere mortals figure this one out? The naming leaves a lot to be desired...
You could also just install it, file a bugzilla saying that it should be installed by default, and drop the sarcasm.
- Did you try running pulseaudio by itself on the command-line to see
whether it prints out any errors?
That last one seems like the first thing you should have done before blaming PulseAudio...
Maybe, but hacking pulseaudio on the command line is not something that pops into my mind, I'll admit.
If running applications on the command-line counts as hacking, then there's a lot of apps I hacked on.
I see a lot of ill will, and not much closure. Does it work now, or not?
On Thu, Mar 13, 2008 at 4:25 PM, Bastien Nocera bnocera@redhat.com wrote:
I see a lot of ill will, and not much closure. Does it work now, or not?
My sound still doesn't work, hasn't worked since the update in early January. No ill will here, but did add my pulseaudio -vv to
https://bugzilla.redhat.com/show_bug.cgi?id=428537
darrell
On Thu, 2008-03-13 at 23:25 +0000, Bastien Nocera wrote:
But as I explained, the gstreamer plugin for PA would just output the sound to my USB headphones, not the system speakers.
Even after what I mentioned in 2) ?
Yes, even after you mentioned 2). It's true, I can move the streams individually to the ALSA output, and that seems to work fine (but without Lennart's help, I didn't figure it out, because if you just open pavucontrol there's no stream listed there if no app is playing silently in the background).
I think now PA bound somehow some apps to the USB sink and setting the default doesn't work anymore...
I see a lot of ill will, and not much closure. Does it work now, or not?
It kinda works in that I can go manually redirect each app to ALSA. Far from ideal, but at least I get some sound out.
Thank you.
And no, I have no ill will towards PA. In fact I really appreciate the work Lennart is doing to improve sound. But I am frustrated by what I've been put through with this sound business. Anybody in my place would have been. It'll pass...
On Thu, 2008-03-13 at 23:09 -0400, Dimi Paun wrote:
On Thu, 2008-03-13 at 23:25 +0000, Bastien Nocera wrote:
But as I explained, the gstreamer plugin for PA would just output the sound to my USB headphones, not the system speakers.
Even after what I mentioned in 2) ?
Yes, even after you mentioned 2). It's true, I can move the streams individually to the ALSA output, and that seems to work fine (but without Lennart's help, I didn't figure it out, because if you just open pavucontrol there's no stream listed there if no app is playing silently in the background).
You can also right-click on the output device in the "output device" tab, and select one of those as the default. There's no need to move each stream by hand to another device...
<snip>
And no, I have no ill will towards PA. In fact I really appreciate the work Lennart is doing to improve sound. But I am frustrated by what I've been put through with this sound business. Anybody in my place would have been. It'll pass...
In that case, step away from the computer. Computers frustrate everyone, but there's no point passing your anger onto other people by venting your frustration on a mailing-list. It just brings more bad vibes to the discussion.
Cheers
On Fri, 2008-03-14 at 17:15 +0000, Bastien Nocera wrote:
You can also right-click on the output device in the "output device" tab, and select one of those as the default. There's no need to move each stream by hand to another device...
I know, I tried that (as suggested by you and Lennart), and it doesn't seem to work. I did: * mark ALSA as default * play sound in RhythmBox, sound goes to USB * move RhythmBox stream to ALSA manually, works * play test sound from Sound Preferences applet (set to Autodetect) sound goes to USB * move it manually to ALSA, works
Anyway, I do appreciate the help I received on the issue, now at least I can hear something. Big part of the problem was that the pa* utilities where not present on my box, my yum-based searches for them yielded nothing, and so I sort of had my eyes and hands tied in a way.
In that case, step away from the computer. Computers frustrate everyone,
This misses the point I think. It's not like I exploded out of nothing, as I explained, for the last 3 years sound on my fedora based boxes was on and off every few days. That's extreme.
And most importantly, we haven't reached any conclusion on why my stable F8 setup got suddenly broken. And no, this time around it wasn't the kernel, or ALSA, or SELinux. Things just stopped working on a stable and mature (by Fedora's standards) version.
This is a big problem for Fedora: my wife (a non-technical user), runs Fedora on her ThinkPad X60. A few days ago she applies some updates, and reboots. She calls me really upset that nothing seemed to work: she no longer had a window manager! Yes, metacity did not start all of a sudden, for unknown reason.
Now, I hope you can appreciate what a non-technical user feels when there's no window manager all of a sudden. Nothing works! File a bug? How? This is close to having a kernel that doesn't boot all of a sudden. After much googling, she figure out that she had to manually start metacity from the command line, then do I-don't-know-what for it to start next reboot. Why? Is this normal to expect on a stable Fedora release?!?
And to top it off, her beloved Desktop Effects no longer work. I asked her to file a bug report, but she didn't really wanted because when she did that in the past nothing came out of it, and she felt people were a tad mean to her...
Dimi Paun wrote:
pa* utilities where not present on my box, my yum-based searches for them yielded nothing
In case someone is having trouble with that in the future: yum search pulse or pirut|search|pulse|search
both give the list of pulseaudio apps, including pavucontrol.
But it would be interesting to know what one may have searched for and not found it - perhaps there is improvements that can be made to a glossary on the wiki or search improvement that could be made to yum ?
DaveT.
On Sun, 2008-03-16 at 00:20 +1100, David Timms wrote:
But it would be interesting to know what one may have searched for and not found it - perhaps there is improvements that can be made to a glossary on the wiki or search improvement that could be made to yum ?
As I explained, that was partly my problem, I didn't use yum search, but rather: yum list '*pulse*'
The reason being is that it seemed to me that I managed to find all pulse-related packages this way, and so I assumed there where no other (all plugins and what not have pulse somewhere in the name).
I think that they should have been installed by anaconda on upgrade, if you don't know about them, you are lost with PA without them. Something went wrong along the way, but it's been a while since I moved to F8 (I upgraded right after the release), so I don't think I remember all the details correctly.
On Sun, 2008-03-16 at 00:20 +1100, David Timms wrote:
Dimi Paun wrote:
pa* utilities where not present on my box, my yum-based searches for them yielded nothing
In case someone is having trouble with that in the future: yum search pulse or pirut|search|pulse|search
both give the list of pulseaudio apps, including pavucontrol.
But it would be interesting to know what one may have searched for and not found it - perhaps there is improvements that can be made to a glossary on the wiki or search improvement that could be made to yum ?
So while it's _there_ if you search for pulse, the last thing starting with pulse yum outputs is called "pulseaudio-utils" which I'd kind to expect it in, and even if you look further you have to look over php-pear-Image-Graph and see that pavumeter is PA related too.
Maybe it'll help a bit when yum-3.2.13 comes out and and it has explicit sections for multiple search terms, so people get used to looking for those.
On Thu, 13.03.08 18:29, Bastien Nocera (bnocera@redhat.com) wrote:
It will just use the USB headphones. If I use Rhythmbox, it uses the default desktop output, and that goes to my USB headphones.
Audacious on the other hand, behaves like this:
- if output is set to ALSA:default, it will go to my headphones
- if output is set to PulseAudio, it will stutter like crazy
That might just be Audacious' plugin sucking as well. Tried with something like Totem or Rhythmbox that uses the (well-tested) GStreamer plugin from PA upstream?
Yes, Audacious PA support is totall borked. They took my totally bug-free (really! ;-)) xmms-pulse plugin and borked it.
Lennart
On Thu, 13.03.08 11:02, Dimi Paun (dimi@lattica.com) wrote:
Hi!
I am an old time Linux user & hacker, been using Linux since 1996. It's now 2008, we're about to release F9, and sound is still a big mess. This is not about filing
Yes, it is a big mess. I am being payed for fixing this. And I am working on it.
Cause: pulseaudio refuses to make use of the built-in (Intel) sound card. And I can't figure out how to force it!
Please provide me with the output of of "pulseaudio -vv"
This sounds a lot like that you have some remaining alsa config lines in /etc/modprobe.conf which assigns a fixed ALSA sound card index to your internal soundcard, while your USB card gets a dynamically one. Now, since the driver initialization order is not determenistic these days, sometimes your USB driver might initialize before the internal sound card driver. And picks the first available index. Which coincidentally is the same index the internal driver was configured to -- and when it loads it cannot get that idea.
If my guess is true, than this is totally unrelated to PA, it's a ALSA config issue.
To fix it, just remove all audio related lines from /etc/modprobe.conf. In the lates Fedora release those lines should not be written anymore.
Lennart
On Thu, 2008-03-13 at 22:43 +0100, Lennart Poettering wrote:
On Thu, 13.03.08 11:02, Dimi Paun (dimi@lattica.com) wrote:
If my guess is true, than this is totally unrelated to PA, it's a ALSA config issue.
To fix it, just remove all audio related lines from /etc/modprobe.conf. In the lates Fedora release those lines should not be written anymore.
So, should I see this in modprobe.conf (using f8)?
alias snd-card-0 snd-intel8x0 options snd-card-0 index=0 options snd-intel8x0 index=0
R
On Fri, 14.03.08 09:18, Rodd Clarkson (rodd@clarkson.id.au) wrote:
On Thu, 2008-03-13 at 22:43 +0100, Lennart Poettering wrote:
On Thu, 13.03.08 11:02, Dimi Paun (dimi@lattica.com) wrote:
If my guess is true, than this is totally unrelated to PA, it's a ALSA config issue.
To fix it, just remove all audio related lines from /etc/modprobe.conf. In the lates Fedora release those lines should not be written anymore.
So, should I see this in modprobe.conf (using f8)?
alias snd-card-0 snd-intel8x0 options snd-card-0 index=0 options snd-intel8x0 index=0
No, you should remove all those three lines. They are evil. Break hotplug as mentioned.
Lennart
On Thu, 2008-03-13 at 23:31 +0100, Lennart Poettering wrote:
On Fri, 14.03.08 09:18, Rodd Clarkson (rodd@clarkson.id.au) wrote:
alias snd-card-0 snd-intel8x0 options snd-card-0 index=0 options snd-intel8x0 index=0
No, you should remove all those three lines. They are evil. Break hotplug as mentioned.
Bad, naughty, system-config-soundcard. Its "Restore Configuration Files" adds such lines to /etc/modprobe.conf.
Filed as: https://bugzilla.redhat.com/show_bug.cgi?id=437425
Unfortunately, this is probably the first utility long-term Fedora users will turn to if they have an audio problem.
Regards,
kev.
On Thu, Mar 13, 2008 at 9:02 AM, Dimi Paun dimi@lattica.com wrote:
Folks,
As some of you might remember, I have experienced hell with Fedora sound ever since, well, FC3 or maybe earlier. Every time I complained, I was told to file bug reports, which I did, and nothing much was done about it.
Just to let you know what has been working for, as I have almost zero sound related issues:
Sound Blaster Live + KDE artsd. I can play music, watch tv (via mythtv) and see a video in flash all at the same time.
On Thu, Mar 13, 2008 at 11:28 PM, Arthur Pemberton pemboa@gmail.com wrote:
On Thu, Mar 13, 2008 at 9:02 AM, Dimi Paun dimi@lattica.com wrote:
Folks,
As some of you might remember, I have experienced hell with Fedora sound ever since, well, FC3 or maybe earlier. Every time I complained, I was told to file bug reports, which I did, and nothing much was done about it.
Just to let you know what has been working for, as I have almost zero sound related issues:
Sound Blaster Live + KDE artsd. I can play music, watch tv (via mythtv) and see a video in flash all at the same time.
soundblaster live with emu10k1 was always the best supported card in linux for me. it also doesent use the software mixing crap but has a real hardware mixer. if you are lucky you still get one of those emu10k1 cards on ebay for 1 or 2 euros ;) otherwise you probably have to deal with ac97 crap.
kind regards, Rudolf Kastl
-- Fedora 7 : sipping some of that moonshine ( www.pembo13.com )
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Rudolf Kastl wrote:
On Thu, Mar 13, 2008 at 11:28 PM, Arthur Pemberton pemboa@gmail.com wrote:
On Thu, Mar 13, 2008 at 9:02 AM, Dimi Paun dimi@lattica.com wrote:
Folks,
As some of you might remember, I have experienced hell with Fedora sound ever since, well, FC3 or maybe earlier. Every time I complained, I was told to file bug reports, which I did, and nothing much was done about it.
Just to let you know what has been working for, as I have almost zero sound related issues:
Sound Blaster Live + KDE artsd. I can play music, watch tv (via mythtv) and see a video in flash all at the same time.
soundblaster live with emu10k1 was always the best supported card in linux for me. it also doesent use the software mixing crap but has a real hardware mixer. if you are lucky you still get one of those emu10k1 cards on ebay for 1 or 2 euros ;) otherwise you probably have to deal with ac97 crap.
I love my SB Audigy Gamer; it is very well supported by emu10k1. The first generation Audigy cards at least can be used with great success.
On 2008-03-13, 15:02 GMT, Dimi Paun wrote:
Cause: pulseaudio refuses to make use of the built-in (Intel) sound card. And I can't figure out how to force it! BTW: I use Gnome, I have ESD checked (that's an obvious label!) so pulseaudio is enabled.
The one thing which makes me really mad is a bug (which again haven't to find, but it was filed) that ConsoleKit (or PulseAudio, or Hal, or whichever *Kit is responsible for it) messes my ACLs so normal user cannot write to the sound device. Usually Ctrl+Alt+F1,Alt+F7 makes sound working, but this was addmitted as a bug by davidz almost three months ago, and since then NOTHING happened on this front.
Matej
On Fri, 2008-03-14 at 13:02 +0100, Matej Cepl wrote:
On 2008-03-13, 15:02 GMT, Dimi Paun wrote:
Cause: pulseaudio refuses to make use of the built-in (Intel) sound card. And I can't figure out how to force it! BTW: I use Gnome, I have ESD checked (that's an obvious label!) so pulseaudio is enabled.
The one thing which makes me really mad is a bug (which again haven't to find, but it was filed) that ConsoleKit (or PulseAudio, or Hal, or whichever *Kit is responsible for it) messes my ACLs so normal user cannot write to the sound device. Usually Ctrl+Alt+F1,Alt+F7 makes sound working, but this was addmitted as a bug by davidz almost three months ago, and since then NOTHING happened on this front.
Not true. The bug has been analyzed, tracked down and fixed in rawhide, and I believe F8 updates should be in -testing, at least.
Matthias Clasen wrote:
On Fri, 2008-03-14 at 13:02 +0100, Matej Cepl wrote:
On 2008-03-13, 15:02 GMT, Dimi Paun wrote:
Cause: pulseaudio refuses to make use of the built-in (Intel) sound card. And I can't figure out how to force it! BTW: I use Gnome, I have ESD checked (that's an obvious label!) so pulseaudio is enabled.
The one thing which makes me really mad is a bug (which again haven't to find, but it was filed) that ConsoleKit (or PulseAudio, or Hal, or whichever *Kit is responsible for it) messes my ACLs so normal user cannot write to the sound device. Usually Ctrl+Alt+F1,Alt+F7 makes sound working, but this was addmitted as a bug by davidz almost three months ago, and since then NOTHING happened on this front.
Not true. The bug has been analyzed, tracked down and fixed in rawhide, and I believe F8 updates should be in -testing, at least.
Well, then the person fixing this has failed to mention so in the many bugs about this, quoting the list from Matej: bugs 332781, 401951, 432399, 432956, 428032, 401951 for example
So its great that this has been fixed! But communicating this to our end users so far has not been done properly (bugzilla is one of the proper channels to communicate with, we ask that of our users, we should do the same). This makes us look bad, while in reality we are big hero's (as we've fixed it).
Regards,
Hans
On 2008-03-14, 12:34 GMT, Matthias Clasen wrote:
Not true. The bug has been analyzed, tracked down and fixed in rawhide, and I believe F8 updates should be in -testing, at least.
I have reproduced it this morning with yesterday evening's F8/updates-testing installed. Will check tonight again.
Matej
On Fri, 2008-03-14 at 18:38 +0100, Matej Cepl wrote:
On 2008-03-14, 12:34 GMT, Matthias Clasen wrote:
Not true. The bug has been analyzed, tracked down and fixed in rawhide, and I believe F8 updates should be in -testing, at least.
I have reproduced it this morning with yesterday evening's F8/updates-testing installed. Will check tonight again.
https://admin.fedoraproject.org/updates/F8/FEDORA-2008-2246
is the update that is supposed to fix the hal acl issues.
2008/3/13, Dimi Paun dimi@lattica.com:
Folks,
As some of you might remember, I have experienced hell with Fedora sound ever since, well, FC3 or maybe earlier. Every time I complained, I was told to file bug reports, which I did, and nothing much was done about it.
Recipe of fully working Linux audio system:
* Disable selinux * Disable *all* useless audio-related crap like arts/esound/pulseaudio and so on (ALSA is good and mature solution for mixing audio streams). * Unmute all channels and set appropriate volume levels to 100% * Plug you computer to every cheap sound amplifier (Kenwood KAF-1030 in my case, costs ~150$) equipped with good loudspeaker (very important part of any good audio setup).
Enjoy of total audio control with remote control or with comfortable handle on amp! Forget about mess with audio setup in every popular operating system (Mac OS X/Windoze/Linux).
Peter Lemenkov wrote:
Recipe of fully working Linux audio system:
- Disable selinux
- Disable *all* useless audio-related crap like arts/esound/pulseaudio
neither are required. I've never seen an issue in a fedora's 3-8 in relation to sound on my PC's. I might not update daily, but more than weekly for sure, and mp3, flac, wav, dvb-mpg, dvd etc have continued to work. I'd be less sure about my nvidia cards s-video output, which I do have trouble with.
and so on (ALSA is good and mature solution for mixing audio streams).
I can't think of any manual thing that I needed to do with PA for that to work; in fact I was pleasantly surprised it does work, whereas the previous alsa based way didn't {on my hardware}.
- Unmute all channels and set appropriate volume levels to 100%
Many modern sound cards digital attenuators actually have gain as well. To avoid distorting digitized sound that uses the full digital scale, you may need to limit the wave input fader to 80, 70 {for mine} or even 50%. There are pulse audio settings that I think can limit / scale the volume slider to only set the chips attenuator to unity gain.
- Plug you computer to every cheap sound amplifier (Kenwood KAF-1030
in my case, costs ~150$) equipped with good loudspeaker (very important part of any good audio setup).
Enjoy of total audio control with remote control or with comfortable handle on amp!
Don't forget the Marantz serial RS232 controlled surround/multiroom amps with heaps of inputs - and build some control of its switching and level control into an app for linux [*]
DaveT.
[*] to be started!