10:02 a.m.
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?
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
11:08 a.m.
On Thu, Mar 13, 2008 at 9:00 AM, Lubomir Kundrak <lkundrak(a)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
11:23 a.m.
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.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
11:36 a.m.
On Thu, Mar 13, 2008 at 9:23 AM, Dimi Paun <dimi(a)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
--
Tom London
12:19 p.m.
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.
5:51 p.m.
On Thu, 13.03.08 12:19, Callum Lerwick (seg(a)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
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
6:32 p.m.
On Thu, Mar 13, 2008 at 3:51 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
On Thu, 13.03.08 12:19, Callum Lerwick (seg(a)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
--
Tom London
11:27 a.m.
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.
7:57 p.m.
On Fri, 14.03.08 12:27, Colin Walters (walters(a)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
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
8:02 p.m.
On Tue, Mar 25, 2008 at 8:57 PM, Lennart Poettering
<mzerqung(a)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.
8:11 p.m.
On Tue, 25.03.08 21:02, Colin Walters (walters(a)verbum.org) wrote:
On Tue, Mar 25, 2008 at 8:57 PM, Lennart Poettering
<mzerqung(a)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
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
8:17 p.m.
On Tue, Mar 25, 2008 at 9:11 PM, Lennart Poettering
<mzerqung(a)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
10:52 p.m.
Colin Walters (walters(a)verbum.org) said:
> 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
Wait, why can't this socket be abstract? Why do you need a dir?
Bill
7:53 a.m.
On Wed, Mar 26, 2008 at 8:36 AM, Colin Walters <walters(a)verbum.org> wrote:
On Tue, Mar 25, 2008 at 11:52 PM, Bill Nottingham
<notting(a)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)
8:04 p.m.
On Wed, 2008-03-26 at 01:57 +0100, Lennart Poettering wrote:
On Fri, 14.03.08 12:27, Colin Walters (walters(a)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
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
8:13 p.m.
On Wed, 26.03.08 12:04, Andrew Bartlett (abartlet(a)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
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
12:26 a.m.
On Wed, 2008-03-26 at 02:13 +0100, Lennart Poettering wrote:
On Wed, 26.03.08 12:04, Andrew Bartlett (abartlet(a)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
2:06 p.m.
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
12:30 p.m.
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
3:11 a.m.
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 (Red Hat Security Response Team)
7:45 a.m.
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?
--
Les Mikesell
lesmikesel(a)gmail.com
7:14 a.m.
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
11:01 a.m.
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.
1:29 p.m.
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...
1:38 p.m.
On Thu, Mar 13, 2008 at 3:29 PM, Bastien Nocera <bnocera(a)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.
--
Paulo Roma Cavalcanti
LCG - UFRJ
4:11 p.m.
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
1) Is the ALSA Pulseaudio plugin installed?
Yes, see above.
2) 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...
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...
Maybe, but hacking pulseaudio on the command line is not something
that pops into my mind, I'll admit.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
6:10 p.m.
On Thu, 13.03.08 17:11, Dimi Paun (dimi(a)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
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
7:07 a.m.
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
10:38 a.m.
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...
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
6:25 p.m.
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
>
> 1) Is the ALSA Pulseaudio plugin installed?
Yes, see above.
> 2) 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.
> 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...
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?
6:39 p.m.
On Thu, Mar 13, 2008 at 4:25 PM, Bastien Nocera <bnocera(a)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
10:09 p.m.
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...
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
12:15 p.m.
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
12:41 p.m.
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 <dimi(a)lattica.com>
Lattica, Inc.
8:20 a.m.
New subject: Fedora found Pulseaudio
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.
10:30 a.m.
New subject: Fedora found Pulseaudio
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.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
9:57 p.m.
New subject: Fedora found Pulseaudio
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.
--
James Antill <james(a)fedoraproject.com>
Fedora
5:54 p.m.
On Thu, 13.03.08 18:29, Bastien Nocera (bnocera(a)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
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
4:43 p.m.
On Thu, 13.03.08 11:02, Dimi Paun (dimi(a)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
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
5:18 p.m.
On Thu, 2008-03-13 at 22:43 +0100, Lennart Poettering wrote:
On Thu, 13.03.08 11:02, Dimi Paun (dimi(a)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
--
"It's a fine line between denial and faith.
It's much better on my side"
5:31 p.m.
On Fri, 14.03.08 09:18, Rodd Clarkson (rodd(a)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(a)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
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
7:18 p.m.
On Thu, 2008-03-13 at 23:31 +0100, Lennart Poettering wrote:
On Fri, 14.03.08 09:18, Rodd Clarkson (rodd(a)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.
5:28 p.m.
On Thu, Mar 13, 2008 at 9:02 AM, Dimi Paun <dimi(a)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.
--
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )
8:46 a.m.
On Thu, Mar 13, 2008 at 11:28 PM, Arthur Pemberton <pemboa(a)gmail.com> wrote:
On Thu, Mar 13, 2008 at 9:02 AM, Dimi Paun <dimi(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
2:51 a.m.
Rudolf Kastl wrote:
On Thu, Mar 13, 2008 at 11:28 PM, Arthur Pemberton
<pemboa(a)gmail.com> wrote:
> On Thu, Mar 13, 2008 at 9:02 AM, Dimi Paun <dimi(a)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.
--
Andrew Farris <lordmorgul(a)gmail.com> www.lordmorgul.net
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
7:02 a.m.
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
7:34 a.m.
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.
7:34 a.m.
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
12:38 p.m.
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
12:58 p.m.
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.
8:11 a.m.
2008/3/13, Dimi Paun <dimi(a)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).
--
With best regards!
9:13 a.m.
New subject: Fedora sound tips
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!
5936
days inactive
5949
days old
54 comments
29 participants
participants (29)
-
"Jóhann B. Guðmundsson" -
Andrew Bartlett -
Andrew Farris -
Arthur Pemberton -
Bastien Nocera -
Bill Nottingham -
Callum Lerwick -
Colin Walters -
Colin Walters -
Dan Williams -
darrell pfeifer -
Development discussions related to Fedora -
Dimi Paun -
Hans de Goede -
James Antill -
Kevin Page -
Lennart Poettering -
Les Mikesell -
Lubomir Kundrak -
Matej Cepl -
Matthias Clasen -
Michael Schwendt -
Paulo Cavalcanti -
Peter Lemenkov -
Ralf Ertzinger -
Rodd Clarkson -
Rudolf Kastl -
Suren Karapetyan -
Tom London