After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 473841 - [playbin] use mixer interface when setting volume
[playbin] use mixer interface when setting volume
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 486667 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-09-05 08:35 UTC by Tommi Myöhänen
Modified: 2008-10-06 16:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Mixer interface patch for playbin (2.76 KB, patch)
2007-09-05 08:37 UTC, Tommi Myöhänen
rejected Details | Review

Description Tommi Myöhänen 2007-09-05 08:35:54 UTC
Currently playbin sets volume directly to volume element's volume property. Alternative method could be to check if playbin contains an element with mixer interface and use the interface to set volume. This would be useful if pipeline contains other elements than volume element implementing mixer interface and having ability to adjust volume.
Comment 1 Tommi Myöhänen 2007-09-05 08:37:49 UTC
Created attachment 94978 [details] [review]
Mixer interface patch for playbin
Comment 2 Tim-Philipp Müller 2007-09-05 10:18:06 UTC
I believe the current setup is intentional and the desired use case for most desktop applications, as changing the mixer setting (and thus the volume of all applications usually) is regarded to be confusing for the user.

Other use cases could probably be catered for if, but IMHO that should be done by adding additional API instead of changing the behaviour of the current API.


I also see some practical issues with this patch, some of which stem from the awkward GstImplementsInterface API that GstMixer implements:

 - setting the same volume for each track doesn't really seem
   right, but in any case you probably want to skip non-playback
   tracks and also take into account track->min_volume. I am not
   sure if setting the volume on all mixer tracks would be an
   acceptable thing to do even for new API - we'd need a smarter
   solution for that, I think.

 - one would probably need to keep track of changes in the mixer
   volume too, so that get_volume() on playbin returns the actual
   value of the mixer volume control, and not just value last set
   via playbin (which the user might have changed through another
   application since then)

 - keep in mind that whether the mixer interface is implemented
   by an element depends on its state too (the device must be
   open for this); this means if the application tries to change
   the volume while the mixer is in the 'wrong' state, you'll
   modify the setting of the 'volume' element instead, which
   will persist when the sink changes state again later and
   lead to an aggregated volume that's too low, if I'm not
   mistaken.

Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2007-09-12 08:07:29 UTC
Tim, when one uses alsa via dmix, esound or pulseaudio then changing the volume on themixer should only affect the current stream, right. And if one uses alsa directly or oss then affecting the mixer is okay, as there cannot be nother stream at the same time.

This seems to be slightly related to Bug 302798.
Comment 4 Sebastian Dröge (slomo) 2007-09-12 08:14:52 UTC
Many OSS and ALSA drivers allow hardware mixing, i.e. having the device opened more than once at the same time and playing multiple streams. So affecting the mixer for OSS/ALSA has exactly the same problems.
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2007-09-12 08:23:59 UTC
Can it be detected wheter the mixer acts globaly or on the stream?
Comment 6 Sebastian Dröge (slomo) 2007-09-12 08:56:19 UTC
No idea, sorry
Comment 7 Marc-Andre Lureau 2007-09-12 15:02:19 UTC
(In reply to comment #4)
> Many OSS and ALSA drivers allow hardware mixing, i.e. having the device opened
> more than once at the same time and playing multiple streams. 

I thought too, but this is not correct. If it works for you, it's usually, because thanks to dmix.

(In reply to comment #5)
> Can it be detected wheter the mixer acts globaly or on the stream?

I am quite sure it will be possible to ask pulseaudio. 

For hw mixing in pulse, follow:
http://www.pulseaudio.org/ticket/25

(reminder, I still have stuff to say here :)
Comment 8 Sebastian Dröge (slomo) 2007-09-12 20:22:19 UTC
(In reply to comment #7)
> (In reply to comment #4)
> > Many OSS and ALSA drivers allow hardware mixing, i.e. having the device opened
> > more than once at the same time and playing multiple streams. 
> 
> I thought too, but this is not correct. If it works for you, it's usually,
> because thanks to dmix.

Definitely not... that was with my old card in times where dmix didn't even exist... and it worked with the OSS drivers too :)
Comment 9 Bastien Nocera 2008-01-30 13:09:50 UTC
Tim mentions that this could be a (hacky) way of solving the problem.

None of the audio sinks currently implement the mixer interface. If we said that only sinks capable of per-stream volume implement this mixer interface (or flag it with a specific property), then this change would allow applications to use that per-stream volume instead of a volume within the pipeline.
Comment 10 Bastien Nocera 2008-01-30 13:12:40 UTC
The patch is missing property notifications when the mixer volume is changed outside playbin.

This means that changing the per-stream volume in pavucontrol wouldn't change the volume in the application's UI.
Comment 11 Marc-Andre Lureau 2008-01-30 14:15:04 UTC
What about sinks that do not have per-stream volume control? The application should use it's own in this case, right?

With the current design, only PulseAudio will allow remote volume control.

What about manipulating application volume without PulseAudio? I would suggest an interface for that kind of remote control, but I can hear you saying "to a dbus guy, everything is a dbus pb"...:)
Comment 12 Bastien Nocera 2008-01-30 14:23:06 UTC
(In reply to comment #11)
> What about sinks that do not have per-stream volume control? The application
> should use it's own in this case, right?

Yes.

> With the current design, only PulseAudio will allow remote volume control.

Remote control volume? What does that mean?

> What about manipulating application volume without PulseAudio? I would suggest
> an interface for that kind of remote control, but I can hear you saying "to a
> dbus guy, everything is a dbus pb"...:)

That doesn't seem to have anything to do with the problem we're discussing in this bug, and I don't see how changing the volume in applications has anything to do with which mixer playbin would be using.
Comment 13 Wim Taymans 2008-01-30 14:35:24 UTC
I'm thinking about moving the volume control in the baseaudiosink class where it can be changed with a lower latency. Optionally sinks that have other ways of changing the per-stream volume could override and do something else (pulseaudio, ...). 

The end result would be that every audio sink has a volume (interface? property?) that changes the per-stream volume.
Comment 14 Marc-Andre Lureau 2008-01-30 14:42:46 UTC
(In reply to comment #12)
> Remote control volume? What does that mean?

Changing the volume from an external process.
 
> > What about manipulating application volume without PulseAudio? I would suggest
> > an interface for that kind of remote control, but I can hear you saying "to a
> > dbus guy, everything is a dbus pb"...:)
> 
> That doesn't seem to have anything to do with the problem we're discussing in
> this bug, and I don't see how changing the volume in applications has anything
> to do with which mixer playbin would be using.

It's related since pavucontrol will be able to change the volume of pulseaudio sinks. You reviewed the patch making the same kind of comment: it goes one way (from the app/playbin), what about the other way (from pavucontrol/remote)

Comment 15 Bastien Nocera 2008-01-30 15:54:37 UTC
(In reply to comment #14)
> (In reply to comment #12)
> > Remote control volume? What does that mean?
> 
> Changing the volume from an external process.
> 
> > > What about manipulating application volume without PulseAudio? I would suggest
> > > an interface for that kind of remote control, but I can hear you saying "to a
> > > dbus guy, everything is a dbus pb"...:)
> > 
> > That doesn't seem to have anything to do with the problem we're discussing in
> > this bug, and I don't see how changing the volume in applications has anything
> > to do with which mixer playbin would be using.
> 
> It's related since pavucontrol will be able to change the volume of pulseaudio
> sinks. You reviewed the patch making the same kind of comment: it goes one way
> (from the app/playbin), what about the other way (from pavucontrol/remote)

I'm talking about the mixer in playbin noticing the changes done by external programs, just like the volume applet syncs the volume with gnome-volume-control. I've never talked about any D-Bus (or whatever) API to modify the application's volume from another application. This is completely out of topic here.

(In reply to comment #13)
> I'm thinking about moving the volume control in the baseaudiosink class where
> it can be changed with a lower latency. Optionally sinks that have other ways
> of changing the per-stream volume could override and do something else
> (pulseaudio, ...). 
> 
> The end result would be that every audio sink has a volume (interface?
> property?) that changes the per-stream volume.

Sounds like it would fit exactly what we'd need.
Comment 16 Stefan Sauer (gstreamer, gtkdoc dev) 2008-01-31 07:46:25 UTC
Regarding comment #13, whatabout moving bother "volume" and "mute"?
Comment 17 Marc-Andre Lureau 2008-01-31 09:13:59 UTC
(In reply to comment #15)
> I'm talking about the mixer in playbin noticing the changes done by external
> programs, just like the volume applet syncs the volume with
> gnome-volume-control. 

ok, I got it  
Comment 18 Wim Taymans 2008-03-18 18:01:21 UTC
playbin2 can now set the volume property on the sink element (if it's available). Special sinks that have some way to control the volume of this particular stream can implement the property to do the right thing. If there is no sink with the property, playbin2 falls back to using the volume element.
Comment 19 Wim Taymans 2008-03-18 18:14:15 UTC
*** Bug 486667 has been marked as a duplicate of this bug. ***
Comment 20 Stefan Sauer (gstreamer, gtkdoc dev) 2008-04-15 07:44:59 UTC
So if playbin2 can do it dow we still want to do it for playbin? Otherwise should it be closed as WONTFIX?
Comment 21 Wim Taymans 2008-10-06 16:43:20 UTC
Marking as obsolete, implement stream volume in the sinks with a 'volume' property.