[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora 11 nerfed my mixer

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);
-                e = pa_alsa_find_elem(m, "Master", "PCM", TRUE);
+                e = pa_alsa_find_elem(m, "PCM", "Master", TRUE);

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


> 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.

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]