PA by default

Bastien Nocera bnocera at redhat.com
Mon Aug 20 20:37:25 UTC 2007


On Mon, 2007-08-20 at 22:10 +0200, Lennart Poettering wrote:
> On Thu, 16.08.07 22:53, Bastien Nocera (bnocera at redhat.com) wrote:
> 
> > Heya,
> > 
> > Before Fedora 8, is there a plan to fix a few regressions or integration
> > issue with PA?
> > 
> > From:
> > https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01196.html
> > 
> > > You also have to make sure that some GConf keys are set up properly:
> > > 
> > >   /system/gstreamer/0.10/default/audiosrc -> pulsesrc
> > >   /system/gstreamer/0.10/default/audiosink -> pulsesink (or autoaudiosink)
> > >   /system/gstreamer/0.10/default/chataudiosink -> pulsesink (or autoaudiosink)
> > >   /system/gstreamer/0.10/default/musicaudiosink -> pulsesink (or autoaudiosink)
> > 
> > This means that the "Devices" part of the Sound Preferences in GNOME is
> > pretty useless. I guess there's a PA specific way of changing the
> > default input and output, but you lose integration with the desktop.
> 
> Hmm, this capplet somhow vanished completely on my Fedora
> system. Anyone knows where I can find it?
> 
> GStreamer supports all kinds of interfaces to enumerate sound
> devices. gst-pulse supports those. Hence the dialog should work, but I
> cannot really say since I haven't testes this. (see above) qThe
> gnome-volume-control device selection does work the last time I
> looked. 

gstreamer-sound-properties. It's the "Sound" preference.

BTW, do you want me to change the default sinks in
gstreamer-plugins-good? If so, could you file a bug so I don't forget :)

> > This will also probably break the device selection that the volume
> > applet uses (it uses the same as the default sound events device,
> > iirc).
> 
> Presumable the applet uses the same interfaces as gnome-volume-control
> and thus should work. A quick check seems to prove that.

Good.

> > I'm also thinking of applications' volume setup. At least Totem and
> > Rhythmbox have the concept of "system volume" (which is per device, and
> > they don't touch), and the "application volume" (which they do). Here,
> > we're adding the "PA volume".
> 
> The "application volume" and the "PA volume" should be "merged". (see
> below)

Sounds good, but that would mean different code.

> > How do we plan on handling that?
> 
> Volume control is a very difficult topic. It had a couple of
> discussions with a couple of people how we should expose this
> best. (Takashi, Kay, thanks!) One has to consider that usually people
> don't expect that there is a whole series of volume controls one after
> the other: software volume control in rhythmbox, then a software
> volume control in PA, the hardware volume control of the WAVE control
> in ALSA, then the MASTER control in ALSA and finally (if you have a
> thinkpad at least like I do) another hw amplifier. That's five
> controls in a row. (let alone the external controls of your active
> loudspeakers or your hifi system, which we will ignore here for
> now). FIVE! That's about three and a half too many, I would say. And
> these are five that you might accidentaly have set to -Inf dB, and
> which might be the reason why your sound doesn't work.

Nod. You thought of many more volume controls than I did, and 3's
already too many for me :)

> If you look how Apple does volume control in MacOSX (Apple usually
> does these things right, so it's where we should belook), they have
> exactly two. One per-app in sw and a one global in hw. Some people
> might still find this confusing, i.e. one too many, but on the other
> hand per-app volume control is deadly sexy.

It's very useful to have both though.

> So, what I would like to see implemented is this: ALSA hides away
> unncessary volume controls and initializes them to sane defaults
> (i.e. "0 dB"), and makes sure there is always a "Master" volume
> control which is the actual control for the amplification in HW. This
> is what Takashi has started to work on. PA already exposes this single
> per-device volume control, and ignores all the rest the hw might
> expose. That's volume control #1, the per-device hw-based one. 
> 
> For volume #2, the per-stream sw-based one: the PA per-stream volume
> and the volume adjustment done in GST should be "merged". PA has all
> the necessary APIs but Gstreamer needs some non-trivial changes for
> this. Right now GST's mixer control is awful and designed with
> per-device controls in mind and hardware backends. Hence I am unable
> to expose the PA per-stream volume properly in gst-pulse.

Right now, Totem and Rhythmbox have their own software-volume in the
pipelines. Handling the "hardware" mixer that PA shows means that Totem
and Rhythmbox would need to special-case PA.

> I brought this up to some GST people a while back, but I guess
> everyone was just too busy and PA was not yet installed by default on
> Fedora and hence not important enough. 
> 
> Ideally, Rhythmbox should only show the per-stream volume control. If
> you right click on it a popup menu should open to replace the widget
> by the hw per-device volume control. Another option of that popup
> should be to start the volume control tool.
> 
> Right now we are in the very unfortunate situation to have two volume
> control tools. One being "pavucontrol" which uses PA and exposes a lot
> of fun functionality but looks ... shitty -- because I wrote it. And
> the other one being gnome-volume-control which looks much better but
> exposes all those unnecessary mixer tracks and doesn't know anything
> about per-stream volumes. This situation needs some real fixing. I am
> hoping that eventually someone eventually will pick up this mess and
> try to find a good solution. (i.e. maybe beef up the gst volume
> control stuff to new levels, or give my PA UI tools some serious love)
> Anyone?

Huh. I'm not volunteering yet :)




More information about the Fedora-desktop-list mailing list