On Mon, 2007-08-20 at 22:10 +0200, Lennart Poettering wrote: > On Thu, 16.08.07 22:53, Bastien Nocera (bnocera@xxxxxxxxxx) 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 :) -- Fedora-desktop-list mailing list Fedora-desktop-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-desktop-list
