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.