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.
This will also probably break the device selection that the volume applet uses (it uses the same as the default sound events device, iirc).
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".
How do we plan on handling that?
Cheers
On Thu, 16.08.07 22:53, Bastien Nocera (bnocera@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.
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.
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)
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.
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.
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.
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?
Lennart
On Mon, 2007-08-20 at 22:10 +0200, Lennart Poettering wrote:
On Thu, 16.08.07 22:53, Bastien Nocera (bnocera@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 :)
On Mon, 20.08.07 21:37, Bastien Nocera (bnocera@redhat.com) wrote:
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.
Hmm, is not installed on my machine, only gstreamer-properties which is not what I am looking for. Hmm, Google doesn't even find any mention of "gstreamer-sound-properties".
Hmm, you probably meant gnome-sound-properties. And update of control-center brought it back now. seems to work fine, too.
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 :)
I checked those and they point to "autoaudiosink" by default, which should be enough to get gst-pulse working by default. And is the best choice anyway, to make sure that people who think that PA is devil's work don't get pissed off needlessly. ;-)
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.
What I would like to see is that gst-pulse would expose a new interface on the GstPulseSink element that allows you to modify the per-stream volume control. In a way the current volume control abstraction in gst is already designed to work like that, but it's for per-device controls and totall fucked up anyway.
So, Totem should check wether the output sink implements this new special interface. And if so it should expose it in the UI. If not, it should add the software volume control thing to the pipeline (which ideally would expose the same aforementioned interface) and use that instead.
Looks relatively easy to me, doesn't it? If someone gets this new interface into GST I am happy to add support for it in PA.
Lennart
On Mon, 2007-08-20 at 23:01 +0200, Lennart Poettering wrote:
On Mon, 20.08.07 21:37, Bastien Nocera (bnocera@redhat.com) wrote:
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.
Hmm, is not installed on my machine, only gstreamer-properties which is not what I am looking for. Hmm, Google doesn't even find any mention of "gstreamer-sound-properties".
Hmm, you probably meant gnome-sound-properties. And update of control-center brought it back now. seems to work fine, too.
Yeah, I'm doing too many things at the same time :)
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 :)
I checked those and they point to "autoaudiosink" by default, which should be enough to get gst-pulse working by default. And is the best choice anyway, to make sure that people who think that PA is devil's work don't get pissed off needlessly. ;-)
If that makes it work, then fine with me :)
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.
What I would like to see is that gst-pulse would expose a new interface on the GstPulseSink element that allows you to modify the per-stream volume control. In a way the current volume control abstraction in gst is already designed to work like that, but it's for per-device controls and totall fucked up anyway.
We're mixing 2 different things. There's the per-stream volume, for the GstPulseSink for use in gnome-volume-control, and there's detecting that we have a "stream" volume, for Totem and Rhythmbox.
The former I don't think is very important right now, as long as the latter is implemented.
A simple read-only property would be enough to handle that. Does MacOS X present a similar interface for applications to use, or do they implement volume control by themselves like Totem/Rhythmbox currently do with the volume element?
If there's something like that in MacOS X, it's a matter of agreeing on the name of the property.
On Mon, 20.08.07 22:18, Bastien Nocera (bnocera@redhat.com) wrote:
We're mixing 2 different things. There's the per-stream volume, for the GstPulseSink for use in gnome-volume-control, and there's detecting that we have a "stream" volume, for Totem and Rhythmbox.
The former I don't think is very important right now, as long as the latter is implemented.
A simple read-only property would be enough to handle that.
Hmm, what would this property export? I am not sure I understand what you are suggesting.
Does MacOS X present a similar interface for applications to use, or do they implement volume control by themselves like Totem/Rhythmbox currently do with the volume element?
The only a have a single per-stream volume which is controlled by the slider in iTunes. The per-system volume is controlled globally with the volume hotkeys.
Lennart
desktop@lists.stg.fedoraproject.org
-
Bastien Nocera -
Lennart Poettering