11:29 p.m.
So, the shiny new pulseaudio mixer setup in F11 took away my ability to
tell the panel applet which channel to use. It seems to insist on
messing with the master. I have a second computer hooked in to the line
in, so it can share speakers with my main box. I had it set up so the
master volume was set on maximum, and the panel volume thingy adjusted
the PCM volume. This allowed me to adjust volumes separately, the
secondary box stayed at a constant volume and the main box could be
adjusted freely without affecting the secondary machine.
How do I get this behavior back?
(Someday I'll just get me a proper studio mixer. Sigh...)
4:22 a.m.
I thought the panel applet was supposed to disappear in Fedora 11? Ardour is
a good studio mixer system, even though it also does professional level
audio editing.
On Mon, Apr 20, 2009 at 11:29 PM, Callum Lerwick <seg(a)haxxed.com> wrote:
So, the shiny new pulseaudio mixer setup in F11 took away my ability
to
tell the panel applet which channel to use. It seems to insist on
messing with the master. I have a second computer hooked in to the line
in, so it can share speakers with my main box. I had it set up so the
master volume was set on maximum, and the panel volume thingy adjusted
the PCM volume. This allowed me to adjust volumes separately, the
secondary box stayed at a constant volume and the main box could be
adjusted freely without affecting the secondary machine.
How do I get this behavior back?
(Someday I'll just get me a proper studio mixer. Sigh...)
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
7:50 a.m.
On Mon, 2009-04-20 at 23:29 -0500, Callum Lerwick wrote:
So, the shiny new pulseaudio mixer setup in F11 took away my ability
to
tell the panel applet which channel to use. It seems to insist on
messing with the master. I have a second computer hooked in to the line
in, so it can share speakers with my main box. I had it set up so the
master volume was set on maximum, and the panel volume thingy adjusted
the PCM volume. This allowed me to adjust volumes separately, the
secondary box stayed at a constant volume and the main box could be
adjusted freely without affecting the secondary machine.
How do I get this behavior back?
_This_ behaviour, no. Any reasons why you don't use PulseAudio over the
network instead?
I'm afraid that your use of the volume control wasn't really something
we thought about, and I'm not sure that's a use case we're that
interested in catering for.
(Someday I'll just get me a proper studio mixer. Sigh...)
Cheers
11:37 a.m.
2009/4/21 Bastien Nocera <bnocera(a)redhat.com>:
On Mon, 2009-04-20 at 23:29 -0500, Callum Lerwick wrote:
> So, the shiny new pulseaudio mixer setup in F11 took away my ability to
> tell the panel applet which channel to use. It seems to insist on
> messing with the master. I have a second computer hooked in to the line
> in, so it can share speakers with my main box. I had it set up so the
> master volume was set on maximum, and the panel volume thingy adjusted
> the PCM volume. This allowed me to adjust volumes separately, the
> secondary box stayed at a constant volume and the main box could be
> adjusted freely without affecting the secondary machine.
>
> How do I get this behavior back?
_This_ behaviour, no. Any reasons why you don't use PulseAudio over the
network instead?
I'm afraid that your use of the volume control wasn't really something
we thought about, and I'm not sure that's a use case we're that
interested in catering for.
> (Someday I'll just get me a proper studio mixer. Sigh...)
Cheers
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Couldn't he also just use Pulseaudio to route the incoming sound from
his line input to the output, also allowing him to adjust the volume
separately and all?
This could be an option, if for example there is no fast network
between the computers.
--
Joonas Sarajärvi
muepsj(a)gmail.com
1:13 p.m.
On Tue, April 21, 2009 6:50 am, Bastien Nocera wrote:
On Mon, 2009-04-20 at 23:29 -0500, Callum Lerwick wrote:
> So, the shiny new pulseaudio mixer setup in F11 took away my ability to
> tell the panel applet which channel to use. It seems to insist on
> messing with the master. I have a second computer hooked in to the line
> in, so it can share speakers with my main box. I had it set up so the
> master volume was set on maximum, and the panel volume thingy adjusted
> the PCM volume. This allowed me to adjust volumes separately, the
> secondary box stayed at a constant volume and the main box could be
> adjusted freely without affecting the secondary machine.
>
> How do I get this behavior back?
_This_ behaviour, no. Any reasons why you don't use PulseAudio over the
network instead?
I'm afraid that your use of the volume control wasn't really something
we thought about, and I'm not sure that's a use case we're that
interested in catering for.
I think I also rely on this use-case (i.e. telling the mixer which
channel(s) to control).
I forget the exact names, but my laptop has separate volume controls for
the built-in bass and non-bass speakers. In older Fedora releases, this
"just worked". In F9 (I think), the mixer (and volume buttons on the front
of the laptop) started to control only the non-bass speaker volume, so
that the bass volume was always maxed out, which wasn't usable. I had to
configure the mixer to control both the bass and non-bass mixer channels
together (and I think I had to hack the alsa configuration to actually
create the bass mixer channel at all, or something like that)
So, is this all handled in a better (i.e. automatic) fashion now, or is
the lack of channel selection going to be another regression for me?
4:29 p.m.
On Tue, 2009-04-21 at 12:13 -0600, Stephen Warren wrote:
On Tue, April 21, 2009 6:50 am, Bastien Nocera wrote:
> On Mon, 2009-04-20 at 23:29 -0500, Callum Lerwick wrote:
>> So, the shiny new pulseaudio mixer setup in F11 took away my ability to
>> tell the panel applet which channel to use. It seems to insist on
>> messing with the master. I have a second computer hooked in to the line
>> in, so it can share speakers with my main box. I had it set up so the
>> master volume was set on maximum, and the panel volume thingy adjusted
>> the PCM volume. This allowed me to adjust volumes separately, the
>> secondary box stayed at a constant volume and the main box could be
>> adjusted freely without affecting the secondary machine.
>>
>> How do I get this behavior back?
>
> _This_ behaviour, no. Any reasons why you don't use PulseAudio over the
> network instead?
>
> I'm afraid that your use of the volume control wasn't really something
> we thought about, and I'm not sure that's a use case we're that
> interested in catering for.
I think I also rely on this use-case (i.e. telling the mixer which
channel(s) to control).
No, you don't rely on this use-case. You rely on the same work-around.
I forget the exact names, but my laptop has separate volume controls
for
the built-in bass and non-bass speakers. In older Fedora releases, this
"just worked". In F9 (I think), the mixer (and volume buttons on the front
of the laptop) started to control only the non-bass speaker volume, so
that the bass volume was always maxed out, which wasn't usable. I had to
configure the mixer to control both the bass and non-bass mixer channels
together (and I think I had to hack the alsa configuration to actually
create the bass mixer channel at all, or something like that)
So, is this all handled in a better (i.e. automatic) fashion now, or is
the lack of channel selection going to be another regression for me?
If both mixers should be handled as one, then it should be PulseAudio or
ALSA making that connection between the mixer tracks.
File a bug against PulseAudio with the output of "amixer -c0", the names
of the tracks that should be handled together, and the name of your
sound driver. I'm pretty sure this can be fixed without resorting to a
work-around.
1:22 p.m.
On Tue, 2009-04-21 at 13:50 +0100, Bastien Nocera wrote:
On Mon, 2009-04-20 at 23:29 -0500, Callum Lerwick wrote:
> So, the shiny new pulseaudio mixer setup in F11 took away my ability to
> tell the panel applet which channel to use. It seems to insist on
> messing with the master. I have a second computer hooked in to the line
> in, so it can share speakers with my main box. I had it set up so the
> master volume was set on maximum, and the panel volume thingy adjusted
> the PCM volume. This allowed me to adjust volumes separately, the
> secondary box stayed at a constant volume and the main box could be
> adjusted freely without affecting the secondary machine.
>
> How do I get this behavior back?
_This_ behaviour, no. Any reasons why you don't use PulseAudio over the
network instead?
Because this is simpler. And the secondary box is running Windows XP.
If anything is there some way I can just have an option to get the old
damn panel applet back?
Seems like yet another case of ripping out a stable solution and
replacing it with a new, shiny and immature one that fails to provide
similar functionality. Can I at least get a secret gconf key to do what
I want? :P
4:26 p.m.
On Tue, 2009-04-21 at 13:22 -0500, Callum Lerwick wrote:
On Tue, 2009-04-21 at 13:50 +0100, Bastien Nocera wrote:
> On Mon, 2009-04-20 at 23:29 -0500, Callum Lerwick wrote:
> > So, the shiny new pulseaudio mixer setup in F11 took away my ability to
> > tell the panel applet which channel to use. It seems to insist on
> > messing with the master. I have a second computer hooked in to the line
> > in, so it can share speakers with my main box. I had it set up so the
> > master volume was set on maximum, and the panel volume thingy adjusted
> > the PCM volume. This allowed me to adjust volumes separately, the
> > secondary box stayed at a constant volume and the main box could be
> > adjusted freely without affecting the secondary machine.
> >
> > How do I get this behavior back?
>
> _This_ behaviour, no. Any reasons why you don't use PulseAudio over the
> network instead?
Because this is simpler. And the secondary box is running Windows XP.
If anything is there some way I can just have an option to get the old
damn panel applet back?
I'm pretty sure the interweb provides half-a-gazillion mixer type
applets, but the mixer applet as it were was removed from gnome-applets
upstream.
Seems like yet another case of ripping out a stable solution and
replacing it with a new, shiny and immature one that fails to provide
similar functionality.
You had about a year to complain that the Volume Control feature didn't
include your use case, and given the 0.01% of the population using their
sound system like you do, I doubt it would have crossed our minds that
this could have been the case.
Can I at least get a secret gconf key to do what
I want? :P
The volume control uses PulseAudio, it doesn't use ALSA directly
anymore, so no, there's no secret GConf key for that.
8:10 p.m.
On Tue, 2009-04-21 at 22:26 +0100, Bastien Nocera wrote:
On Tue, 2009-04-21 at 13:22 -0500, Callum Lerwick wrote:
> On Tue, 2009-04-21 at 13:50 +0100, Bastien Nocera wrote:
I'm pretty sure the interweb provides half-a-gazillion mixer type
applets, but the mixer applet as it were was removed from gnome-applets
upstream.
Which is stupid. Deprecate first, then remove only after the new code
has gone through at least one cycle of wide release.
> Seems like yet another case of ripping out a stable solution
and
> replacing it with a new, shiny and immature one that fails to provide
> similar functionality.
You had about a year to complain that the Volume Control feature didn't
include your use case, and given the 0.01% of the population using their
sound system like you do, I doubt it would have crossed our minds that
this could have been the case.
Well I'm sorry, I wasn't able to figure out from an abstract description
and a lot of tl;dr that my use case was going to get screwed. And I
don't have the time to dick around getting my babies eaten following
Rawhide on my critical primary desktop machine. As a personal policy
from experience I don't touch rawhide until Beta. I have Shit To Do that
doesn't include being a damned alpha tester. And even so I'm lucky if I
can even get !@#$ing Beta to install before final release.
I've spent many weeks and many long annoying reboot cycles interrupting
my Shit To Do, filing bugs trying to get preupgrade to even work:
https://bugzilla.redhat.com/show_bug.cgi?id=493685
https://bugzilla.redhat.com/show_bug.cgi?id=494992
https://bugzilla.redhat.com/show_bug.cgi?id=496406
I finally just temporally stripped my fstab bare so I could get the
damned thing to install. Once upgraded, I had to screw around trying to
figure out why Pulseaudio was doing nothing but spin in place, eating
100% CPU, getting killed off by the CPU limiter, respawning, and
repeating. Which seemed to magically fix itself after updating to the
Feb 20th rawhide.
Which brings me to now. Fedora 11 isn't even released yet. So don't give
me any bullshit about not being proactive about testing. Pulseaudio
isn't the only broken crap in Fedora.
> Can I at least get a secret gconf key to do what
> I want? :P
The volume control uses PulseAudio, it doesn't use ALSA directly
anymore, so no, there's no secret GConf key for that.
So a PulseAudio config option then. Do I have to write the patch myself?
And why do Pidgin alert sounds explode my speakers now? Yeah pump the
hardware volume up to 100%, that's great... Why does Pidgin still not
have native Pulseaudio support? I set it to use paplay because in the
past Pidgin would leak PA connections and RAM like crazy and choke the
machine dead any other way. This "flat volume" thing now seems to mean
short alert tones will cause obnoxious volume glitching if they happen
to be louder than my music.
5:44 a.m.
On Tue, 2009-04-21 at 20:10 -0500, Callum Lerwick wrote:
On Tue, 2009-04-21 at 22:26 +0100, Bastien Nocera wrote:
> On Tue, 2009-04-21 at 13:22 -0500, Callum Lerwick wrote:
> > On Tue, 2009-04-21 at 13:50 +0100, Bastien Nocera wrote:
> I'm pretty sure the interweb provides half-a-gazillion mixer type
> applets, but the mixer applet as it were was removed from gnome-applets
> upstream.
Which is stupid. Deprecate first, then remove only after the new code
has gone through at least one cycle of wide release.
Thanks, love you too.
And ship two apps with that do the same thing in the desktop? What a
great way to confuse things further.
> > Seems like yet another case of ripping out a stable
solution and
> > replacing it with a new, shiny and immature one that fails to provide
> > similar functionality.
>
> You had about a year to complain that the Volume Control feature didn't
> include your use case, and given the 0.01% of the population using their
> sound system like you do, I doubt it would have crossed our minds that
> this could have been the case.
<snip>
Which brings me to now. Fedora 11 isn't even released yet. So
don't give
me any bullshit about not being proactive about testing. Pulseaudio
isn't the only broken crap in Fedora.
I meant the volume control feature on the Fedora wiki. It's been there
for a year. Sure you can ignore it. But then you're going to complain
when it breaks things for you.
> > Can I at least get a secret gconf key to do what
> > I want? :P
>
> The volume control uses PulseAudio, it doesn't use ALSA directly
> anymore, so no, there's no secret GConf key for that.
So a PulseAudio config option then. Do I have to write the patch myself?
Probably not a PA config option either.
The volume control applet will show a mixer for input devices if an
application is recording on it. You'd just need to make the mixer think
that something is recording on that device. I'm not sure how to do that,
but Lennart might.
And why do Pidgin alert sounds explode my speakers now? Yeah pump
the
hardware volume up to 100%, that's great... Why does Pidgin still not
have native Pulseaudio support? I set it to use paplay because in the
past Pidgin would leak PA connections and RAM like crazy and choke the
machine dead any other way. This "flat volume" thing now seems to mean
short alert tones will cause obnoxious volume glitching if they happen
to be louder than my music.
I don't know what Pidgin uses, but spitting out alert sounds using
paplay is unlikely to work well at all. You need to set the
"PULSE_PROP_media.role=event" envvar before launching paplay. Otherwise
it thinks paplay is a normal, say, music application and will change the
volumes.
That's a good use of your patch action: port Pidgin to use libcanberra.
1:44 p.m.
Bastien Nocera wrote:
And ship two apps with that do the same thing in the desktop? What a
great way to confuse things further.
Why not ship one app which uses PulseAudio to set PulseAudio volumes and
ALSA to set ALSA volumes? Hide the ALSA settings by default if you think
users will get confused by them, but provide a way to enable them. (Of
course it's too late for F11, but still, that's the right way to do it.)
Kevin Kofler
3:11 p.m.
On Wed, 2009-04-22 at 20:44 +0200, Kevin Kofler wrote:
Bastien Nocera wrote:
> And ship two apps with that do the same thing in the desktop? What a
> great way to confuse things further.
Why not ship one app which uses PulseAudio to set PulseAudio volumes and
ALSA to set ALSA volumes? Hide the ALSA settings by default if you think
users will get confused by them, but provide a way to enable them. (Of
course it's too late for F11, but still, that's the right way to do it.)
Because ALSA sucks, and I don't want to go another round of working
around crappy ALSA bugs in the 3 different software mixers we have
(that's gnome-settings-daemon's volume keys handling, the applet and the
volume control).
2:51 p.m.
On Wed, 2009-04-22 at 11:44 +0100, Bastien Nocera wrote:
On Tue, 2009-04-21 at 20:10 -0500, Callum Lerwick wrote:
> On Tue, 2009-04-21 at 22:26 +0100, Bastien Nocera wrote:
> > On Tue, 2009-04-21 at 13:22 -0500, Callum Lerwick wrote:
> > > On Tue, 2009-04-21 at 13:50 +0100, Bastien Nocera wrote:
> > I'm pretty sure the interweb provides half-a-gazillion mixer type
> > applets, but the mixer applet as it were was removed from gnome-applets
> > upstream.
>
> Which is stupid. Deprecate first, then remove only after the new code
> has gone through at least one cycle of wide release.
Thanks, love you too.
And ship two apps with that do the same thing in the desktop? What a
great way to confuse things further.
We package duplicates all the time. Doesn't mean it has to be installed
or visible or available by default.
Lets rip out KDE, it just duplicates GNOME and confuses people!
> > > Seems like yet another case of ripping out a stable
solution and
> > > replacing it with a new, shiny and immature one that fails to provide
> > > similar functionality.
> >
> > You had about a year to complain that the Volume Control feature didn't
> > include your use case, and given the 0.01% of the population using their
> > sound system like you do, I doubt it would have crossed our minds that
> > this could have been the case.
<snip>
> Which brings me to now. Fedora 11 isn't even released yet. So don't give
> me any bullshit about not being proactive about testing. Pulseaudio
> isn't the only broken crap in Fedora.
I meant the volume control feature on the Fedora wiki. It's been there
for a year. Sure you can ignore it.
Previously, on fedora-devel:
> Well I'm sorry, I wasn't able to figure out from an
> abstract description and a lot of tl;dr that my use case was going
> to get screwed.
But then you're going to complain when it breaks things for you.
WHAT is so hard to understand about people getting pissed off when you
break their shit, and then dismiss them as some kind of fringe nutjob
when they ask for help?
And when did it become Fedora policy that no one has a right to complain
unless they're an Alpha tester from day 1?
> > > Can I at least get a secret gconf key to do what
> > > I want? :P
> >
> > The volume control uses PulseAudio, it doesn't use ALSA directly
> > anymore, so no, there's no secret GConf key for that.
>
> So a PulseAudio config option then. Do I have to write the patch myself?
Probably not a PA config option either.
The volume control applet will show a mixer for input devices if an
application is recording on it. You'd just need to make the mixer think
that something is recording on that device. I'm not sure how to do that,
but Lennart might.
No, you are misunderstanding. I don't want to adjust the input volume. I
want it left alone. I want the master left alone. Master stays at 0dB,
Line stays at 0dB. I want PA to dink with PCM instead of Master.
The volume of the secondary box is adjusted on the secondary box itself.
Oh gee, what do we have here:
$ grep "prefer Master" ChangeLog
9a4e84a: On recommendation of Takashi Iwai prefer Master volume control over PCM
and don't control Mic control
Let's just reverse that then:
--- pulseaudio-0.9.15/src/modules/alsa/alsa-util.c 2009-04-13 16:11:32.000000000
-0500
+++ pulseaudio-0.9.15.patched/src/modules/alsa/alsa-util.c 2009-04-22
14:23:49.367297597 -0500
@@ -1180,7 +1180,7 @@
else if (profile)
e = pa_alsa_find_elem(m, profile->playback_control_name,
profile->playback_control_fallback, TRUE);
else
- e = pa_alsa_find_elem(m, "Master", "PCM", TRUE);
+ e = pa_alsa_find_elem(m, "PCM", "Master", TRUE);
break;
case SND_PCM_STREAM_CAPTURE:
Suggestion: Make fallback order a config option. You are hardcoding
policy. That's a no-no.
Suggestion: Hardwired for only two options? There's no such thing as
two:
http://c2.com/cgi/wiki?ZeroOneInfinityRule
http://c2.com/cgi/wiki?TwoIsAnImpossibleNumber
I don't know what Pidgin uses, but spitting out alert sounds
using
paplay is unlikely to work well at all.
Why not? Small processes working together is the Unix way. But people
seem to have forgotten that.
Pidgin doesn't exactly have low latency requirements.
You need to set the
"PULSE_PROP_media.role=event" envvar before launching paplay. Otherwise
it thinks paplay is a normal, say, music application and will change the
volumes.
That's a good use of your patch action: port Pidgin to use libcanberra.
How about a command line interface to libcanberra?
Thread dismissed.
3:14 p.m.
On Wed, 2009-04-22 at 14:51 -0500, Callum Lerwick wrote:
<snip>
> I don't know what Pidgin uses, but spitting out alert sounds
using
> paplay is unlikely to work well at all.
Why not? Small processes working together is the Unix way. But people
seem to have forgotten that.
Because paplay doesn't know it's playing a sound event, music, or audio
from a softphone. I also gave the work-around to avoid the change of
volume with flat-volumes enabled.
Pidgin doesn't exactly have low latency requirements.
> You need to set the
> "PULSE_PROP_media.role=event" envvar before launching paplay. Otherwise
> it thinks paplay is a normal, say, music application and will change the
> volumes.
>
> That's a good use of your patch action: port Pidgin to use libcanberra.
How about a command line interface to libcanberra?
PULSE_PROP_media.role=event paplay
3:24 p.m.
On Wed, 2009-04-22 at 21:14 +0100, Bastien Nocera wrote:
On Wed, 2009-04-22 at 14:51 -0500, Callum Lerwick wrote:
<snip>
> > I don't know what Pidgin uses, but spitting out alert sounds using
> > paplay is unlikely to work well at all.
>
> Why not? Small processes working together is the Unix way. But people
> seem to have forgotten that.
Because paplay doesn't know it's playing a sound event, music, or audio
from a softphone. I also gave the work-around to avoid the change of
volume with flat-volumes enabled.
Well then you GIVE it the ability to do so. Are you not a programmer?
Make paplay do this:
paplay --role event alert.wav
And apparently there IS a way to make it work, with the env variables
you keep mentioning.
(... why would paplay be playing audio from a softphone?)
> Pidgin doesn't exactly have low latency requirements.
>
> > You need to set the
> > "PULSE_PROP_media.role=event" envvar before launching paplay.
Otherwise
> > it thinks paplay is a normal, say, music application and will change the
> > volumes.
> >
> > That's a good use of your patch action: port Pidgin to use libcanberra.
>
> How about a command line interface to libcanberra?
PULSE_PROP_media.role=event paplay
3:18 p.m.
On Wed, 2009-04-22 at 14:51 -0500, Callum Lerwick wrote:
Let's just reverse that then:
--- pulseaudio-0.9.15/src/modules/alsa/alsa-util.c 2009-04-13 16:11:32.000000000
-0500
+++ pulseaudio-0.9.15.patched/src/modules/alsa/alsa-util.c 2009-04-22
14:23:49.367297597 -0500
@@ -1180,7 +1180,7 @@
else if (profile)
e = pa_alsa_find_elem(m, profile->playback_control_name,
profile->playback_control_fallback, TRUE);
else
- e = pa_alsa_find_elem(m, "Master", "PCM", TRUE);
+ e = pa_alsa_find_elem(m, "PCM", "Master", TRUE);
break;
case SND_PCM_STREAM_CAPTURE:
Aaaaaaand that doesn't appear to have worked. Grrrrrrrr. I haven't got
any more time for this I have Shit To Do.
(lol STD)
3:36 p.m.
On Wed, 2009-04-22 at 14:51 -0500, Callum Lerwick wrote:
I used to be able to just place my mouse over the icon
and use the scroll wheel. I'm just noticing the shiny new mixer app
doesn't seem to support that either...
Sure it does.
How about a command line interface to libcanberra?
Try canberra-gtk-play.
You are trying too hard to complain, I think...
12:34 p.m.
On Wed, 2009-04-22 at 16:36 -0400, Matthias Clasen wrote:
On Wed, 2009-04-22 at 14:51 -0500, Callum Lerwick wrote:
> I used to be able to just place my mouse over the icon
> and use the scroll wheel. I'm just noticing the shiny new mixer app
> doesn't seem to support that either...
Sure it does.
Well apparently my applet got screwed up somehow. Nuking it and
restarting fixed it.
> How about a command line interface to libcanberra?
Try canberra-gtk-play.
You are trying too hard to complain, I think...
That's in libcanberra-gtk2 so I didn't see it when I looked in the
libcanberra package. Why the hell does it depend on GTK? Why do you need
GTK to just play a frickin' sound?
Bloat.
12:43 p.m.
On Thu, 23.04.09 12:34, Callum Lerwick (seg(a)haxxed.com) wrote:
> > How about a command line interface to libcanberra?
>
> Try canberra-gtk-play.
>
> You are trying too hard to complain, I think...
That's in libcanberra-gtk2 so I didn't see it when I looked in the
libcanberra package. Why the hell does it depend on GTK? Why do you need
GTK to just play a frickin' sound?
Among some other things this tools uses the GtkSettings framework to
find the right sound theme to play sounds, so that it matches the
sounds from the rest of the desktop.
Bloat.
Yes, I love you too. And I love your friendly, constructive and
educated comments. What would I do without these enlightening insights!
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
5:33 p.m.
On Wed, 2009-04-22 at 14:51 -0500, Callum Lerwick wrote:
> > Which is stupid. Deprecate first, then remove only after
the new code
> > has gone through at least one cycle of wide release.
>
> Thanks, love you too.
>
> And ship two apps with that do the same thing in the desktop? What a
> great way to confuse things further.
We package duplicates all the time. Doesn't mean it has to be installed
or visible or available by default.
Lets rip out KDE, it just duplicates GNOME and confuses people!
Well, we do have a couple of GUI mixers which still give you raw access
- the xfce mixer is the most logical fit. But I'd really like to have it
installed by default in this particular case. People will be happy at
not having a GUI mixer with raw access to the hardware channels only if
the shiny new abstracted mixer genuinely covers every case. As is very
clear from this list, the bug report, test-list and fedoraforums, it's
not even close. So I'm going to push very hard to have an alternate GUI
mixer available for F11. The new mixer is obviously the Way Forward, but
at the moment it's two steps forward for most people and a couple of
dozen back for a significant minority.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
5:53 p.m.
On Wed, 2009-04-22 at 15:33 -0700, Adam Williamson wrote:
Well, we do have a couple of GUI mixers which still give you raw access
- the xfce mixer is the most logical fit. But I'd really like to have it
installed by default in this particular case. People will be happy at
not having a GUI mixer with raw access to the hardware channels only if
the shiny new abstracted mixer genuinely covers every case.
You can never cover _every case_, thats an illusion. Creating a usable
ui is to a large part deciding which cases are not worth supporting. You
just can't support everything that is possible by manually twiddling
with alsa internals, unless you just expose all the alsa guts 1-1 in the
ui. We've been there, and we don't want to go back to that.
6 p.m.
On Wed, 2009-04-22 at 18:53 -0400, Matthias Clasen wrote:
On Wed, 2009-04-22 at 15:33 -0700, Adam Williamson wrote:
>
> Well, we do have a couple of GUI mixers which still give you raw access
> - the xfce mixer is the most logical fit. But I'd really like to have it
> installed by default in this particular case. People will be happy at
> not having a GUI mixer with raw access to the hardware channels only if
> the shiny new abstracted mixer genuinely covers every case.
>
You can never cover _every case_, thats an illusion. Creating a usable
ui is to a large part deciding which cases are not worth supporting. You
just can't support everything that is possible by manually twiddling
with alsa internals, unless you just expose all the alsa guts 1-1 in the
ui. We've been there, and we don't want to go back to that.
I know, but we are clearly way too far in the other direction at the
point where the current mixer causes some people not to be able to get
any audible sound at all, and prevents you from selecting an input
channel. These are not bizarre corner cases.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:18 p.m.
On Wed, Apr 22, 2009 at 6:53 PM, Matthias Clasen wrote:
On Wed, 2009-04-22 at 15:33 -0700, Adam Williamson wrote:
>
> Well, we do have a couple of GUI mixers which still give you raw access
> - the xfce mixer is the most logical fit. But I'd really like to have it
> installed by default in this particular case. People will be happy at
> not having a GUI mixer with raw access to the hardware channels only if
> the shiny new abstracted mixer genuinely covers every case.
>
You can never cover _every case_, thats an illusion. Creating a usable
ui is to a large part deciding which cases are not worth supporting. You
just can't support everything that is possible by manually twiddling
with alsa internals, unless you just expose all the alsa guts 1-1 in the
ui. We've been there, and we don't want to go back to that.
What do you mean? Having full control of your soundcard with all the
sliders and stuff is useless?
Not displaying everything 1-1 and hiding sliders is an improvement?
Orcan
7:38 p.m.
On Wed, 2009-04-22 at 19:18 -0400, Orcan Ogetbil wrote:
What do you mean? Having full control of your soundcard with all the
sliders and stuff is useless?
Not displaying everything 1-1 and hiding sliders is an improvement?
Holy hell yes:
http://people.redhat.com/alexl/files/why-alsa-sucks.png
-w
7:46 p.m.
On Wed, 2009-04-22 at 20:38 -0400, Will Woods wrote:
On Wed, 2009-04-22 at 19:18 -0400, Orcan Ogetbil wrote:
> What do you mean? Having full control of your soundcard with all the
> sliders and stuff is useless?
> Not displaying everything 1-1 and hiding sliders is an improvement?
Holy hell yes:
http://people.redhat.com/alexl/files/why-alsa-sucks.png
That's a true screenshot, but that argument is vulnerable to the exact
same 'logic' used to justify not caring about people who need to adjust
a different slider than Master or PCM, or people who want to switch
input channels: it's not a common case. most people don't see that much
of a mess of channels. The "Trident TRID4DWAVENX" is not a common sound
adapter.
What's sauce for the goose is sauce for the gander - if our objection to
hardware channel access is 'it's insane on a few configurations', then
'it totally breaks what people are trying to do with their sound card on
a few configurations' is a valid objection to the new system.
If that's not the objection, stop shopping that screenshot around
everywhere. =)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:40 p.m.
On Wed, Apr 22, 2009 at 05:46:11PM -0700, Adam Williamson wrote:
On Wed, 2009-04-22 at 20:38 -0400, Will Woods wrote:
> On Wed, 2009-04-22 at 19:18 -0400, Orcan Ogetbil wrote:
>
> > What do you mean? Having full control of your soundcard with all the
> > sliders and stuff is useless?
> > Not displaying everything 1-1 and hiding sliders is an improvement?
>
> Holy hell yes:
> http://people.redhat.com/alexl/files/why-alsa-sucks.png
That's a true screenshot, but that argument is vulnerable to the exact
same 'logic' used to justify not caring about people who need to adjust
a different slider than Master or PCM, or people who want to switch
input channels: it's not a common case. most people don't see that much
of a mess of channels. The "Trident TRID4DWAVENX" is not a common sound
adapter.
Good thing it doesn't happen on other more common cards then.
Like say, the emu10k1.
http://www.codemonkey.org.uk/junk/wtf/alsa-mixer-o-doom.jpg
oops.
Dave
12:16 a.m.
On Thursday 23 April 2009 08:40:43 Dave Jones wrote:
On Wed, Apr 22, 2009 at 05:46:11PM -0700, Adam Williamson wrote:
Good thing it doesn't happen on other more common cards then.
Like say, the emu10k1.
http://www.codemonkey.org.uk/junk/wtf/alsa-mixer-o-doom.jpg
And what about another card which is at least as popular?
I'm talking about HDA cards.
Have you ever been able to get any mic input (e.g. for voip)
on any HDA card without messing with all the channels?
I always had to select the source manually then find which of the controls
changes volume and then do some tuning to find optimal volume/noise ratio.
Yes, this is very ugly but it's much better than no mic input at all.
P.S. This doesn't create much problems for me,
just another reason to stick with KDE/kmix.
But I'm sure there are many people who want to use a SIP softphone with GNOME.
Suren
1:06 a.m.
On Thu, 2009-04-23 at 10:16 +0500, Suren Karapetyan wrote:
On Thursday 23 April 2009 08:40:43 Dave Jones wrote:
> On Wed, Apr 22, 2009 at 05:46:11PM -0700, Adam Williamson wrote:
>
> Good thing it doesn't happen on other more common cards then.
> Like say, the emu10k1.
> http://www.codemonkey.org.uk/junk/wtf/alsa-mixer-o-doom.jpg
>
And what about another card which is at least as popular?
I'm talking about HDA cards.
Have you ever been able to get any mic input (e.g. for voip)
on any HDA card without messing with all the channels?
I always had to select the source manually then find which of the controls
changes volume and then do some tuning to find optimal volume/noise ratio.
Yes, this is very ugly but it's much better than no mic input at all.
P.S. This doesn't create much problems for me,
just another reason to stick with KDE/kmix.
But I'm sure there are many people who want to use a SIP softphone with GNOME.
Clearly the argument is now getting confused, because I'm in *favour* of
having a legacy mixer available, not against it...the argument about
having large numbers of channels is that it's overwhelming and confusing
and hence we should be supported PulseAudio in abstracting them all
away.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:16 a.m.
On Wed, 2009-04-22 at 23:40 -0400, Dave Jones wrote:
On Wed, Apr 22, 2009 at 05:46:11PM -0700, Adam Williamson wrote:
> On Wed, 2009-04-22 at 20:38 -0400, Will Woods wrote:
> > On Wed, 2009-04-22 at 19:18 -0400, Orcan Ogetbil wrote:
> >
> > > What do you mean? Having full control of your soundcard with all the
> > > sliders and stuff is useless?
> > > Not displaying everything 1-1 and hiding sliders is an improvement?
> >
> > Holy hell yes:
> > http://people.redhat.com/alexl/files/why-alsa-sucks.png
>
> That's a true screenshot, but that argument is vulnerable to the exact
> same 'logic' used to justify not caring about people who need to adjust
> a different slider than Master or PCM, or people who want to switch
> input channels: it's not a common case. most people don't see that much
> of a mess of channels. The "Trident TRID4DWAVENX" is not a common sound
> adapter.
Good thing it doesn't happen on other more common cards then.
Like say, the emu10k1.
http://www.codemonkey.org.uk/junk/wtf/alsa-mixer-o-doom.jpg
OK, so there's clearly a bug there.
Again to take the approach of the PulseAudio cheerleaders: this should
clearly be reported to the upstream project so it gets resolved. =)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:13 a.m.
On Wed, Apr 22, 2009 at 10:16:18PM -0700, Adam Williamson wrote:
On Wed, 2009-04-22 at 23:40 -0400, Dave Jones wrote:
> Good thing it doesn't happen on other more common cards then.
> Like say, the emu10k1.
> http://www.codemonkey.org.uk/junk/wtf/alsa-mixer-o-doom.jpg
OK, so there's clearly a bug there.
Again to take the approach of the PulseAudio cheerleaders: this should
clearly be reported to the upstream project so it gets resolved. =)
The "bug" is exposing all of the native mixer functionality in the alsa
mixer implementation and then presenting that in the UI. This is
precisely the problem that PA's mixer design fixes.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:33 p.m.
On Thu, 2009-04-23 at 14:13 +0100, Matthew Garrett wrote:
On Wed, Apr 22, 2009 at 10:16:18PM -0700, Adam Williamson wrote:
> On Wed, 2009-04-22 at 23:40 -0400, Dave Jones wrote:
> > Good thing it doesn't happen on other more common cards then.
> > Like say, the emu10k1.
> > http://www.codemonkey.org.uk/junk/wtf/alsa-mixer-o-doom.jpg
>
> OK, so there's clearly a bug there.
>
> Again to take the approach of the PulseAudio cheerleaders: this should
> clearly be reported to the upstream project so it gets resolved. =)
The "bug" is exposing all of the native mixer functionality in the alsa
mixer implementation and then presenting that in the UI. This is
precisely the problem that PA's mixer design fixes.
No, it isn't. Look closely at both the 'hilarious' screenshots: most of
the channels are duplicated (in Dave's case) or shown over ten times (in
Will's). That's why the whole thing is *so* long.
Just displaying all the available channels wouldn't be a bug in either
case.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:40 a.m.
On Thu, Apr 23, 2009 at 10:33:47AM -0700, Adam Williamson wrote:
On Thu, 2009-04-23 at 14:13 +0100, Matthew Garrett wrote:
> The "bug" is exposing all of the native mixer functionality in the alsa
> mixer implementation and then presenting that in the UI. This is
> precisely the problem that PA's mixer design fixes.
No, it isn't. Look closely at both the 'hilarious' screenshots: most of
the channels are duplicated (in Dave's case) or shown over ten times (in
Will's). That's why the whole thing is *so* long.
Just displaying all the available channels wouldn't be a bug in either
case.
No, what you're seeing there is that the mixer implements various
different stages for the same channel. In Dave's case it appears that
they're independently controllable for the input and output paths - note
that some of the duplicates have "record" and the others don't.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
1:20 p.m.
On Thursday 23 April 2009 18:13:28 Matthew Garrett wrote:
The "bug" is exposing all of the native mixer functionality in the alsa
mixer implementation and then presenting that in the UI. This is
precisely the problem that PA's mixer design fixes.
Exposing mixer functionality isn't a bug!
If someone has a sound card which has some advanced controls
(e.g. bass/treble) and you're trying (very hard) to hide them,
you aren't doing any good to that guy.
He bought that card - he deserves the right to use all it's functionality.
Suren
2:15 a.m.
Suren Karapetyan wrote:
Exposing mixer functionality isn't a bug!
If someone has a sound card which has some advanced controls
(e.g. bass/treble) and you're trying (very hard) to hide them,
you aren't doing any good to that guy.
He bought that card - he deserves the right to use all it's functionality.
+1
Kevin Kofler
8:39 p.m.
On Wed, Apr 22, 2009 at 8:38 PM, Will Woods wrote:
On Wed, 2009-04-22 at 19:18 -0400, Orcan Ogetbil wrote:
> What do you mean? Having full control of your soundcard with all the
> sliders and stuff is useless?
> Not displaying everything 1-1 and hiding sliders is an improvement?
Holy hell yes:
http://people.redhat.com/alexl/files/why-alsa-sucks.png
Wow that's great. I wish my soundcard (Audigy4) had that many
controls. It's only about half of it.
Orcan
1:20 a.m.
On 04/23/2009 07:09 AM, Orcan Ogetbil wrote:
On Wed, Apr 22, 2009 at 8:38 PM, Will Woods wrote:
> On Wed, 2009-04-22 at 19:18 -0400, Orcan Ogetbil wrote:
>
>> What do you mean? Having full control of your soundcard with all the
>> sliders and stuff is useless?
>> Not displaying everything 1-1 and hiding sliders is an improvement?
> Holy hell yes:
> http://people.redhat.com/alexl/files/why-alsa-sucks.png
>
Wow that's great. I wish my soundcard (Audigy4) had that many
controls. It's only about half of it.
Thank $deity. Very few people really want to fiddle with that many
controls. That UI is clearly not a sane one.
Rahul
1:57 a.m.
On Thu, 2009-04-23 at 11:50 +0530, Rahul Sundaram wrote:
Thank $deity. Very few people really want to fiddle with that many
controls. That UI is clearly not a sane one.
Of course they don't, but given the choice between "have to suffer
through poking all those controls in order to get audible sound / record
from an external device" and "not be able to get audible sound or record
from an external device", I think most people would prefer the former.
No-one's saying the previous situation is perfect, the point is that the
new system is missing functionality that is blatantly needed, which will
be experienced (and is *already* being experienced) by many many users
as a severe regression.
I don't think anyone wants to lose the new volume control, or even for
it not to be the default. All I'm asking for is for *some* old-skool GUI
mixer to be installed alongside it by default so those who need to poke
those controls will be able to find a reasonably usable app to do it
with.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:21 a.m.
On 04/23/2009 12:27 PM, Adam Williamson wrote:
On Thu, 2009-04-23 at 11:50 +0530, Rahul Sundaram wrote:
> Thank $deity. Very few people really want to fiddle with that many
> controls. That UI is clearly not a sane one.
Of course they don't, but given the choice between "have to suffer
through poking all those controls in order to get audible sound / record
from an external device" and "not be able to get audible sound or record
from an external device", I think most people would prefer the former.
Adam,
I am not arguing with your point. You don't have to defend that view
point. I have posted my own problem to fedora-desktop list a while back.
I am just saying that, the UI is not a sane one. Nothing more. Nothing less.
Rahul
12:59 p.m.
On Wed, 2009-04-22 at 23:57 -0700, Adam Williamson wrote:
On Thu, 2009-04-23 at 11:50 +0530, Rahul Sundaram wrote:
> Thank $deity. Very few people really want to fiddle with that many
> controls. That UI is clearly not a sane one.
Of course they don't, but given the choice between "have to suffer
through poking all those controls in order to get audible sound / record
from an external device" and "not be able to get audible sound or record
from an external device", I think most people would prefer the former.
No-one's saying the previous situation is perfect, the point is that the
new system is missing functionality that is blatantly needed, which will
be experienced (and is *already* being experienced) by many many users
as a severe regression.
I don't think anyone wants to lose the new volume control, or even for
it not to be the default. All I'm asking for is for *some* old-skool GUI
mixer to be installed alongside it by default so those who need to poke
those controls will be able to find a reasonably usable app to do it
with.
Yes, please. It is necessary to have a gui alternative for the cases
where the new, better, shinier thingy does not work.
The thread seems to be looping:
start:
a: please keep the old gui mixer as an alternative
b: just use alsamixer
a: but the gui mixer was working, why do I have to use alsamixer?
b: no it was not working (insert image of mixer with 23567 controls)
a: but it is working, I start it and it shows the controls and it works
b: no it does not (another image of a case which is complicated)
a: but I need it, why do I have to use alsamixer now?
b: you are mis-using things
loop:
a: no I'm not
b: yes you are
goto loop: for a while
[degenerates into name calling and four letter words]
goto start:
It's all about layers of support. Adding a new, simpler layer of support
does not mean you have to drop older, still functional layers, that take
care of corner cases you state you are never going to support.
-- Fernando
2:41 a.m.
On Thu, 2009-04-23 at 11:50 +0530, Rahul Sundaram wrote:
On 04/23/2009 07:09 AM, Orcan Ogetbil wrote:
> On Wed, Apr 22, 2009 at 8:38 PM, Will Woods wrote:
>> On Wed, 2009-04-22 at 19:18 -0400, Orcan Ogetbil wrote:
>>
>>> What do you mean? Having full control of your soundcard with all the
>>> sliders and stuff is useless?
>>> Not displaying everything 1-1 and hiding sliders is an improvement?
>> Holy hell yes:
>> http://people.redhat.com/alexl/files/why-alsa-sucks.png
>>
>
> Wow that's great. I wish my soundcard (Audigy4) had that many
> controls. It's only about half of it.
Thank $deity. Very few people really want to fiddle with that many
controls. That UI is clearly not a sane one.
Probably true -- and there's a very good case for simplifying it by
_default_.
But just breaking certain features, including "play audio through line
in", or "set the speaker volumes as the user wants them" is really not
the way to do it.
I can't play DVDs through my TV from my laptop at the moment either --
the only way I could get sufficient volume before was to plug in some
external speakers (which automatically turns off the internal speakers)
and then use gnome-volume-control to turn the internal speakers back
_on_ again. I can't do that any more.
The proposals I've seen to work around PulseAudio's problems have been
ridiculous -- running audio over the network using PulseAudio,
introducing a bunch of latency which wouldn't otherwise be there, was a
stupid suggestion even if the other box wasn't running Windows. The
hardware has a line-in socket for a reason -- are we just going to
advise Fedora users to tape over it and pretend it isn't there?
And the response to Stephen's need to control bass and treble speakers
individually was stupid too -- you _don't_ want to just tie them
together. Depending on what he's playing, he might need to adjust the
relative volume of bass vs. treble. That's not an unreasonable desire.
While I completely accept that we should be showing something _simple_
to the user in the default case, we really _do_ need to do better for
the cases where the user needs something more than that.
It's not good enough to just say "No. I know your hardware can do that
really well and it used to work, but we have decreed that your use case
isn't important so you're not allowed to do it that way any more".
That just sucks.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
10:31 a.m.
On Thu, 23.04.09 08:41, David Woodhouse (dwmw2(a)infradead.org) wrote:
On Thu, 2009-04-23 at 11:50 +0530, Rahul Sundaram wrote:
> On 04/23/2009 07:09 AM, Orcan Ogetbil wrote:
> > On Wed, Apr 22, 2009 at 8:38 PM, Will Woods wrote:
> >> On Wed, 2009-04-22 at 19:18 -0400, Orcan Ogetbil wrote:
> >>
> >>> What do you mean? Having full control of your soundcard with all the
> >>> sliders and stuff is useless?
> >>> Not displaying everything 1-1 and hiding sliders is an improvement?
> >> Holy hell yes:
> >> http://people.redhat.com/alexl/files/why-alsa-sucks.png
> >>
> >
> > Wow that's great. I wish my soundcard (Audigy4) had that many
> > controls. It's only about half of it.
>
> Thank $deity. Very few people really want to fiddle with that many
> controls. That UI is clearly not a sane one.
Probably true -- and there's a very good case for simplifying it by
_default_.
But just breaking certain features, including "play audio through line
in", or "set the speaker volumes as the user wants them" is really not
the way to do it.
Still I think that playing audio through line-in a pretty exotic
feature. If you want to do weird stuff like this, go to the ALSA
mixer. It's not that PA takes that away from you. You can always
bypass PA if you really feel that you need 555 different controls.
I can't play DVDs through my TV from my laptop at the moment
either --
the only way I could get sufficient volume before was to plug in some
external speakers (which automatically turns off the internal speakers)
and then use gnome-volume-control to turn the internal speakers back
_on_ again. I can't do that any more.
You can, just bypass PA.
If you want to do weird stuff, use weird tools. Don't expect us to
support all the exotic use cases minds could come up with to support
in a single simple UI.
The proposals I've seen to work around PulseAudio's problems
have been
ridiculous -- running audio over the network using PulseAudio,
introducing a bunch of latency which wouldn't otherwise be there, was a
stupid suggestion even if the other box wasn't running Windows. The
hardware has a line-in socket for a reason -- are we just going to
advise Fedora users to tape over it and pretend it isn't there?
The point of line-in is that you can record from it.
Doing line-in/mic feedback to line-out is something I deliberetaly don't
plan to support in PA. A sound card is not an amp.
And the response to Stephen's need to control bass and treble
speakers
individually was stupid too -- you _don't_ want to just tie them
together. Depending on what he's playing, he might need to adjust the
relative volume of bass vs. treble. That's not an unreasonable
desire.
That was no response. That's what Stephen suggested himself (I
assume are referring to 496981).
A laptop with integrated bass speakers is certainly not the type of
machine I have on my list as the most common piece of
hardware. Actaully I still cannot believe that such a thing exists.
What complicates the matter is that we cannot properly deduce if some
weird system has bass speakers connected to "Master mono" or not. It
could be something completely different. tbh I have not the slightest
clue how this should be exposed.
It's not good enough to just say "No. I know your hardware
can do that
really well and it used to work, but we have decreed that your use case
isn't important so you're not allowed to do it that way any more".
That just sucks.
I mean, you guys complain over over-simplification. Now you are
over-simplifying this entire story. Just because PA hides many exotic
'features' it doesn't mean you cannot access them. You can always
bypass PA and get the complex ALSA mixer. Try 'alsamixer -c0'
This whole thread is so pointless. The same people just keep repeating
the same issues over and over.
Let me summarize this:
1) PA doesn't support switching of different inputs (i.e. Mic
vs. Line-In) and outputs (Headphones vs internal Speakers) of a sound
card. There are two bugs filed about this. Yes, we need to support
this in PA, and we will. But it is a major PITA. ALSA has no usable
API for enumerating inputs and outputs. While the ALSA folks
acknoweledge that this is broken in ALSA this is not going to be fixed
anytime soon on their side. Now, I agree that this is actually a
bigger problem. So for F12 I will hack up input/output enumeration
that makes the best of the situation and that will hopefully work for
many cases, but most likely not all of them. This won't happen for
F11. Until then, do as the release notes suggest and drop to a tool
like alsamixer. In most cases the default mixer initialization
database of alsa should set up the right thing for you anyway and not
make this necessary. In many cases it doesn't, some of them because
there is no 'right thing', in others because the db is
incomplete. Thing is, without patches to the db this won't get fixed.
The main reason why this issue actually has become a problem recently
is that modern cards don't do the jack switching in hw anymore but leave
that for the software and provide jack sesning. Jack sensing is now
supported for two chips or so in ALSA but there is no code that would
actually make use of the jack sensing interfaces. PA should of course
make use of it. Unfortunately none of the sound cards I posess
currently is supported by ALSA jack sensing, so I cannot really work
on js right now.
2) People are not aware that pavucontrol allows you to switch between
several profiles during runtime. A profile is 'analog stereo',
'analog 5.1', 'digital spdif' and so on. Unfortunately this is not
exposed in g-v-c. I am pretty sure it will in F12. Install pavucontrol
and you can even switch these profiles during playback without having
your music stop in F11 already. It's actually pretty hot.
3) People want to do exotic things like (mis-)using their sound cards
as analog mixer for multiple analog sources. Or for driving internal
and external speakers from the same sound card at the same time. I
think this doesn't make much sense and won't support it in PA. If you
want to use it, drop to the raw alsa mixer.
4) People want 568 different elements in the mixer. They probably
should go visit a doctor, or just bypass PA by using a tool like
alsamixer. No chance in the world I will ever support this in PA.
5) People want PA to use a different mixer control than 'Master'. I
don't think this is a good thing to do. There is a workaround for this
as mentioned, but this is one of the most basic things a driver should
get right. Hence, fix it in the driver. I am not planning to support
this beyond allowing you to edit some config files to set this up.
6) There are some exotic pieces of hw around. Like that monster laptop
with integrated bass speakers connected to 'Master Mono'. Not sure how
we should support this at all and if we even could identify these
cases. Given how rare these devices are, this is not a top-priority to
fix for me, but I have it on my list. In the meantime, drop to the raw
alsa mixer please.
7) There are default mixer initialization problems. alsa-utils now
ships with a database of 'sensible' default mixer initialization
settings, i.e. settings where playback PCM is routed at a 'reasonable'
level to the outputs, and input PCM from the mic. That db is not
complete. Some HDa cards have weird switches that need to be set
correctly for any output happen at all. That db is the right place to
do that. So don't complain that PA doesn't expose tht switch! Instead,
just add the correct setting to the db.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
12:38 p.m.
On Thu, 2009-04-23 at 17:31 +0200, Lennart Poettering wrote:
Still I think that playing audio through line-in a pretty exotic
feature. If you want to do weird stuff like this, go to the ALSA
mixer. It's not that PA takes that away from you. You can always
bypass PA if you really feel that you need 555 different controls.
To reiterate, I at least am not proposing that gnome-volume-control
support all these cases. g-v-c should support profile switching and
input switching, and have a single volume control that actually works
properly on all hardware. That would be enough.
All I want beyond that is for there to be a GUI mixer that provides full
channel control available in the default install for all editions of
Fedora, *alongside* Pulse-level mixers like the new-skool g-v-c. Only
providing alsamixer would be a serious regression - most people don't
know that it exists, or know how to use it. And most people, infamously,
don't read the release notes. This isn't our fault, but it's something
we should take into account.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:10 p.m.
On Thu, 23 Apr 2009, Adam Williamson wrote:
To reiterate, I at least am not proposing that gnome-volume-control
support all these cases. g-v-c should support profile switching and
input switching, and have a single volume control that actually works
properly on all hardware. That would be enough.
For a start. I'm sure there are some more cases which should be
considered, but the most important ones are probably the ones you
described.
All I want beyond that is for there to be a GUI mixer that provides
full
channel control available in the default install for all editions of
Fedora, *alongside* Pulse-level mixers like the new-skool g-v-c. Only
providing alsamixer would be a serious regression - most people don't
know that it exists, or know how to use it.
Call it "Advanced Audio Mixer", have it offer the Alsa channels and offer
to show only a subset, make it play nicely with the new-skool mixer and
world domination will be ours. Nope, that came out wrong. Let me try
again: And all our users rejoiced.
There, much better. The easy cases can work with the new-skool mixer and
if you need something specific, use the Advanced mixer.
Hopefully people needing the Advanced mixer will share their use cases and
these can then be considered for inclusion into the new-skool mixer.
And most people, infamously, don't read the release notes. This
isn't
our fault, but it's something we should take into account.
I think that's worth a seperate discussion...
regards,
andreas
2:18 p.m.
On Thu, 2009-04-23 at 17:31 +0200, Lennart Poettering wrote:
Still I think that playing audio through line-in a pretty exotic
feature. If you want to do weird stuff like this, go to the ALSA
mixer. It's not that PA takes that away from you. You can always
bypass PA if you really feel that you need 555 different controls.
Yes, monitoring what you're recording on the line in is SUCH an unusual
need! Just think of what I'm doing as monitoring a recording without
actually recording.
If you want Pulseaudio to ever be more than a toy for Aunt Tillie,
you're going to have to pull your head out of your ass.
> I can't play DVDs through my TV from my laptop at the moment
either --
> the only way I could get sufficient volume before was to plug in some
> external speakers (which automatically turns off the internal speakers)
> and then use gnome-volume-control to turn the internal speakers back
> _on_ again. I can't do that any more.
You can, just bypass PA.
If you want to do weird stuff, use weird tools. Don't expect us to
support all the exotic use cases minds could come up with to support
in a single simple UI.
> The proposals I've seen to work around PulseAudio's problems have been
> ridiculous -- running audio over the network using PulseAudio,
> introducing a bunch of latency which wouldn't otherwise be there, was a
> stupid suggestion even if the other box wasn't running Windows. The
> hardware has a line-in socket for a reason -- are we just going to
> advise Fedora users to tape over it and pretend it isn't there?
The point of line-in is that you can record from it.
Doing line-in/mic feedback to line-out is something I deliberetaly don't
plan to support in PA.
It's called "input monitoring" and it's not unusual. Why is someone
with
no apparent musical or audio recording background in charge of core
Fedora audio infrastructure?
A sound card is not an amp.
I don't want it to amplify, in fact that's exactly what I don't want. I
just want it to pass line-in through to the amplified speakers as
untouched as possible. I want 0dB. How many different ways do I have to
explain this before you get it?
> And the response to Stephen's need to control bass and
treble speakers
> individually was stupid too -- you _don't_ want to just tie them
> together. Depending on what he's playing, he might need to adjust the
> relative volume of bass vs. treble. That's not an unreasonable
> desire.
That was no response. That's what Stephen suggested himself (I
assume are referring to 496981).
A laptop with integrated bass speakers is certainly not the type of
machine I have on my list as the most common piece of
hardware. Actaully I still cannot believe that such a thing exists.
So apparently it is Fedora policy to only support common hardware.
What complicates the matter is that we cannot properly deduce if
some
weird system has bass speakers connected to "Master mono" or not. It
could be something completely different. tbh I have not the slightest
clue how this should be exposed.
You expose it in the UI as a volume and a "tone" slider. Or "bass"
and
"treble" sliders. Christ, have you ever looked at real physical stereo?
The 'exposure' is the easy part. Yes, the low level details are probably
going to be a bitch. But handling those kinds of details are your *JOB*.
> It's not good enough to just say "No. I know your
hardware can do that
> really well and it used to work, but we have decreed that your use case
> isn't important so you're not allowed to do it that way any more".
>
> That just sucks.
I mean, you guys complain over over-simplification. Now you are
over-simplifying this entire story. Just because PA hides many exotic
'features' it doesn't mean you cannot access them. You can always
bypass PA and get the complex ALSA mixer. Try 'alsamixer -c0'
All I want is for the taskbar mixer applet to adjust PCM instead of
Master. THAT'S ALL I !@#$ING NEED, LENNART! I don't even want it to be
exposed in ui. A secret daemon.conf option would be JUST FINE.
This whole thread is so pointless. The same people just keep
repeating
the same issues over and over.
Because you and Bastien Nocera are being defensive, stubborn
thick-headed dicks who aren't listening. Yes, we get it. Disagreeing
with the almighty Lennart Poettering is a pointless waste of time. Don't
bother even trying!
Let me summarize this:
The main reason why this issue actually has become a problem recently
is that modern cards don't do the jack switching in hw anymore but leave
that for the software and provide jack sesning. Jack sensing is now
supported for two chips or so in ALSA but there is no code that would
actually make use of the jack sensing interfaces. PA should of course
make use of it. Unfortunately none of the sound cards I posess
currently is supported by ALSA jack sensing, so I cannot really work
on js right now.
I've had this motherboard for 3 years. I don't give a shit what
"modern"
cards do or don't do. All I want is for what worked before to continue
working.
3) People want to do exotic things like (mis-)using their sound
cards
as analog mixer for multiple analog sources. Or for driving internal
and external speakers from the same sound card at the same time. I
think this doesn't make much sense and won't support it in PA. If you
want to use it, drop to the raw alsa mixer.
5) People want PA to use a different mixer control than
'Master'. I
don't think this is a good thing to do. There is a workaround for this
as mentioned, but this is one of the most basic things a driver should
get right. Hence, fix it in the driver. I am not planning to support
this beyond allowing you to edit some config files to set this up.
I don't care what you think. This isn't about what you think. This is
about what the end user wants. Namely ME. Clearly, from this thread and
plenty of others in the past, you don't give two shits about what your
end users want.
2:29 p.m.
It's called "input monitoring" and it's not
unusual. Why is someone with
no apparent musical or audio recording background in charge of core
Fedora audio infrastructure?
Because neither you nor someone with « apparent musical or audio
recording background » stepped up to do the work.
Me ? I have neither this background nor the development skills. At the
very least, Lennart has the development skills.
You seem to have such a « musical or audio recording background », so
you and Lennart might be complimentary and thus a great team (no pun
intended, I honestly think that).
If only you were actually helping him instead of talking so much (and so badly).
Best regards,
----------
Mathieu Bridon (bochecha)
2:42 p.m.
On Thu, 2009-04-23 at 21:29 +0200, Mathieu Bridon (bochecha) wrote:
> It's called "input monitoring" and it's not
unusual. Why is someone with
> no apparent musical or audio recording background in charge of core
> Fedora audio infrastructure?
Because neither you nor someone with « apparent musical or audio
recording background » stepped up to do the work.
Me ? I have neither this background nor the development skills. At the
very least, Lennart has the development skills.
You seem to have such a « musical or audio recording background », so
you and Lennart might be complimentary and thus a great team (no pun
intended, I honestly think that).
Yes. Lennart is a pig headed dick who won't listen to suggestions. He's
a textbook case of someone with no listening skills. And Bastien Nocera
isn't doing so great either.
And I'm a huge dick with quite a bit of steam to blow off due to
Fedora's general descent into brokenness. Watch the sparks fly!
If only you were actually helping him instead of talking so much (and
so badly).
Lennart, learn to listen.
3:10 p.m.
On Thu, 23.04.09 14:42, Callum Lerwick (seg(a)haxxed.com) wrote:
On Thu, 2009-04-23 at 21:29 +0200, Mathieu Bridon (bochecha) wrote:
> > It's called "input monitoring" and it's not unusual. Why is
someone with
> > no apparent musical or audio recording background in charge of core
> > Fedora audio infrastructure?
>
> Because neither you nor someone with « apparent musical or audio
> recording background » stepped up to do the work.
>
> Me ? I have neither this background nor the development skills. At the
> very least, Lennart has the development skills.
>
> You seem to have such a « musical or audio recording background », so
> you and Lennart might be complimentary and thus a great team (no pun
> intended, I honestly think that).
Yes. Lennart is a pig headed dick who won't listen to suggestions. He's
a textbook case of someone with no listening skills. And Bastien Nocera
isn't doing so great either.
And I'm a huge dick with quite a bit of steam to blow off due to
Fedora's general descent into brokenness. Watch the sparks fly!
> If only you were actually helping him instead of talking so much (and so badly).
Lennart, learn to listen.
I am pretty good at listening. The best thing to make sure I am all
ears is of course calling me a "pig headed dick" and "stupid" and of
course using the magic words "fuck you" on me. Adding a couple of
demands on top and assuming that I was your private code monkey rounds
up nicely this convincing approach to get me to fulfill to your
wishes!
I responded earnestly to all points raised in this thread. And all I
got from you were insults and demands.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
3:48 p.m.
On Thu, 2009-04-23 at 22:10 +0200, Lennart Poettering wrote:
I am pretty good at listening. The best thing to make sure I am all
ears is of course calling me a "pig headed dick" and "stupid" and of
course using the magic words "fuck you" on me. Adding a couple of
demands on top and assuming that I was your private code monkey rounds
up nicely this convincing approach to get me to fulfill to your
wishes!
Bastien Nocera started it, and you continued it. I was perfectly polite
in my initial question. And Bastien quite politely and
passive-aggressively told me to fuck off. It went downhill from there.
I responded earnestly to all points raised in this thread. And all I
got from you were insults and demands.
Yes, you and Bastien Nocera earnestly responded with defensiveness,
handwaving, distractions and blow-offs.
That's not how you listen and that's not how you constructively
communicate with people.
2:56 p.m.
On Thu, 23.04.09 14:18, Callum Lerwick (seg(a)haxxed.com) wrote:
> > The proposals I've seen to work around PulseAudio's
problems have been
> > ridiculous -- running audio over the network using PulseAudio,
> > introducing a bunch of latency which wouldn't otherwise be there, was a
> > stupid suggestion even if the other box wasn't running Windows. The
> > hardware has a line-in socket for a reason -- are we just going to
> > advise Fedora users to tape over it and pretend it isn't there?
>
> The point of line-in is that you can record from it.
>
> Doing line-in/mic feedback to line-out is something I deliberetaly don't
> plan to support in PA.
It's called "input monitoring" and it's not unusual. Why is someone
with
no apparent musical or audio recording background in charge of core
Fedora audio infrastructure?
You are forgetting one thing: PA is a desktop sound server, not a pro
audio sound server or anything for music production.
And that's why input monitoring doesn't make much sense for PA and I
don't plan to support it. If you do pro audio, then don't use PA. Use
JACK and use the raw ALSA.
> What complicates the matter is that we cannot properly deduce if
some
> weird system has bass speakers connected to "Master mono" or not. It
> could be something completely different. tbh I have not the slightest
> clue how this should be exposed.
You expose it in the UI as a volume and a "tone" slider. Or "bass"
and
"treble" sliders. Christ, have you ever looked at real physical stereo?
The 'exposure' is the easy part. Yes, the low level details are probably
going to be a bitch. But handling those kinds of details are your
*JOB*.
Ah, I always wondered what my job was. Nice that I get it explained
from you now.
> 5) People want PA to use a different mixer control than
'Master'. I
> don't think this is a good thing to do. There is a workaround for this
> as mentioned, but this is one of the most basic things a driver should
> get right. Hence, fix it in the driver. I am not planning to support
> this beyond allowing you to edit some config files to set this up.
I don't care what you think. This isn't about what you think. This is
about what the end user wants. Namely ME. Clearly, from this thread and
plenty of others in the past, you don't give two shits about what your
end users want.
Hear, hear!
So everyone listen up! The one magical 'end user' is now revealed as
being Mr. Callum Lerwick himself! Listen to his demands and obey!
Don't you think you are a bit presumptuous firstly in believing that
you are the one 'end user' that counts and can stand for them all?
What do you think of courself? And secondly in requesting that RH's
developers have to follow your wishes orders when developing software
you don't even pay for?
Come on, give me break. This is more than enough.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
3:57 p.m.
On Thu, 23 Apr 2009, Lennart Poettering wrote:
You are forgetting one thing: PA is a desktop sound server, not a
pro
audio sound server or anything for music production.
And that's why input monitoring doesn't make much sense for PA and I
don't plan to support it. If you do pro audio, then don't use PA. Use
JACK and use the raw ALSA.
I wouldn't consider "input monitoring" a pro-audio feature. I recently
spent about 4 years at university, getting a degree. I've seen quite a lot
of people there having no audio equipment at all except a notebook or a
computer with some external speakers.
Many of them had a mp3 player or a minidisc player connected to the line
in and played their music through the speakers of their computer.
I'm certain these people were not pro-audio guys or anything but the
standard Windows XP desktop user. So maybe it would be worthwile
considering their usecase desktop-audio worthy?
Just saying...
regards,
andreas
4:30 p.m.
On Thu, 2009-04-23 at 22:57 +0200, Andreas Thienemann wrote:
On Thu, 23 Apr 2009, Lennart Poettering wrote:
> You are forgetting one thing: PA is a desktop sound server, not a pro
> audio sound server or anything for music production.
>
> And that's why input monitoring doesn't make much sense for PA and I
> don't plan to support it. If you do pro audio, then don't use PA. Use
> JACK and use the raw ALSA.
I wouldn't consider "input monitoring" a pro-audio feature. I recently
spent about 4 years at university, getting a degree. I've seen quite a lot
of people there having no audio equipment at all except a notebook or a
computer with some external speakers.
Many of them had a mp3 player or a minidisc player connected to the line
in and played their music through the speakers of their computer.
I'm certain these people were not pro-audio guys or anything but the
standard Windows XP desktop user. So maybe it would be worthwile
considering their usecase desktop-audio worthy?
Just saying...
... See, I'm not the only one.
Lennart, you are not God. You can not foresee every use case.
12:46 p.m.
On Thu, 2009-04-23 at 08:41 +0100, David Woodhouse wrote:
And the response to Stephen's need to control bass and treble
speakers
individually was stupid too -- you _don't_ want to just tie them
together. Depending on what he's playing, he might need to adjust the
relative volume of bass vs. treble. That's not an unreasonable desire.
You abstract it and present it in the UI as a volume slider and a "tone"
slider.
hwvol = vol;
bassvol = vol * tone;
Which is the kind of stuff PA *should* be doing. But Stephen is a fringe
nutjob for owning such uncommon hardware, and PA is never going to
support it.
It's not good enough to just say "No. I know your hardware
can do that
really well and it used to work, but we have decreed that your use case
isn't important so you're not allowed to do it that way any more".
That just sucks.
+1
Thank god, someone else has some sanity. :P
5:30 p.m.
On Thu, April 23, 2009 11:46 am, Callum Lerwick wrote:
On Thu, 2009-04-23 at 08:41 +0100, David Woodhouse wrote:
> And the response to Stephen's need to control bass and treble speakers
> individually was stupid too -- you _don't_ want to just tie them
> together. Depending on what he's playing, he might need to adjust the
> relative volume of bass vs. treble. That's not an unreasonable desire.
You abstract it and present it in the UI as a volume slider and a "tone"
slider.
hwvol = vol;
bassvol = vol * tone;
Which is the kind of stuff PA *should* be doing. But Stephen is a fringe
nutjob for owning such uncommon hardware, and PA is never going to
support it.
You have got to be freaking kidding me???
This is a major brand laptop - Dell Inspiron, not some bizarre uncommon
piece of HW.
Also, this used to work perfectly back in F8 or F9, and regressed (like
pretty much everything in Fedora).
And, FYI, I didn't come up with the WAR, but found it here:
http://ubuntuforums.org/showthread.php?t=101386#6
So at least a number of other people have the same issue...
2:34 a.m.
David Woodhouse wrote:
The proposals I've seen to work around PulseAudio's problems
have been
ridiculous -- running audio over the network using PulseAudio,
introducing a bunch of latency which wouldn't otherwise be there, was a
stupid suggestion even if the other box wasn't running Windows.
FYI, PulseAudio also runs on Window$.
http://www.cendio.com/pulseaudio/
Kevin Kofler
11:34 a.m.
On Sun, 2009-04-26 at 09:34 +0200, Kevin Kofler wrote:
David Woodhouse wrote:
> The proposals I've seen to work around PulseAudio's problems have been
> ridiculous -- running audio over the network using PulseAudio,
> introducing a bunch of latency which wouldn't otherwise be there, was a
> stupid suggestion even if the other box wasn't running Windows.
FYI, PulseAudio also runs on Window$.
http://www.cendio.com/pulseaudio/
Does that come with DirectSound drivers so World of Warcraft will feed
through it?
... Though I still don't see why network latency and packet loss are
more desirable than a single analog patch cable. Also my IAudio U3
doesn't have ethernet, or wireless...
11:37 a.m.
On Sun, 26.04.09 11:34, Callum Lerwick (seg(a)haxxed.com) wrote:
On Sun, 2009-04-26 at 09:34 +0200, Kevin Kofler wrote:
> David Woodhouse wrote:
> > The proposals I've seen to work around PulseAudio's problems have been
> > ridiculous -- running audio over the network using PulseAudio,
> > introducing a bunch of latency which wouldn't otherwise be there, was a
> > stupid suggestion even if the other box wasn't running Windows.
>
> FYI, PulseAudio also runs on Window$.
> http://www.cendio.com/pulseaudio/
Does that come with DirectSound drivers so World of Warcraft will feed
through it?
... Though I still don't see why network latency and packet loss are
more desirable than a single analog patch cable. Also my IAudio U3
doesn't have ethernet, or wireless...
Not sure what kind of cheap cabling you have. But packet loss on local
ethernet is near zero.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
12:10 p.m.
On Sun, 2009-04-26 at 18:37 +0200, Lennart Poettering wrote:
On Sun, 26.04.09 11:34, Callum Lerwick (seg(a)haxxed.com) wrote:
> On Sun, 2009-04-26 at 09:34 +0200, Kevin Kofler wrote:
> > David Woodhouse wrote:
> > > The proposals I've seen to work around PulseAudio's problems have
been
> > > ridiculous -- running audio over the network using PulseAudio,
> > > introducing a bunch of latency which wouldn't otherwise be there, was
a
> > > stupid suggestion even if the other box wasn't running Windows.
> >
> > FYI, PulseAudio also runs on Window$.
> > http://www.cendio.com/pulseaudio/
>
> Does that come with DirectSound drivers so World of Warcraft will feed
> through it?
>
> ... Though I still don't see why network latency and packet loss are
> more desirable than a single analog patch cable. Also my IAudio U3
> doesn't have ethernet, or wireless...
Not sure what kind of cheap cabling you have. But packet loss on local
ethernet is near zero.
And wireless?
12:34 p.m.
On Sun, 26.04.09 12:10, Callum Lerwick (seg(a)haxxed.com) wrote:
> > ... Though I still don't see why network latency and
packet loss are
> > more desirable than a single analog patch cable. Also my IAudio U3
> > doesn't have ethernet, or wireless...
>
> Not sure what kind of cheap cabling you have. But packet loss on local
> ethernet is near zero.
And wireless?
I thought you were comparing audio cables with ethernet cables.
But now that I see that you want to compare audio cables with wireless
ethernet then I am pretty sure you can see what the advantage of
wireless connections is -- the fct that they are wireless.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
1:05 p.m.
On Sun, 2009-04-26 at 19:34 +0200, Lennart Poettering wrote:
On Sun, 26.04.09 12:10, Callum Lerwick (seg(a)haxxed.com) wrote:
> > > ... Though I still don't see why network latency and packet loss are
> > > more desirable than a single analog patch cable. Also my IAudio U3
> > > doesn't have ethernet, or wireless...
> >
> > Not sure what kind of cheap cabling you have. But packet loss on local
> > ethernet is near zero.
>
> And wireless?
I thought you were comparing audio cables with ethernet cables.
But now that I see that you want to compare audio cables with wireless
ethernet then I am pretty sure you can see what the advantage of
wireless connections is -- the fct that they are wireless.
Touché.
2:12 p.m.
On Thu, Apr 23, 2009 at 2:20 AM, Rahul Sundaram wrote:
On 04/23/2009 07:09 AM, Orcan Ogetbil wrote:
> On Wed, Apr 22, 2009 at 8:38 PM, Will Woods wrote:
>> On Wed, 2009-04-22 at 19:18 -0400, Orcan Ogetbil wrote:
>>
>>> What do you mean? Having full control of your soundcard with all the
>>> sliders and stuff is useless?
>>> Not displaying everything 1-1 and hiding sliders is an improvement?
>> Holy hell yes:
>> http://people.redhat.com/alexl/files/why-alsa-sucks.png
>>
>
> Wow that's great. I wish my soundcard (Audigy4) had that many
> controls. It's only about half of it.
Thank $deity. Very few people really want to fiddle with that many
controls. That UI is clearly not a sane one.
Fedora amazes me. It teaches me something new every day. The other
day, I learned that there are people on the surface of the planet who
would push ctrl-alt-bs accidentally. Now, I see that there are folks
who don't want full control over the capabilities of their hardware.
I would never have imagined hiding soundcard functionality could be
thought as an enhancement. My Audigy4 has even more controls than the
image that was posted. And I was glad to be able to fiddle with all of
them. Sure there are some controls that I don't need. But I can opt to
not display them in kmix.
But there is one thing that I miss. These controls used to be
classified in tabs. One tab was showing the output controls the other
was showing input controls etc. Does anyone know who/what made these
tabs disappear in kmix?
Orcan
2:34 p.m.
On Thu, 23.04.09 15:12, Orcan Ogetbil (oget.fedora(a)gmail.com) wrote:
I would never have imagined hiding soundcard functionality could be
thought as an enhancement. My Audigy4 has even more controls than the
image that was posted. And I was glad to be able to fiddle with all of
them. Sure there are some controls that I don't need. But I can opt to
not display them in kmix.
I'd bet money that only for about 10% of your controls you actually
know what they do.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
2:43 p.m.
On Thu, Apr 23, 2009 at 3:34 PM, Lennart Poettering wrote:
On Thu, 23.04.09 15:12, Orcan Ogetbil wrote:
> I would never have imagined hiding soundcard functionality could be
> thought as an enhancement. My Audigy4 has even more controls than the
> image that was posted. And I was glad to be able to fiddle with all of
> them. Sure there are some controls that I don't need. But I can opt to
> not display them in kmix.
I'd bet money that only for about 10% of your controls you actually
know what they do.
The last time I checked all my controls (including the ones I don't
display), there was only 1 control that I didn't know. And it was
labeled "Unknown1" by ALSA. Feel free to ask questions about any of
them. No need for you to make such a bet with someone from
AudioCreation SIG.
Orcan
4:01 a.m.
On Wed, 2009-04-22 at 20:38 -0400, Will Woods wrote:
On Wed, 2009-04-22 at 19:18 -0400, Orcan Ogetbil wrote:
> What do you mean? Having full control of your soundcard with all the
> sliders and stuff is useless?
> Not displaying everything 1-1 and hiding sliders is an improvement?
Holy hell yes:
http://people.redhat.com/alexl/files/why-alsa-sucks.png
As an argument for what PulseAudio is doing, that's a complete
non-sequitur.
The old gnome-volume-control had the facility to show/hide different
mixer elements already -- if you think you _know_ which ones are useful
to expose to the user and which aren't, we had the facility to do that
_already_.
You don't have to do it in such a way that the user _can't_ get at the
extra controls when our heuristics get it wrong (as they _often_ will).
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
10:32 a.m.
On Thu, 23.04.09 10:01, David Woodhouse (dwmw2(a)infradead.org) wrote:
On Wed, 2009-04-22 at 20:38 -0400, Will Woods wrote:
> On Wed, 2009-04-22 at 19:18 -0400, Orcan Ogetbil wrote:
>
> > What do you mean? Having full control of your soundcard with all the
> > sliders and stuff is useless?
> > Not displaying everything 1-1 and hiding sliders is an improvement?
>
> Holy hell yes:
> http://people.redhat.com/alexl/files/why-alsa-sucks.png
As an argument for what PulseAudio is doing, that's a complete
non-sequitur.
The old gnome-volume-control had the facility to show/hide different
mixer elements already -- if you think you _know_ which ones are useful
to expose to the user and which aren't, we had the facility to do that
_already_.
You don't have to do it in such a way that the user _can't_ get at the
extra controls when our heuristics get it wrong (as they _often_ will).
First of all, these are no 'heuristics'.
Secondly, you _can_ get at the extra controls by dropping to alsamixer.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
2:38 a.m.
Lennart Poettering wrote:
Secondly, you _can_ get at the extra controls by dropping to
alsamixer.
... which isn't even a GUI app.
You might at least suggest a GUI app like the XFCE mixer or KMix as a
serious alternative. But all this doesn't justify dropping ALSA support
from gnome-volume-control.
Kevin Kofler
6:31 p.m.
On Wed, 22.04.09 14:51, Callum Lerwick (seg(a)haxxed.com) wrote:
> > > > Can I at least get a secret gconf key to do
what
> > > > I want? :P
> > >
> > > The volume control uses PulseAudio, it doesn't use ALSA directly
> > > anymore, so no, there's no secret GConf key for that.
> >
> > So a PulseAudio config option then. Do I have to write the patch myself?
>
> Probably not a PA config option either.
>
> The volume control applet will show a mixer for input devices if an
> application is recording on it. You'd just need to make the mixer think
> that something is recording on that device. I'm not sure how to do that,
> but Lennart might.
No, you are misunderstanding. I don't want to adjust the input volume. I
want it left alone. I want the master left alone. Master stays at 0dB,
Line stays at 0dB. I want PA to dink with PCM instead of Master.
You can pass a parameter (control=) when loading the PA ALSA plugin
(module-alsa-sink) which specifies the ALSA mixer element to
choose. It's intended to be used as a hackish work-around for drivers
that don't name their controls properly.
Let's just reverse that then:
--- pulseaudio-0.9.15/src/modules/alsa/alsa-util.c 2009-04-13 16:11:32.000000000
-0500
+++ pulseaudio-0.9.15.patched/src/modules/alsa/alsa-util.c 2009-04-22
14:23:49.367297597 -0500
@@ -1180,7 +1180,7 @@
else if (profile)
e = pa_alsa_find_elem(m, profile->playback_control_name,
profile->playback_control_fallback, TRUE);
else
- e = pa_alsa_find_elem(m, "Master", "PCM", TRUE);
+ e = pa_alsa_find_elem(m, "PCM", "Master", TRUE);
break;
case SND_PCM_STREAM_CAPTURE:
The mixer handling code changed a couple of times after this.
Suggestion: Make fallback order a config option. You are hardcoding
policy. That's a no-no.
No. This has nothing to do with policy.
We want to control the 'outermost' volume slider. Because that's the
one that most likely controls the actual analog amplifier if there is
any. Controlling 'PCM' is kind of pointless on most modern cards since
it is implemented digitally.
It simply doesn't make any sense to pick 'PCM', unless the driver is a
bit weird and doesn't have a 'Master' control.
And as mentioned there's a workaround, you can specify the control for
a sink. But using that will break device autodetecting and hence the
whole profile logic. BTW, that option was contributed by someone with a
weird driver who supplied me with a patch. He didn't whine on a huge
thread on a mailing list, but just prepared a patch. Could be a good
role model for some other folks, don't you think?
Suggestion: Hardwired for only two options?
Yes. 'Master' is the one two use. And 'PCM' is the fallback for broken
drivers. That's it. There's no need for more fallbacks. Drivers
should be fixed to register 'Master' properly. Which is why you even
could argue that having the 'PCM' fallback already hides driver
brokeness.
There's no such thing as
two:
http://c2.com/cgi/wiki?ZeroOneInfinityRule
http://c2.com/cgi/wiki?TwoIsAnImpossibleNumber
> I don't know what Pidgin uses, but spitting out alert sounds using
> paplay is unlikely to work well at all.
Why not? Small processes working together is the Unix way. But people
seem to have forgotten that.
Yes, we hate Unix, didn't you notice by now?
Anyway, Pidgin should be using libcanberra. There has been a bug open
in their BTS for a while about that. However, they appear to have
their very own opinions on some things, so this is not going to happen
very soon I fear. Unless of course someone prepares an actual patch
and fights that through the end.
It would however probably be a better idea to finally move Fedora to
Empathy by default.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
2:19 p.m.
On Thu, 2009-04-23 at 01:31 +0200, Lennart Poettering wrote:
On Wed, 22.04.09 14:51, Callum Lerwick (seg(a)haxxed.com) wrote:
> > > > > Can I at least get a secret gconf key to do what
> > > > > I want? :P
> > > >
> > > > The volume control uses PulseAudio, it doesn't use ALSA directly
> > > > anymore, so no, there's no secret GConf key for that.
> > >
> > > So a PulseAudio config option then. Do I have to write the patch myself?
> >
> > Probably not a PA config option either.
> >
> > The volume control applet will show a mixer for input devices if an
> > application is recording on it. You'd just need to make the mixer think
> > that something is recording on that device. I'm not sure how to do that,
> > but Lennart might.
>
> No, you are misunderstanding. I don't want to adjust the input volume. I
> want it left alone. I want the master left alone. Master stays at 0dB,
> Line stays at 0dB. I want PA to dink with PCM instead of Master.
You can pass a parameter (control=) when loading the PA ALSA plugin
(module-alsa-sink) which specifies the ALSA mixer element to
choose. It's intended to be used as a hackish work-around for drivers
that don't name their controls properly.
THANK YOU. That is *ALL* I was asking for at the start of this thread.
This whole thread could have been accomplished with one polite useful
reply. But no, Bastien Nocera had to escalate it in to a dickfest.
$ pulseaudio
E: module.c: Failed to load module "module-alsa-sink" (argument:
"control=PCM"): initialization failed.
E: main.c: Module load failed.
E: main.c: Failed to initialize daemon.
So how the shit do I make it work?
And as mentioned there's a workaround, you can specify the
control for
a sink. But using that will break device autodetecting and hence the
whole profile logic. BTW, that option was contributed by someone with a
weird driver who supplied me with a patch. He didn't whine on a huge
thread on a mailing list, but just prepared a patch. Could be a good
role model for some other folks, don't you think?
Fuck you.
2:36 p.m.
On Thu, Apr 23, 2009 at 3:19 PM, Callum Lerwick wrote:
On Thu, 2009-04-23 at 01:31 +0200, Lennart Poettering wrote:
> And as mentioned there's a workaround, you can specify the control for
> a sink. But using that will break device autodetecting and hence the
> whole profile logic. BTW, that option was contributed by someone with a
> weird driver who supplied me with a patch. He didn't whine on a huge
> thread on a mailing list, but just prepared a patch. Could be a good
> role model for some other folks, don't you think?
Fuck you.
Actually, I have a very good patch for pulseaudio. It's a one liner
and goes right after the %setup line in the specfile:
rm -fr *
My wife have had this problem with her computer freezing when browsing
the web.I coudn't trace the error. It required a hard reboot every
time. I thought I tried everything, changed the CPU, the video card,
memory... And nothing solved the issue and I thought it was a
motherboard error, until 3 days ago...
I finally saw a system.log error regarding pulseaudio and I
immediately removed all the pulseaudio crap from her computer.
Now it doesn't freeze anymore. She's happy, I'm happy.
Seriously, given hundreds of threads in fedoraforum, people
complaining about pulseaudio, we do need to discuss how to remove
pulseaudio from Fedora (not whether we should remove it).
Cheers,
Orcan, the pulse against
3:17 p.m.
On Thu, 2009-04-23 at 15:36 -0400, Orcan Ogetbil wrote:
My wife have had this problem with her computer freezing when
browsing
the web.
I finally saw a system.log error regarding pulseaudio and I
immediately removed all the pulseaudio crap from her computer.
Why didn't you file a bug? If you don't report problems when you
experience them, how do you ever expect it to get better?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:39 p.m.
On Thu, Apr 23, 2009 at 4:17 PM, Adam Williamson wrote:
On Thu, 2009-04-23 at 15:36 -0400, Orcan Ogetbil wrote:
> My wife have had this problem with her computer freezing when browsing
> the web.
> I finally saw a system.log error regarding pulseaudio and I
> immediately removed all the pulseaudio crap from her computer.
Why didn't you file a bug? If you don't report problems when you
experience them, how do you ever expect it to get better?
I said this before (but maybe not under this thread, so sorry):
Because pulseaudio is not worth it.
Pulseaudio has been a failure in all 3 of my computers. And I don't
know (in person) anyone who has a working pulseaudio setup. All
positive things I heard about pulseaudio were from a handful of people
I discussed here and on irc. Majority of people that I communicated
does not want pulseaudio.
And yes, I don't know how I allowed it to get into my wife's computer.
I blame myself for that.
Pulseaudio proposes nice features. But proposing is one thing,
implementing is another. It is pre-alpha quality for now, and
shouldn't be allowed for public consumption. Maybe in 2-3 years (with
this pace), we shall make it optional for curious testers.
Orcan
4:01 p.m.
On Friday 24 April 2009 01:17:01 Adam Williamson wrote:
Why didn't you file a bug? If you don't report problems when you
experience them, how do you ever expect it to get better?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
This is why:
https://bugzilla.redhat.com/buglist.cgi?component=pulseaudio&product=...
There you'll find a *lot* of bugs related to pulseaudio.
And a few of them (about hogging resources and sound quality problems)
don't look like they will be fixed [soon].
Why? Cause they are being reported since the very begining, again and again.
Suren
4:48 p.m.
On Fri, 24.04.09 02:01, Suren Karapetyan (surenkarapetyan(a)gmail.com) wrote:
On Friday 24 April 2009 01:17:01 Adam Williamson wrote:
>
> Why didn't you file a bug? If you don't report problems when you
> experience them, how do you ever expect it to get better?
This is why:
https://bugzilla.redhat.com/buglist.cgi?component=pulseaudio&product=...
There you'll find a *lot* of bugs related to pulseaudio.
And a few of them (about hogging resources and sound quality problems)
don't look like they will be fixed [soon].
Why? Cause they are being reported since the very begining, again and again.
A long list of bugs bug reports is certainly a sign that your software
is used a lot, not so much that it is complete broken whcih you seem
to imply.
Also, what's the point of listing closed bugs?
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
4:58 p.m.
On Thu, Apr 23, 2009 at 5:48 PM, Lennart Poettering wrote:
On Fri, 24.04.09 02:01, Suren Karapetyan wrote:
>
> On Friday 24 April 2009 01:17:01 Adam Williamson wrote:
> >
> > Why didn't you file a bug? If you don't report problems when you
> > experience them, how do you ever expect it to get better?
>
> This is why:
> https://bugzilla.redhat.com/buglist.cgi?component=pulseaudio&product=...
> There you'll find a *lot* of bugs related to pulseaudio.
> And a few of them (about hogging resources and sound quality problems)
> don't look like they will be fixed [soon].
> Why? Cause they are being reported since the very begining, again and again.
A long list of bugs bug reports is certainly a sign that your software
is used a lot, not so much that it is complete broken whcih you seem
to imply.
He doesn't need to imply anything. Curseaudio is unbroken only in your
system(s) and possibly in a countably many other people's.
Also, what's the point of listing closed bugs?
They are not all closed. There are many OPEN's as well as WONTFIX' and
WORKSFORME's.
Please do lift this curse from Fedora. It is bad. It is broken to a
great extent. I'm glad I got rid of it before it started damaging my
hardware.
Pretty please!
Orcan
8:43 p.m.
On Thu, 2009-04-23 at 17:58 -0400, Orcan Ogetbil wrote:
Please do lift this curse from Fedora. It is bad. It is broken to a
great extent. I'm glad I got rid of it before it started damaging my
hardware.
Since you're being a bitch today, here's some karma: I rebooted earlier
this afternoon and my network didn't come up. Having caused a nice level
of domestic strife by rebooting the router and knocking my partner
offline, and then caused myself a lot of frustration by fiddling with
the router and my own system and even everything else connected by wifi
for an hour (and losing lots of valuable work time), I noticed rt2860
had been bumped to a new version. By you.
I went back to the old version, rebooted, and lo and behold - up came my
wireless.
SO YOU FUCKING BROKE MY SYSTEM YOU FUCKING BASTARD YOU SHOULD PAY!!!
11111!!!!!! YOU ARE NOT GOD! GIVE ME BACK MY AFTERNOON!
there, that didn't help anyone, did it? It's a bug. I'll go and
investigate a bit more later, and then I'll file it in the correct
location. I will not chase you down on mailing lists and denigrate your
hard work with expletive filled messages, and I suggest you refrain from
doing the same to others in future.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:46 p.m.
On Thu, 2009-04-23 at 18:43 -0700, Adam Williamson wrote:
there, that didn't help anyone, did it? It's a bug. I'll
go and
investigate a bit more later, and then I'll file it in the correct
location. I will not chase you down on mailing lists and denigrate your
hard work with expletive filled messages, and I suggest you refrain from
doing the same to others in future.
Sorry - I just went back through the thread and realized you weren't one
of the ones spreading profanities around. But still, calling it
'curseaudio', saying it's broken for everyone in the world, and claiming
it would break your hardware really isn't productive.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
9 p.m.
On Thu, Apr 23, 2009 at 9:43 PM, Adam Williamson wrote:
On Thu, 2009-04-23 at 17:58 -0400, Orcan Ogetbil wrote:
> Please do lift this curse from Fedora. It is bad. It is broken to a
> great extent. I'm glad I got rid of it before it started damaging my
> hardware.
Since you're being a bitch today, here's some karma: I rebooted earlier
this afternoon and my network didn't come up. Having caused a nice level
of domestic strife by rebooting the router and knocking my partner
offline, and then caused myself a lot of frustration by fiddling with
the router and my own system and even everything else connected by wifi
for an hour (and losing lots of valuable work time), I noticed rt2860
had been bumped to a new version. By you.
1- I repeatedly told folks that I DO NOT OWN THIS HARDWARE. I am just
maintaining the kmod because nobody else does and people need it. I
would be more than happy to give it away to someone who owns the
hardware and can do tests.
2- The issue has been reported and the package will not be pushed to
stable. If you are using rawhide, you should get used to such things.
3- However pulseaudio is not just in rawhide. It is in stable. Even
worse, it is enabled by DEFAULT! Even more worse, IT IS THE DEFAULT
SOUND SYSTEM IN FEDORA!!! I have every right to blame on who made this
happen. Pulseaudio is pure crap, rt2860 drivers aren't good but they
work (sometimes).
I went back to the old version, rebooted, and lo and behold - up came
my
wireless.
SO YOU FUCKING BROKE MY SYSTEM YOU FUCKING BASTARD YOU SHOULD PAY!!!
11111!!!!!! YOU ARE NOT GOD! GIVE ME BACK MY AFTERNOON!
I don't want to respond to this. Foul language belongs to its speaker.
there, that didn't help anyone, did it? It's a bug. I'll
go and
investigate a bit more later, and then I'll file it in the correct
location. I will not chase you down on mailing lists and denigrate your
hard work with expletive filled messages, and I suggest you refrain from
doing the same to others in future.
--
I do appreciate your work and your time spent on this. But swallow the
big bite. IT DID NOT WORK. So, please for the good of humanity, kill
this package.
I had to change my PhD thesis topic twice. Why? Because my
calculations didn't work out right (I couldn't disprove my theory
either). So I had to put hundreds of pages of calculations and more
than a year-full of work to trash, literally. It happens. I just
accepted the fact and worked on something else.
If you are using firefox, just start typing "pulseaudio is..." on the
search bar with google engine. You'll see what suggestions it will
give you along the way.
Best,
Orcan
9:17 p.m.
On Thu, 2009-04-23 at 22:00 -0400, Orcan Ogetbil wrote:
1- I repeatedly told folks that I DO NOT OWN THIS HARDWARE. I am
just
maintaining the kmod because nobody else does and people need it. I
would be more than happy to give it away to someone who owns the
hardware and can do tests.
2- The issue has been reported and the package will not be pushed to
stable. If you are using rawhide, you should get used to such things.
I know. The point is just about the appropriate way to respond to
problems.
I don't want to respond to this. Foul language belongs to its
speaker.
Yeah, as I said, I had you confused with Callum (and Lennart and
Bastien...) who'd been swearing their way through the thread. Very sorry
for that, entirely my fault.
> there, that didn't help anyone, did it? It's a bug.
I'll go and
> investigate a bit more later, and then I'll file it in the correct
> location. I will not chase you down on mailing lists and denigrate your
> hard work with expletive filled messages, and I suggest you refrain from
> doing the same to others in future.
> --
I do appreciate your work and your time spent on this. But swallow the
big bite. IT DID NOT WORK. So, please for the good of humanity, kill
this package.
I see I'm not the only one who gets confused :). I don't work on
Pulseaudio. I can barely fix a typo in a Python script, never mind hack
on sound architecture.
My only work on it has been running it for a long time (since it was
called PolypAudio) and complaining (constructively) to Lennart and Colin
Guthrie when something went wrong, and acting as a conduit for bug
reports from others. I just think it's fundamentally a project with most
of the right goals (even if I try and influence things here and there,
like in this debate) that we really need. Linux audio was a giant
horrible ball of pain before PulseAudio; in many ways it's still a giant
horrible ball of pain now, but PulseAudio is one of the bits that is
helping to get that changed. I don't think throwing the baby out with
the bathwater is the right idea.
If you are using firefox, just start typing "pulseaudio
is..." on the
search bar with google engine. You'll see what suggestions it will
give you along the way.
I spend large amounts of time in the places where such things get
posted, I know all the "pulseaudio is..." lines. However, I also
remember before Pulseaudio came along, there were just as many "Linux
is...." lines caused by people frustrated with the crappy way in which
sound is/was handled. I get as frustrated as Lennart does by people
whose first response to *any* kind of sound issue on *anyone's* system
is "oh, you need to remove Pulseaudio" - that kind of thing just isn't
helping anywhere. A lot of the anti-Pulse sentiment is multiplied by
this kind of thread to the point where people who never actually had any
problems with Pulse at all are parroting it all over the place. Pulse
has some problems, but it's also made a lot of things a lot better (I
wouldn't run my system without it now), and it'll continue to move in
the right direction in future.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
5:34 a.m.
On Thu, 2009-04-23 at 19:17 -0700, Adam Williamson wrote:
<snip>
Yeah, as I said, I had you confused with Callum (and Lennart and
Bastien...) who'd been swearing their way through the thread. Very sorry
for that, entirely my fault.
I didn't swear once. Remember, I'm passive-aggressive...
10:20 a.m.
On Fri, 2009-04-24 at 11:34 +0100, Bastien Nocera wrote:
On Thu, 2009-04-23 at 19:17 -0700, Adam Williamson wrote:
<snip>
> Yeah, as I said, I had you confused with Callum (and Lennart and
> Bastien...) who'd been swearing their way through the thread. Very sorry
> for that, entirely my fault.
I didn't swear once. Remember, I'm passive-aggressive...
Hmm, you're right. That cuts my swearing candidates down to two. Maybe I
just love swearing so much I was sticking it into other people's posts
in my head ;)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:32 a.m.
On Fri, 24.04.09 08:20, Adam Williamson (awilliam(a)redhat.com) wrote:
On Fri, 2009-04-24 at 11:34 +0100, Bastien Nocera wrote:
> On Thu, 2009-04-23 at 19:17 -0700, Adam Williamson wrote:
> <snip>
> > Yeah, as I said, I had you confused with Callum (and Lennart and
> > Bastien...) who'd been swearing their way through the thread. Very sorry
> > for that, entirely my fault.
>
> I didn't swear once. Remember, I'm passive-aggressive...
Hmm, you're right. That cuts my swearing candidates down to two. Maybe I
just love swearing so much I was sticking it into other people's posts
in my head ;)
Did I swear in this thread? Sure, I was sarcastic, but I didn't swear
unless I am starting to get forgetful.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
10:41 a.m.
On Fri, 2009-04-24 at 17:32 +0200, Lennart Poettering wrote:
> > I didn't swear once. Remember, I'm
passive-aggressive...
>
> Hmm, you're right. That cuts my swearing candidates down to two. Maybe I
> just love swearing so much I was sticking it into other people's posts
> in my head ;)
Did I swear in this thread? Sure, I was sarcastic, but I didn't swear
unless I am starting to get forgetful.
OK, since this is clearly the most important question ;), I went back
and checked. It's only Callum. I was misremembering based on his claim
that you and Bastien 'started it' - apparently he meant 'started it' in
the sense of 'disagreed with him'...
so everyone but Callum is pure as the driven snow and guilty only of a
hearty and robust exchange of ideas such as mailing lists were born
for :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:54 a.m.
On Fri, 2009-04-24 at 08:41 -0700, Adam Williamson wrote:
On Fri, 2009-04-24 at 17:32 +0200, Lennart Poettering wrote:
> > > I didn't swear once. Remember, I'm passive-aggressive...
> >
> > Hmm, you're right. That cuts my swearing candidates down to two. Maybe I
> > just love swearing so much I was sticking it into other people's posts
> > in my head ;)
>
> Did I swear in this thread? Sure, I was sarcastic, but I didn't swear
> unless I am starting to get forgetful.
OK, since this is clearly the most important question ;), I went back
and checked. It's only Callum. I was misremembering based on his claim
that you and Bastien 'started it' - apparently he meant 'started it' in
the sense of 'disagreed with him'...
so everyone but Callum is pure as the driven snow and guilty only of a
hearty and robust exchange of ideas such as mailing lists were born
for :)
The swearing is an expression of my frustration. Apparently swearing
completely invalidates everything I have to say. Point taken.
11:29 a.m.
On Thu, Apr 23, 2009 at 19:17:33 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
sound is/was handled. I get as frustrated as Lennart does by people
whose first response to *any* kind of sound issue on *anyone's* system
is "oh, you need to remove Pulseaudio" - that kind of thing just isn't
helping anywhere. A lot of the anti-Pulse sentiment is multiplied by
This so reminds me of selinux. The same thing happens with it (except with
access issues instead of sound issues).
9:14 a.m.
On Thu, 2009-04-23 at 17:58 -0400, Orcan Ogetbil wrote:
He doesn't need to imply anything. Curseaudio is unbroken only in
your
system(s) and possibly in a countably many other people's.
> Also, what's the point of listing closed bugs?
>
They are not all closed. There are many OPEN's as well as WONTFIX' and
WORKSFORME's.
Please do lift this curse from Fedora. It is bad. It is broken to a
great extent. I'm glad I got rid of it before it started damaging my
hardware.
Pretty please!
Orcan, I don't think this is very helpful.
I think many people have had similar experiences -- I actually disabled
PulseAudio completely in my own F-10 machines and especially my
father's, because audio was just too unreliable.
But Fedora is _supposed_ to be bleeding edge. It may have been a little
_too_ bleeding edge in that case, but it's also a lot better in F-11
than it used to be. A lot of work has gone into fixing the bugs, and
personally I'm determined to stick with it in F-11.
Amusingly, the first time I noticed PulseAudio actually 'doing its job'
and mixing multiple streams was completely counterproductive -- it was
when I was trying to give a presentation from OpenOffice, and because
the video was playing on both screens, so did the audio... slightly out
of sync with each other, giving me an echo :)
But still, I'm determined to stick with it. And I don't think that
attacking it on those grounds is particularly useful.
The issue which we _should_ address is how regressions are handled when
they're actually a _design_ issue in PulseAudio rather than simply a
bug. It's very disturbing that regressions are being marked as WONTFIX,
and I think we need to do better than that.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
10:19 a.m.
On Fri, Apr 24, 2009 at 10:14 AM, David Woodhouse wrote:
On Thu, 2009-04-23 at 17:58 -0400, Orcan Ogetbil wrote:
> He doesn't need to imply anything. Curseaudio is unbroken only in your
> system(s) and possibly in a countably many other people's.
>
> > Also, what's the point of listing closed bugs?
> >
>
> They are not all closed. There are many OPEN's as well as WONTFIX' and
> WORKSFORME's.
>
> Please do lift this curse from Fedora. It is bad. It is broken to a
> great extent. I'm glad I got rid of it before it started damaging my
> hardware.
>
> Pretty please!
Orcan, I don't think this is very helpful.
I think many people have had similar experiences -- I actually disabled
PulseAudio completely in my own F-10 machines and especially my
father's, because audio was just too unreliable.
But Fedora is _supposed_ to be bleeding edge. It may have been a little
_too_ bleeding edge in that case, but it's also a lot better in F-11
than it used to be. A lot of work has gone into fixing the bugs, and
personally I'm determined to stick with it in F-11.
Amusingly, the first time I noticed PulseAudio actually 'doing its job'
and mixing multiple streams was completely counterproductive -- it was
when I was trying to give a presentation from OpenOffice, and because
the video was playing on both screens, so did the audio... slightly out
of sync with each other, giving me an echo :)
But still, I'm determined to stick with it. And I don't think that
attacking it on those grounds is particularly useful.
The issue which we _should_ address is how regressions are handled when
they're actually a _design_ issue in PulseAudio rather than simply a
bug. It's very disturbing that regressions are being marked as WONTFIX,
and I think we need to do better than that.
David,
Had CA worked for me in just one case out of so many, I wouldn't
complain so strongly. Recently it started damaging my wife's data on
her computer (just hard-reboot your computer as if it was frozen 5
times a day for a month. I'm confident that you'll lose some data at
some point). I'm glad I shut it off before it damaged the hardware.
It is harmful. It is 100% crap. OK, maybe 99.999%, since it works for you guys.
I am all for bleeding edge. But CA is so immature that it doesn't have
a circulatory system yet. Thus it cannot bleed.
Orcan
8:08 a.m.
On Fri, 2009-04-24 at 11:19 -0400, Orcan Ogetbil wrote:
David,
Had CA worked for me in just one case out of so many, I wouldn't
complain so strongly. Recently it started damaging my wife's data on
her computer (just hard-reboot your computer as if it was frozen 5
times a day for a month. I'm confident that you'll lose some data at
some point). I'm glad I shut it off before it damaged the hardware.
It is harmful. It is 100% crap. OK, maybe 99.999%, since it works for
you guys.
I didn't say it worked for me. It doesn't -- in rawhide I can't even
turn the speakers up past about 80% of what they can do in F-10, and
many apps just silently (no pun intended) fail to make any noise when
they start up -- either because they fail to connect to PA, or because
PA either marks them as muted or sets their volume to zero.
The panel applet and the hotkeys in my GNOME session have stopped
working completely, too.
What I said is that I'm determined to persevere with it.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
8:38 p.m.
On Fri, 2009-04-24 at 02:01 +0500, Suren Karapetyan wrote:
On Friday 24 April 2009 01:17:01 Adam Williamson wrote:
>
> Why didn't you file a bug? If you don't report problems when you
> experience them, how do you ever expect it to get better?
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
> http://www.happyassassin.net
This is why:
https://bugzilla.redhat.com/buglist.cgi?component=pulseaudio&product=...
There you'll find a *lot* of bugs related to pulseaudio.
And a few of them (about hogging resources and sound quality problems)
don't look like they will be fixed [soon].
Why? Cause they are being reported since the very begining, again and again.
Interesting experiment. Let's do it my way:
[adamw@adam ~]$ bugzilla query -p Fedora -c pulseaudio --outputformat="%{bug_status}
%{resolution}" | sort
if you do that and take a look at the results...you get 372 bugs. 27 are
NEW, and 6 are ASSIGNED - so only 33 open bugs. 4 are CLOSED CANTFIX, 69
are CLOSED NOTABUG, 17 CLOSED INSUFFICIENT_DATA, 17 CLOSED WORKSFORME,
70 are CLOSED DUPLICATE - 177 that were considered and closed for
probably valid reasons. And: 15 are CLOSED CURRENTRELEASE, 5 are CLOSED
ERRATA, 6 are CLOSED NEXTRELEASE and 92 are CLOSED RAWHIDE - that's 118
that were fixed. 25 are CLOSED UPSTREAM.
I don't see anything particularly wrong with those numbers. Obviously a
lot of valid bugs have been filed and properly fixed. The amount that
are currently outstanding is not at all unreasonable as a proportion of
the total, and not an unmanageable number of bugs taken absolutely. I
suspect you'd see very similar proportions if you looked at, say, all
kernel bugs, or all X bugs.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:24 a.m.
On Friday 24 April 2009 06:38:52 Adam Williamson wrote:
I don't see anything particularly wrong with those numbers. Obviously a
lot of valid bugs have been filed and properly fixed. The amount that
are currently outstanding is not at all unreasonable as a proportion of
the total, and not an unmanageable number of bugs taken absolutely. I
suspect you'd see very similar proportions if you looked at, say, all
kernel bugs, or all X bugs.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
The important part is not numbers.
Much more important is what that bugs are about.
Try to find bugs with keys "skipping" "choppy" "lag"
"crackling".
You'll find a few NEW bugs but you'll also find a lot of CLOSED bugs.
This "about skipping" bugs are reported every few weeks.
Soon they're closed. A week later they are reported again.
Will it help if I reply to each of that bugs with "me too"?
And let me state again: I don't find the situation with ALSA good.
I'm sure there is a need for a system-wide sound server,
and PA may become that server. I enjoy the way projectM-pulse works.
But for now (for me)
NO PA = One application can use the sound card
and that application works as expected.
PA = Many applications can use the sound card at once,
but none of them works as expected - a combination of clicking,
fast playback, kaffeine eating CPU and memory and no sound input.
The fact that PA is default makes me fill like someone
is using me as a sea-hog to test alpha software.
But I may even agree with that situation.
The thing I don't like at all, is when you say PA has (big) problems
and PA maintainers tell you that there are no problems and if you have
one you should report it and it will be fixed (at once),
and if it isn't fixed then you're a minority and you are not important.
Suren
8:56 a.m.
On Fri, 24.04.09 16:24, Suren Karapetyan (surenkarapetyan(a)gmail.com) wrote:
The important part is not numbers.
Ah, so it's more about anecdotes?
Much more important is what that bugs are about.
Try to find bugs with keys "skipping" "choppy" "lag"
"crackling".
You'll find a few NEW bugs but you'll also find a lot of CLOSED bugs.
This "about skipping" bugs are reported every few weeks.
Soon they're closed. A week later they are reported again.
If you make accusations of me handling bug reports incorrectly, how
about actually providing references to real bug reports? Otherwise what
you do is simple slander.
I'm sure there is a need for a system-wide sound server,
PA is not a system-wide sound server.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
10:15 a.m.
On Fri, 2009-04-24 at 16:24 +0500, Suren Karapetyan wrote:
The important part is not numbers.
Much more important is what that bugs are about.
Try to find bugs with keys "skipping" "choppy" "lag"
"crackling".
You'll find a few NEW bugs but you'll also find a lot of CLOSED bugs.
This "about skipping" bugs are reported every few weeks.
Soon they're closed. A week later they are reported again.
Will it help if I reply to each of that bugs with "me too"?
Similar symptoms != identical bugs.
The thing I don't like at all, is when you say PA has (big)
problems
and PA maintainers tell you that there are no problems and if you have
one you should report it and it will be fixed (at once),
and if it isn't fixed then you're a minority and you are not important.
I haven't seen any PA developer say it has no bugs, or that all bugs
will be fixed immediately. That'd just be a silly thing for any
developer to say.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:36 p.m.
On Sun, Apr 26, 2009 at 4:17 AM, Kevin Kofler wrote:
Orcan Ogetbil wrote:
> Seriously, given hundreds of threads in fedoraforum, people
> complaining about pulseaudio, we do need to discuss how to remove
> pulseaudio from Fedora (not whether we should remove it).
PulseAudio is not going away. Sorry.
Kevin Kofler
Oh, sooner or later it will. We will not let Linux die because of this crap.
I consider this first wave to be successful as it made some people
aware of the situation. 6 months from now when the F-12 is about to be
released, if the pulseaudio is still crap (and I'm pretty sure it will
be), the second wave will be more brutal. Remember that.
Orcan
3:12 p.m.
On Thu, 2009-04-23 at 14:19 -0500, Callum Lerwick wrote:
On Thu, 2009-04-23 at 01:31 +0200, Lennart Poettering wrote:
> On Wed, 22.04.09 14:51, Callum Lerwick (seg(a)haxxed.com) wrote:
>
> > > > > > Can I at least get a secret gconf key to do what
> > > > > > I want? :P
> > > > >
> > > > > The volume control uses PulseAudio, it doesn't use ALSA
directly
> > > > > anymore, so no, there's no secret GConf key for that.
> > > >
> > > > So a PulseAudio config option then. Do I have to write the patch
myself?
> > >
> > > Probably not a PA config option either.
> > >
> > > The volume control applet will show a mixer for input devices if an
> > > application is recording on it. You'd just need to make the mixer
think
> > > that something is recording on that device. I'm not sure how to do
that,
> > > but Lennart might.
> >
> > No, you are misunderstanding. I don't want to adjust the input volume. I
> > want it left alone. I want the master left alone. Master stays at 0dB,
> > Line stays at 0dB. I want PA to dink with PCM instead of Master.
>
> You can pass a parameter (control=) when loading the PA ALSA plugin
> (module-alsa-sink) which specifies the ALSA mixer element to
> choose. It's intended to be used as a hackish work-around for drivers
> that don't name their controls properly.
THANK YOU. That is *ALL* I was asking for at the start of this thread.
This whole thread could have been accomplished with one polite useful
reply. But no, Bastien Nocera had to escalate it in to a dickfest.
$ pulseaudio
E: module.c: Failed to load module "module-alsa-sink" (argument:
"control=PCM"): initialization failed.
E: main.c: Module load failed.
E: main.c: Failed to initialize daemon.
So how the shit do I make it work?
> And as mentioned there's a workaround, you can specify the control for
> a sink. But using that will break device autodetecting and hence the
> whole profile logic. BTW, that option was contributed by someone with a
> weird driver who supplied me with a patch. He didn't whine on a huge
> thread on a mailing list, but just prepared a patch. Could be a good
> role model for some other folks, don't you think?
Fuck you.
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
I really don't think we need this kind of language and attitude on this
list. Please take a day or two off to cool down.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
11:48 a.m.
New subject: [SOLVED] Re: Fedora 11 nerfed my mixer
On Sun, 2009-04-26 at 11:26 -0500, Callum Lerwick wrote:
On Sun, 2009-04-26 at 10:16 +0200, Kevin Kofler wrote:
> Callum Lerwick wrote:
> > E: module.c: Failed to load module "module-alsa-sink" (argument:
> > "control=PCM"): initialization failed.
>
> Try putting (double) quotes around "PCM".
Well holy crap it works! Thanks, Lennart!
For those playing along at home, the full solution is:
Copy /etc/pulse/default.pa to ~/.pulse/ . You have to copy the whole
thing and edit or PA doesn't work.
Look for this line:
### Load audio drivers statically (it's probably better to not load
### these drivers manually, but instead use module-hal-detect --
### see below -- for doing this automatically)
#load-module module-alsa-sink
Uncomment it and edit it to something like:
load-module module-alsa-sink device=hw:M5455,0 control="PCM"
The device= thing is technically optional, but if you don't put it in
you just see "dmix:0" in the UI. You probably don't want pulseaudio
going through dmix anyway.
As Lennart pointed out, you can look in /proc/asound/cards to find the
name of your card, so you don't have to hard code indexes:
$ cat /proc/asound/cards
0 [M5455 ]: ICH - ALi M5455
ALi M5455 with ALC850 at irq 18
1 [au8830 ]: au8830 - Aureal Vortex au8830
Aureal Vortex au8830 at 0xea000000 irq 20
10 [UART ]: MPU-401 UART - MPU-401 UART
MPU-401 UART at 0x330, irq 10
12:44 p.m.
New subject: [SOLVED] Re: Fedora 11 nerfed my mixer
On Sun, 26.04.09 11:48, Callum Lerwick (seg(a)haxxed.com) wrote:
load-module module-alsa-sink device=hw:M5455,0
control="PCM"
Please don't use hw: as device string prefix. Use 'front:' or
'surround41:' or something like that. 'hw:' gives you the naked device
and implies no particular channel order or number of
channels. The other mentioned strings do imply that and hence work
everywhere and not just on one specific piece of hardware.
Please only specify card identifiers, not device indexes. I.e. drop
the ",0" from the device string. Specifying device indexes gives you
the naked device and implies no specific output. If you use "front:"
or "spdif:" a particular output is implied and hence the proper device
automatically selected for you which makes this work on more than once
specific piece of hardware.
In summary, use 'device=front:M5455" as parameter.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
3:25 p.m.
On Thu, 23 Apr 2009, Lennart Poettering wrote:
We want to control the 'outermost' volume slider. Because
that's the
one that most likely controls the actual analog amplifier if there is
any. Controlling 'PCM' is kind of pointless on most modern cards since
it is implemented digitally.
Surely a nice thing in theory.
But in reality, it's not always that clear.
I recently had a dual boot system with rawhide and windows.
Windows sound was fine, right volume et all. Volume knob at the speakers
was at 50% and the software mixer at 75%.
Now booting to Linux, sound is barely audible. Turning up the volume to
100% in the mixer and turning the speakers to full was barely enough to
understand the music.
Using an alsa mixer to turn up the PCM volume to 100% somewhat fixed that.
But turning to an alsamixer to work around a problem with the current
pamixer can't be a long term solution.
What is the long term way? And no, I don't care for F11. Releases are
overrated anyway.
regards,
andreas
3:46 p.m.
On Thu, 2009-04-23 at 22:25 +0200, Andreas Thienemann wrote:
On Thu, 23 Apr 2009, Lennart Poettering wrote:
> We want to control the 'outermost' volume slider. Because that's the
> one that most likely controls the actual analog amplifier if there is
> any. Controlling 'PCM' is kind of pointless on most modern cards since
> it is implemented digitally.
Surely a nice thing in theory.
But in reality, it's not always that clear.
I recently had a dual boot system with rawhide and windows.
Windows sound was fine, right volume et all. Volume knob at the speakers
was at 50% and the software mixer at 75%.
Now booting to Linux, sound is barely audible. Turning up the volume to
100% in the mixer and turning the speakers to full was barely enough to
understand the music.
Using an alsa mixer to turn up the PCM volume to 100% somewhat fixed that.
But turning to an alsamixer to work around a problem with the current
pamixer can't be a long term solution.
What is the long term way? And no, I don't care for F11. Releases are
overrated anyway.
The long term way is that your situation is a bug, probably a bug in
ALSA, and should be reported as such.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:50 p.m.
On Thu, 23.04.09 22:25, Andreas Thienemann (andreas(a)bawue.net) wrote:
Heya,
Windows sound was fine, right volume et all. Volume knob at the
speakers
was at 50% and the software mixer at 75%.
Now booting to Linux, sound is barely audible. Turning up the volume to
100% in the mixer and turning the speakers to full was barely enough to
understand the music.
Using an alsa mixer to turn up the PCM volume to 100% somewhat fixed that.
But turning to an alsamixer to work around a problem with the current
pamixer can't be a long term solution.
What is the long term way? And no, I don't care for F11. Releases are
overrated anyway.
Firstly the alsa mixer init database should have set up your system
correctly. The database is incomplete unfortunately since most people
don't send in a patch for the db after they fixed those settings
manually. After running alsamixer -c0 alsa will remember and hence
they never get annoyed by that anymore so they don't remember to post
this anymore.
However my plans for F12 should hopefully help to make this issue go
away: on many machines we have quite a few volume controls in
series. e.g. on Thinkpads there is the hw volume that is controlled by
those magic keys, and then there is master, and then there is PCM. My
plan is to collapse them all into a single slider which is possible if
we have dB information about the sliders. The resulting slider would
be the multiplication of the seperate sliders. This would both
increase the range and the granularity of the overall volume slider
and also allows us to fix the mixer initialization issue a bit since
we would control both PCM and Master.
This should fix a lot of problems for a lot of people. However it will
of course also annoy Mr. Lerwick. But I fear I have to live with that
I guess.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
4:01 p.m.
On Thu, Apr 23, 2009 at 22:50, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Thu, 23.04.09 22:25, Andreas Thienemann (andreas(a)bawue.net)
wrote:
Heya,
> Windows sound was fine, right volume et all. Volume knob at the speakers
> was at 50% and the software mixer at 75%.
>
> Now booting to Linux, sound is barely audible. Turning up the volume to
> 100% in the mixer and turning the speakers to full was barely enough to
> understand the music.
>
> Using an alsa mixer to turn up the PCM volume to 100% somewhat fixed that.
>
> But turning to an alsamixer to work around a problem with the current
> pamixer can't be a long term solution.
>
> What is the long term way? And no, I don't care for F11. Releases are
> overrated anyway.
Firstly the alsa mixer init database should have set up your system
correctly. The database is incomplete unfortunately since most people
don't send in a patch for the db after they fixed those settings
manually. After running alsamixer -c0 alsa will remember and hence
they never get annoyed by that anymore so they don't remember to post
this anymore.
Are you saying that I should open a bug saying something like « on
Fedora 11, audio was barely audible. I run alsamixer and set all
channels to the max, now it's a little better » ?
Is so, I'll happily go and open one right now :)
----------
Mathieu Bridon (bochecha)
4:20 p.m.
On Thu, 23.04.09 23:01, Mathieu Bridon (bochecha) (bochecha(a)fedoraproject.org) wrote:
> Firstly the alsa mixer init database should have set up your
system
> correctly. The database is incomplete unfortunately since most people
> don't send in a patch for the db after they fixed those settings
> manually. After running alsamixer -c0 alsa will remember and hence
> they never get annoyed by that anymore so they don't remember to post
> this anymore.
Are you saying that I should open a bug saying something like « on
Fedora 11, audio was barely audible. I run alsamixer and set all
channels to the max, now it's a little better » ?
Is so, I'll happily go and open one right now :)
Yes, it would be good if you would open a bug report about this. No it
wouldn't be good if you'd post it like that.
Identify which control exactly was incorrectly initialized. Identify a
good value for it. And then describe exactly which card you have, and
file a bug against alsa-utils.
Even better, have a working patch ready for alsa-utils. Most folks
will probably have to add a few lines to /lib/alsa/init/hda and that's
about it. The syntax is similar to udev rules. Just read that file and
you should be able to deduce the format it is written in. Then use
'alsactl init' to test your changes.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
4:24 p.m.
On Thu, 23.04.09 23:20, Lennart Poettering (mzerqung(a)0pointer.de) wrote:
> Are you saying that I should open a bug saying something like «
on
> Fedora 11, audio was barely audible. I run alsamixer and set all
> channels to the max, now it's a little better » ?
>
> Is so, I'll happily go and open one right now :)
Yes, it would be good if you would open a bug report about this. No it
wouldn't be good if you'd post it like that.
Identify which control exactly was incorrectly initialized. Identify a
good value for it. And then describe exactly which card you have, and
file a bug against alsa-utils.
Let me add that 'alsa-info.sh --no-upload' is a good source of
information for identifying audio devices for these rules.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
8:39 p.m.
On Thu, 2009-04-23 at 23:01 +0200, Mathieu Bridon (bochecha) wrote:
> Firstly the alsa mixer init database should have set up your
system
> correctly. The database is incomplete unfortunately since most people
> don't send in a patch for the db after they fixed those settings
> manually. After running alsamixer -c0 alsa will remember and hence
> they never get annoyed by that anymore so they don't remember to post
> this anymore.
Are you saying that I should open a bug saying something like « on
Fedora 11, audio was barely audible. I run alsamixer and set all
channels to the max, now it's a little better » ?
Is so, I'll happily go and open one right now :)
Well yes, but if it's only a *little* better - i.e. if, with all
channels maxed in alsamixer and everything maxed in pavucontrol / g-v-m,
the sound's still pretty quiet - it would seem like there's a more
fundamental bug happening somewhere.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:03 p.m.
Hi,
On Thu, 23 Apr 2009, Lennart Poettering wrote:
Thank you for the quick reply.
[ Differences in volume level between Windows and Rawhide ]
Firstly the alsa mixer init database should have set up your system
correctly. The database is incomplete unfortunately since most people
don't send in a patch for the db after they fixed those settings
manually. After running alsamixer -c0 alsa will remember and hence
they never get annoyed by that anymore so they don't remember to post
this anymore.
Okay. So fixing the database entry would solve that. Now, what data do I
need to extract from my system and where do I have to send that?
However my plans for F12 should hopefully help to make this issue go
away: on many machines we have quite a few volume controls in
series. e.g. on Thinkpads there is the hw volume that is controlled by
those magic keys, and then there is master, and then there is PCM. My
plan is to collapse them all into a single slider which is possible if
we have dB information about the sliders. The resulting slider would
be the multiplication of the seperate sliders. This would both
increase the range and the granularity of the overall volume slider
and also allows us to fix the mixer initialization issue a bit since
we would control both PCM and Master.
At least to me that sounds somewhat sensible. But I'm no audio guy. :)
But as it's a long term solution, the short term solution for me would
still be the alsa database.
regards,
andreas
6:53 a.m.
On Thursday 23 April 2009 21:50:57 Lennart Poettering wrote:
However my plans for F12 should hopefully help to make this issue go
away: on many machines we have quite a few volume controls in
series. e.g. on Thinkpads there is the hw volume that is controlled by
those magic keys, and then there is master, and then there is PCM. My
plan is to collapse them all into a single slider which is possible if
we have dB information about the sliders. The resulting slider would
be the multiplication of the seperate sliders. This would both
increase the range and the granularity of the overall volume slider
and also allows us to fix the mixer initialization issue a bit since
we would control both PCM and Master.
...this is not the right way to go.
Often, doing so with (say) a high-level CD input, will lead to clipping
somewhere in the hardware as soon as you add another signal. You have more than
one volume control for a reason.
This should fix a lot of problems for a lot of people. However it
will
of course also annoy Mr. Lerwick. But I fear I have to live with that
I guess.
This is - perhaps understandably, from reading the preceding discussion - being
completely dismissive of a real user with, from his point of view, a valid
complaint and use case. What makes him (and I, and others) upset is the clear
fact that you're not interested in "supporting" our use-cases *at all* ...
and
we don't have any particularly bizarre needs.
9:18 a.m.
On Fri, 24.04.09 12:53, Bill Crawford (billcrawford1970(a)gmail.com) wrote:
> those magic keys, and then there is master, and then there is
PCM. My
> plan is to collapse them all into a single slider which is possible if
> we have dB information about the sliders. The resulting slider would
> be the multiplication of the seperate sliders. This would both
> increase the range and the granularity of the overall volume slider
> and also allows us to fix the mixer initialization issue a bit since
> we would control both PCM and Master.
...this is not the right way to go.
You are wrong.
Often, doing so with (say) a high-level CD input, will lead to
clipping
somewhere in the hardware as soon as you add another signal. You have more than
one volume control for a reason.
Uh?
Not sure if I get what you exactly want, but let me say three things:
Firstly I believe that playing audio cds via the classic 'analog' path
is obsolete. CDs should be ripped sector by sector and played as PCM
streams to the sound card. Only that allows flexibly moving cd audio
between different sound cards and makes it possible to handle external
usb disk drives correctly.
Secondly, the logic to select the volumes for the various sliders is
going from the outermost slider to the innermost always coming closer
to the actual volume you want to achieve. That means that the
outermost (hopefully analog) slider will do the 'biggest' part of the
volume adjustment while the remaining sliders (usually digital) are
mostly initialized to 0dB or shortly below. That's the best thing to
avoid clipping in the hw.
Thirdly: of course if you mix several 16bit streams into one 16bit
stream you might end up with clipping. It's not as tragic as it sounds
however: most of them time only one stream plays, and usually for good
CDs the average signal level has enough headroom to allow mixing at
least two streams without clipping. And finally there are plans to add
a simple range comrpession scheme to the mixing process for the cases
where clipping might happen.
> This should fix a lot of problems for a lot of people. However
it will
> of course also annoy Mr. Lerwick. But I fear I have to live with that
> I guess.
This is - perhaps understandably, from reading the preceding discussion - being
completely dismissive of a real user with, from his point of view, a valid
complaint and use case. What makes him (and I, and others) upset is the clear
fact that you're not interested in "supporting" our use-cases *at all* ...
and
we don't have any particularly bizarre needs.
As mentioned there's always 'alsamixer'.
Please don't claim I wouldn't listen. You are confusing 'listening'
with 'agreeing'. I am aware of this uncomon use-case of using a sound
card as a hw mixer for line-in. And I have decided it is a use-case
that is out of scope for PA.
Now, what about you folks and listening? You keep repeating the same
thing over and over again. And I respond the same and the same thing
over and over again: we don't make the uncommon uses impossible. All
we do is we make the common uses simple. And we leave enough tools for
the uncommon uses: 'alsamixer' or a similar tool that exposes the full
ALSA control set.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
8:58 a.m.
On Thu, 2009-04-23 at 22:50 +0200, Lennart Poettering wrote:
Firstly the alsa mixer init database should have set up your system
correctly. The database is incomplete unfortunately since most people
don't send in a patch for the db after they fixed those settings
manually.
Your database will _always_ be incomplete. There will _always_ be new
hardware, and users will _always_ have to tweak things manually.
You can do well, and it's a wonderful thing to be doing -- but you
_have_ to accept that you can't get it right in all cases, so you have
to let the user fix it.
However my plans for F12 should hopefully help to make this issue go
away: on many machines we have quite a few volume controls in
series. e.g. on Thinkpads there is the hw volume that is controlled by
those magic keys, and then there is master, and then there is PCM. My
plan is to collapse them all into a single slider which is possible if
we have dB information about the sliders. The resulting slider would
be the multiplication of the seperate sliders. This would both
increase the range and the granularity of the overall volume slider
and also allows us to fix the mixer initialization issue a bit since
we would control both PCM and Master.
That sounds like a recipe for disaster to me. I've often had to play
around with levels for PCM vs. Master vs. other things to maximise the
resulting volume¹ without introducing distortion -- you're effectively
downgrading my audio capabilities unless you _always_ get it absolutely
right. On which topic, see above.
And then factor in the observation that we're talking about analogue
circuitry and physical devices which will even vary a little from one
machine to the next machine off the production line. Not to mention what
my ears can detect. Your database _cannot_ know.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
¹ And that's even without the bit where I plug in external speakers and
want to use those in _addition_ to the internal ones, which PA also
breaks.
9:45 a.m.
On Fri, 24.04.09 14:58, David Woodhouse (dwmw2(a)infradead.org) wrote:
On Thu, 2009-04-23 at 22:50 +0200, Lennart Poettering wrote:
> Firstly the alsa mixer init database should have set up your system
> correctly. The database is incomplete unfortunately since most people
> don't send in a patch for the db after they fixed those settings
> manually.
Your database will _always_ be incomplete. There will _always_ be new
hardware, and users will _always_ have to tweak things manually.
You can do well, and it's a wonderful thing to be doing -- but you
_have_ to accept that you can't get it right in all cases, so you have
to let the user fix it.
Yes. I am aware of that. That's one of the reasons there is alsamixer
shipped with our distro.
> However my plans for F12 should hopefully help to make this
issue go
> away: on many machines we have quite a few volume controls in
> series. e.g. on Thinkpads there is the hw volume that is controlled by
> those magic keys, and then there is master, and then there is PCM. My
> plan is to collapse them all into a single slider which is possible if
> we have dB information about the sliders. The resulting slider would
> be the multiplication of the seperate sliders. This would both
> increase the range and the granularity of the overall volume slider
> and also allows us to fix the mixer initialization issue a bit since
> we would control both PCM and Master.
That sounds like a recipe for disaster to me. I've often had to play
around with levels for PCM vs. Master vs. other things to maximise the
resulting volume¹ without introducing distortion -- you're effectively
downgrading my audio capabilities unless you _always_ get it absolutely
right. On which topic, see above.
And then factor in the observation that we're talking about analogue
circuitry and physical devices which will even vary a little from one
machine to the next machine off the production line. Not to mention what
my ears can detect. Your database _cannot_ know.
This has nothing to do with 'my' database.
If you ever had a look at alsamixer you'd have seen that it shows dB
values for most sliders. While for the 'outermost' sliders it is not
clear relative to what reference level those dB values are it is for
the more innerwards (i.e. usually digitally implemented) sliders:
0dB mens no amplification, no attenuation.
As already explained the algorithm for initializing that series of
sliders is to go from outermost to innermost and doing the 'biggest'
part of the volume adjustment on the more outermust sliders and doing
adjustments on the more innerwards only if the outermost cannot do it
due to limitations in range or granularity. That should make sure that
the more innerwards sliders (the digital ones) are usually initialized
to 0dB and hence do not have any detrimental effect on audio quality.
Also, pavucontrol shows the 'base volume' in the UI, i.e. the point
were the all sliders are at 0dB.
I am pretty confident that the dB information is pretty reliable since
often it comes from the hw itself and Visa relies on it, too. Since
vendors test their stuff against Vista this makes them as reliable as
it could get.
If ALSA cannot provide us with the dB information for a specific card
this algorithm will of course not be used.
In summary: I am pretty sure your fears are unfounded.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
10:18 a.m.
This has been a very funny thread. Thank you to whoever started it, I needed
a laugh.
Lennart, your baby is ugly, your baby has always been ugly, its not likely
to get any better looking for a long time if ever. I like how you advise
people what they should and should not be doing with their hardware, clearly
only you what is best for us. I also like "just wait in F12 it will be
better guys I promise!" You are a funny guy, you should take that show on
the road.
I noticed FESco will be discussing just how well you know best later today.
How long do we remain your alpha testers until you get PA in a state worthy
of shipping with fedora? Let me guess F12 right? lol, you kill me.
We'd of all been better off if PA had never been created, our only hope now
is that it dies the quick death. To much to hope for I know but everyone has
to have a dream. For now we can just remove it and drive on.
@ all those saying file bug reports, I say why file reports against
something not worth the time or effort? Don't install it to begin with and
you'll be better off.
TK009
11:29 a.m.
On Fri, 2009-04-24 at 16:45 +0200, Lennart Poettering wrote:
Yes. I am aware of that. That's one of the reasons there is
alsamixer
shipped with our distro.
But Lennart, this is not an option for the general Joe. I've used Linux
exclusively for more than 13 years, and I wasn't even aware of this
alsamixer until recently when _you_ mentioned it to me.
For most people, if it's not easily accessible from a convenient UI
(the Volume Control in this case), it _does_not_exist_. And it should
be this way.
For crying out loud, how would someone know to open up a terminal
and run this obscure problem? How would they know about it?
In F8 at least I could control all that from the Volume Control, as
crappy as that was. As soon as I upgraded to F11, I was lost! I had
to file a bug report https://bugzilla.redhat.com/show_bug.cgi?id=493790
just to find out about alsamixer! (BTW, this was the problem Dave was
mentioning: the DB was missing entries, and for a very standard piece of
HW, and the user was toast)
I know you mean well by trying to simplify this entire mess (I hated the
old Volume Control, it was too much), but on the other hand this seems
to be a messy problem and taking too much control from the user is a
mistake. At least that's what my intuition is telling me, FWIW.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
11:58 a.m.
On Fri, 24.04.09 12:29, Dimi Paun (dimi(a)lattica.com) wrote:
For crying out loud, how would someone know to open up a terminal
and run this obscure problem? How would they know about it?
By reading the release notes?
I know you mean well by trying to simplify this entire mess (I hated
the
old Volume Control, it was too much), but on the other hand this seems
to be a messy problem and taking too much control from the user is a
mistake. At least that's what my intuition is telling me, FWIW.
If we don' try to fix it then this will never be fixed.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
12:07 p.m.
On Fri, 2009-04-24 at 18:58 +0200, Lennart Poettering wrote:
> For crying out loud, how would someone know to open up a
terminal
> and run this obscure problem? How would they know about it?
By reading the release notes?
Oh, please. Do you think that most people even _know_ what PA is
or what it does? Who has the time or interest to read tons of
release notes, and _remember_ this obscure alsamixer thing?
Most folks expect to be able to get sound out of their box without
reading *anything* -- just by clicking on things that should be pretty
obvious withing 5-10s of looking at the computer.
And that's the way it should be.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
12:30 p.m.
Some OffTopic comment.
A while ago I bought a brand new notebook and the audio hardware
wasn't supported( actually I had to give the correct model= option).
So it took me about 10 minutes to get a pulseaudio server on my
roommate's windows machine and even that my machine couldn't play
audio I had very easy solution if I wanted to listen to some music.
Later on I had working audio but my roommate had some nice 5.1 system
so I also used that without having to plug-unplug the audio from one
machine to another all the time .
So since fedora9 until latest rawhide pulseaudio worked flawlessly for me.
I think it's good to know that there are happy users out there and I
know a lot who are.
--
NV
12:55 p.m.
2009/4/24 Nikolay Vladimirov <nikolay(a)vladimiroff.com>:
Some OffTopic comment.
A while ago I bought a brand new notebook and the audio hardware
wasn't supported( actually I had to give the correct model= option).
So it took me about 10 minutes to get a pulseaudio server on my
roommate's windows machine and even that my machine couldn't play
audio I had very easy solution if I wanted to listen to some music.
Later on I had working audio but my roommate had some nice 5.1 system
so I also used that without having to plug-unplug the audio from one
machine to another all the time .
So since fedora9 until latest rawhide pulseaudio worked flawlessly for me.
I think it's good to know that there are happy users out there and I
know a lot who are.
I'd also like to add similar experiences about Pulseaudio.
Things I like about Pulseaudio:
When visiting my parents, I was very happy with Pulseaudio in my
Laptop being able to play music over the wlan to a desktop computer
that was running Fedora and Pulseaudio. It was easy to set up, and
worked quite reliably.
I can play sounds from multiple programs simultaneously.
I can adjust every program's volume independently of the others.
I can use pavucontrol to see if a silence is the result of a program
not talking to PA correctly, or if it has something to do with volumes
being too low or speakers off, etc.
Even Wine seems to talk nicely to Pulse nowadays.
I can plug in a USB headset, it works out of the box, and I can
immediately move the output of appropriate programs to them.
I can unplug the USB headset, with their streams being automatically
redirected to another output, if one is available.
Contrary to the experiences of some people on this list, Pulseaudio
seems to be quite compatible with different hardware and sound
drivers. My laptop and desktop currently have it running flawlessly,
with no manual configuration required. The desktop at my parents'
place has it working good, as far as I can tell with the little use
that I have done there. My girlfriend hasn't complained about it on
her laptop either, though she doesn't use the audio features very
much.
Pulseaudio is very nice in an LTSP setup.
Things that I don't like about Pulseaudio:
I had some problems with sound stuttering in early F10, in the new
glitch-free Pulseaudio. However, these got eventually fixed a couple
of months ago.
Some pieces of software seem harder to get behave well with
Pulseaudio. Hard ones have been some games in Wine, Ekiga (fixed now),
Audacity (I hear it's nowadays better) and some native Linux games
(None that I play currently have issues, though).
On the whole, I am anyway very pleased with Pulseaudio, and I look
forward to the remaining issues eventually getting resolved, so that
as many as possible can enjoy the good features that it offers.
--
Joonas Sarajärvi
muepsj(a)gmail.com
4:45 p.m.
On 2009-04-24, 17:55 GMT, Joonas Sarajärvi wrote:
Things I like about Pulseaudio:
I got almost a heart attack when Windows 7 Beta (yeah I know,
I am just curious about our enemy ;-)) in KVM guest machine
started to play sounds to my speakers! (totally out of the box,
I did not even know it is possible) Is it possible to do
something like that without PA?
Matej
5:49 p.m.
On Sat, 2009-04-25 at 23:45 +0200, Matej Cepl wrote:
On 2009-04-24, 17:55 GMT, Joonas Sarajärvi wrote:
> Things I like about Pulseaudio:
I got almost a heart attack when Windows 7 Beta (yeah I know,
I am just curious about our enemy ;-)) in KVM guest machine
started to play sounds to my speakers! (totally out of the box,
I did not even know it is possible) Is it possible to do
something like that without PA?
KVM is based around qemu isn't it? qemu's been able to simulate sound
cards for some time. It'll happily output to ALSA and I think OSS and/or
SDL. Maybe it has native PA support by now.
So no, you don't need PA for that.
11:22 a.m.
2009/4/25 Matej Cepl <mcepl(a)redhat.com>:
On 2009-04-24, 17:55 GMT, Joonas Sarajärvi wrote:
> Things I like about Pulseaudio:
I got almost a heart attack when Windows 7 Beta (yeah I know,
I am just curious about our enemy ;-)) in KVM guest machine
started to play sounds to my speakers! (totally out of the box,
I did not even know it is possible) Is it possible to do
something like that without PA?
I found that when a centOS KVM guest was running, my mythTV on the
host OS couldn't play any sounds, I honestly can't remember if I had
removed pluseaudio or not (not because it's bad but merely because I
don''t need its features on what was originally a dedicated HTPC box).
2:03 p.m.
On Sun, Apr 26, 2009 at 10:22 AM, Andy Burns <fedora.lists(a)burns.me.uk> wrote:
I found that when a centOS KVM guest was running, my mythTV on the
host OS couldn't play any sounds, I honestly can't remember if I had
removed pluseaudio or not (not because it's bad but merely because I
don''t need its features on what was originally a dedicated HTPC box).
Could this be the problem?
https://bugzilla.redhat.com/show_bug.cgi?id=477955
--
Jerry James
http://loganjerry.googlepages.com/
http://jjames.fedorapeople.org/
6:17 a.m.
On Fri, 2009-04-24 at 18:58 +0200, Lennart Poettering wrote:
> I know you mean well by trying to simplify this entire mess (I hated the
> old Volume Control, it was too much), but on the other hand this seems
> to be a messy problem and taking too much control from the user is a
> mistake. At least that's what my intuition is telling me, FWIW.
If we don' try to fix it then this will never be fixed.
I agree -- it is a wonderful thing that we're trying to fix this, and I
applaud your efforts.
But we have to acknowledge that we cannot always get it 100% right, and
that we _do_ need to let the user have ultimate control.
Even ignoring the 'esoteric' use cases, I don't think we're ever going
to see an end to bugs like #493790 or the last part of #497698.
It's all very well saying that the ALSA hardware database should know
everything -- but it _doesn't_, and realistically speaking it never
will.
It doesn't even know about the 'Front' control on my MacBook Pro -- so
if I didn't have gnome-alsamixer, the F-11 installation would just be
inexplicably quieter than F-10 was.
You can argue that that's a bug in the database, and even that it's
someone _else's_ database so it's not your problem. And you'd be right,
to a certain extent.
But you seem to be missing the point that there will _always_ be bugs in
the database, and it's _your_ code which has suddenly promoted that
database from being a 'convenience' to a 'mission critical' thing, by
relying on it 100% and giving the user no override.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
10:43 a.m.
On Sun, 26.04.09 12:17, David Woodhouse (dwmw2(a)infradead.org) wrote:
On Fri, 2009-04-24 at 18:58 +0200, Lennart Poettering wrote:
>
> > I know you mean well by trying to simplify this entire mess (I hated the
> > old Volume Control, it was too much), but on the other hand this seems
> > to be a messy problem and taking too much control from the user is a
> > mistake. At least that's what my intuition is telling me, FWIW.
>
> If we don' try to fix it then this will never be fixed.
I agree -- it is a wonderful thing that we're trying to fix this, and I
applaud your efforts.
But we have to acknowledge that we cannot always get it 100% right, and
that we _do_ need to let the user have ultimate control.
Everyone who wants the full use of the mixer still can have it. The
question is whether it needs to be installed by default or not. Not
installing a mixer like that by default won't take any control or any
freedom away of the user.
You apparently want to make this a question of control and
freedom. It however is just a question of cluttering the default
install with stuff only a minority of folks need.
What's next? Will you be asking that postgresql is installed by
default on Fedora because some users could need it and it takes away
control from them if it's not installed by default?
Even ignoring the 'esoteric' use cases, I don't think
we're ever going
to see an end to bugs like #493790 or the last part of #497698.
It's all very well saying that the ALSA hardware database should know
everything -- but it _doesn't_, and realistically speaking it never
will.
It doesn't need to know *everything*. It just needs needs tweaks for
a few sound cards. It needs those tweaks on the kernel-side of the
story all the time, have you seen the amount of card-specific patches
that go into the HDA driver every week? For a few cards not just the
kernel drivers need to be tweaked from time to time but also the user
space db. The user space db is maintained by exactly the same folks
who also maintain the kernel drivers. And hence the chance is actually
not that bad that the db will be updated at the same time as the
kernel drivers if necessary
The db is still a pretty new feature. That's why it still misses the
userspce quirks for a lot of older sound cards.
It doesn't even know about the 'Front' control on my
MacBook Pro -- so
if I didn't have gnome-alsamixer, the F-11 installation would just be
inexplicably quieter than F-10 was.
The ALSA mixer interface is quite broken when it comes to surround
sound. Due to that a few controls have been slit up into seperate
Front/Rear/LFE/Center controls although should actually just be
one. That's a drity workaround in ALSA right now because everyone is
afraid of unfucking the mixer api.
But you seem to be missing the point that there will _always_ be bugs
in
the database, and it's _your_ code which has suddenly promoted that
database from being a 'convenience' to a 'mission critical' thing, by
relying on it 100% and giving the user no override.
Yes, there will always be missing entries in the DB. The same way as
there always will be missing quirks in the kernel driver. That's
something we need to accept. But there is no need to conclude from
that that it is necessary to expose the full alsa mixer all the
time -- the same way it is not necessary to install gcc, patch, git
and the kernel sources just because the kernel drivers might need
quirks, too.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
11:25 a.m.
On Sun, 2009-04-26 at 17:43 +0200, Lennart Poettering wrote:
Yes, there will always be missing entries in the DB. The same way as
there always will be missing quirks in the kernel driver. That's
something we need to accept. But there is no need to conclude from
that that it is necessary to expose the full alsa mixer all the
time --
Absolutely. I don't think anyone would suggest that we want to expose
the full alsa mixer all the time. That would be horrid. Did anyone
suggest that?
the same way it is not necessary to install gcc, patch, git
and the kernel sources just because the kernel drivers might need
quirks, too.
I think that's a good analogy. We don't just declare use cases to be
uninteresting and refuse to support them in the kernel -- we add quirks,
so the user can make things work properly. The user retains full
control.
We should be allowing the user to retain full control of the mixer too
-- they definitely shouldn't need to use it in the _default_ case, but
there should be _some_ way for them to fix things when we don't get it
right. Preferably in such a way that we can learn from what they've
done, improve our database and get it right for similar machines in the
future.
I don't think we achieve that by throwing our toys out of the pram and
refusing to contemplate the notion of letting the user fix things
through the panel applet or the tool they can launch from it.
It sucks that we're forcing the user to go through the application menus
to find an alternative, when there ought to be some kind of quirk or
"stuff isn't working right!" button or menu or something in the place
the user will actually be _looking_.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
11:36 a.m.
On Sun, 26.04.09 17:25, David Woodhouse (dwmw2(a)infradead.org) wrote:
> the same way it is not necessary to install gcc, patch, git
> and the kernel sources just because the kernel drivers might need
> quirks, too.
I think that's a good analogy. We don't just declare use cases to be
uninteresting and refuse to support them in the kernel -- we add quirks,
so the user can make things work properly. The user retains full
control.
We should be allowing the user to retain full control of the mixer too
-- they definitely shouldn't need to use it in the _default_ case, but
there should be _some_ way for them to fix things when we don't get it
right. Preferably in such a way that we can learn from what they've
done, improve our database and get it right for similar machines in the
future.
Ah, now you admit that the low-level alsa mixer is not necessary for
the default case. So why do you want to push it into the default
install then?
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
12:04 p.m.
On Sun, 2009-04-26 at 18:36 +0200, Lennart Poettering wrote:
Ah, now you admit that the low-level alsa mixer is not necessary for
the default case. So why do you want to push it into the default
install then?
I said it _shouldn't_ be. We're still a long way even from that state.
As I said: on the two machines I've tried so far, I haven't even been
able to turn the volume up to its full level without having to resort to
gnome-alsamixer.
I believe that the VolumeControl 'feature' for F-11 isn't ready for
prime time yet, and should be reverted. We can try again in F-12.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
12:48 p.m.
On Sun, Apr 26, 2009 at 12:25 PM, David Woodhouse wrote:
On Sun, 2009-04-26 at 17:43 +0200, Lennart Poettering wrote:
> Yes, there will always be missing entries in the DB. The same way as
> there always will be missing quirks in the kernel driver. That's
> something we need to accept. But there is no need to conclude from
> that that it is necessary to expose the full alsa mixer all the
> time --
Absolutely. I don't think anyone would suggest that we want to expose
the full alsa mixer all the time. That would be horrid. Did anyone
suggest that?
I did. But that was before I noticed that there are people who don't
want to have full control on their sound hardware, and this still
sounds weird to me.
Maybe that's because I'm an audio oriented "minority". Who knows...
Orcan
3:11 p.m.
On 04/26/2009 08:48 PM, Orcan Ogetbil wrote:
On Sun, Apr 26, 2009 at 12:25 PM, David Woodhouse wrote:
> On Sun, 2009-04-26 at 17:43 +0200, Lennart Poettering wrote:
>
>> Yes, there will always be missing entries in the DB. The same way as
>> there always will be missing quirks in the kernel driver. That's
>> something we need to accept. But there is no need to conclude from
>> that that it is necessary to expose the full alsa mixer all the
>> time --
>>
> Absolutely. I don't think anyone would suggest that we want to expose
> the full alsa mixer all the time. That would be horrid. Did anyone
> suggest that?
>
>
I did. But that was before I noticed that there are people who don't
want to have full control on their sound hardware, and this still
sounds weird to me.
Maybe that's because I'm an audio oriented "minority". Who knows...
I am not audio oriented, I am just a regular user who wants to be able
to see youtube clips, listen to some classic music, use VoIP and maybe
see a movie once in a while. And no, I could not do that using only the
_defaults_ from F10. I had to spend 2 days reading docs from the PA's
website, install half a dozen pav* and pa* packages and plugins, notice
that none of them is useful and finally switch to alsamixer in order to
be able to increase the level of the front mic (and just as in Will's
case, I alsoneeded to really raise the global output level to a value
which made the sound loud enough; for the first days I almost believed
that my shiny new MB is broken because with the output maxed out via
pavucontrol, it was barely audible. only after using alsamixer did I
notice that there existed yet another knob which - surprise surprise -
solved the issue)
1:47 p.m.
Callum Lerwick wrote:
And why do Pidgin alert sounds explode my speakers now? Yeah pump
the
hardware volume up to 100%, that's great... Why does Pidgin still not
have native Pulseaudio support? I set it to use paplay because in the
past Pidgin would leak PA connections and RAM like crazy and choke the
machine dead any other way. This "flat volume" thing now seems to mean
short alert tones will cause obnoxious volume glitching if they happen
to be louder than my music.
Flat volumes can be disabled in /etc/pulse/daemon.conf or
~/.pulse/daemon.conf with the following line:
flat-volumes = no
Kevin Kofler
1:34 p.m.
Bastien Nocera wrote:
You had about a year to complain that the Volume Control feature
didn't
include your use case, and given the 0.01% of the population using their
sound system like you do, I doubt it would have crossed our minds that
this could have been the case.
People did complain, they got told (by you and others) that it is an
intentional design feature not to show the options they need.
Kevin Kofler
3:08 p.m.
On Wed, 2009-04-22 at 20:34 +0200, Kevin Kofler wrote:
Bastien Nocera wrote:
> You had about a year to complain that the Volume Control feature didn't
> include your use case, and given the 0.01% of the population using their
> sound system like you do, I doubt it would have crossed our minds that
> this could have been the case.
People did complain, they got told (by you and others) that it is an
intentional design feature not to show the options they need.
Complaining after a feature freeze isn't going to help us get the
software in the release just coming up.
What we don't want to do is do a botched job at supporting work-arounds,
instead of fixing the original use cases.
I'm not interested in adding a button to do this or that using ALSA. So,
no, we won't be adding a way to change the input settings via ALSA to
the gnome-volume-control UI. And we'll be fixing this properly for F12.
If you have specific use-cases that aren't covered by the current
software, file a bug upstream.
2:44 p.m.
On Wed, 2009-04-22 at 20:27 +0200, Kevin Kofler wrote:
Callum Lerwick wrote:
> How do I get this behavior back?
Use xfce4-mixer or KMix (the latter is part of kdemultimedia). Or the
text-based alsamixer.
When I need a full mixer, alsamixer is what I use. What I'm missing is
the panel applet. I used to be able to just place my mouse over the icon
and use the scroll wheel. I'm just noticing the shiny new mixer app
doesn't seem to support that either...
Sigh.
When stumbling upon a youtube with crappy distorted overdriven audio, I
need to get the volume down FAST. If it weren't for the speaker sharing
setup I'd just use the nice low-latency hardware volume knob on my
speakers, where I don't have to wait for the software volume app to swap
in before the volume changes...
3:51 p.m.
Callum Lerwick wrote:
When I need a full mixer, alsamixer is what I use. What I'm
missing is
the panel applet. I used to be able to just place my mouse over the icon
and use the scroll wheel. I'm just noticing the shiny new mixer app
doesn't seem to support that either...
KMix supports that fine, and as it's a systray applet it should also work in
GNOME. kdemultimedia does have a lot of dependencies though.
I haven't tried the XFCE mixer, maybe that one does what you want? It'll
have fewer dependencies.
Kevin Kofler
5476
days inactive
5482
days old
134 comments
29 participants
participants (29)
-
Adam Williamson -
Andreas Thienemann -
Andy Burns -
Bastien Nocera -
Bill Crawford -
Bruno Wolff III -
Callum Lerwick -
Dave Jones -
David Woodhouse -
Dimi Paun -
Fernando Lopez-Lezcano -
Jerry James -
Jesse Keating -
Joonas Sarajärvi -
Kevin Kofler -
Lennart Poettering -
Manuel Wolfshant -
Matej Cepl -
Mathieu Bridon -
Matthew Garrett -
Matthias Clasen -
Neal Gompa -
Nikolay Vladimirov -
Orcan Ogetbil -
Rahul Sundaram -
Stephen Warren -
Suren Karapetyan -
TK009 -
Will Woods