On Tue, 2011-08-23 at 13:16 +0100, Colin Guthrie wrote: > 'Twas brillig, and Jesse Sheidlower at 23/08/11 10:42 did gyre and gimble: > > > > Hi. I'm sorry to ask a relatively basic question on what seems like a > > pretty high-powered dev list, but I'm having trouble finding the answer > > elsewhere. > > > > I'm using PulseAudio on Debian under Xfce. I want to bind keys to > > commands that raise and lower the volume (typically multimedia keys, > > though my current keyboard doesn't actually have these). That's it. > > There are a few discussions about how to do this online, including > > > > https://bbs.archlinux.org/viewtopic.php?id=46608&p=2 > > and > > http://crunchbanglinux.org/forums/topic/11392/pulseaudio-volume-control-with-media-keys/ > > > > The problem is, these commands only control one sink. I have two USB > > audio controllers and the internal sound card (and a virtual device to > > play everything together), and would like to be able to control whatever > > happens to be playing at any time. (Typically I have a music player > > going through a USB controller, and the rest of my system going through > > the internal card; I'm not usually listening to both simultaneously, but > > this is possible.) So maybe this is more of a question about shell > > coding, but either way, I'd think that it's something that would be of > > interest to many Pulse users. > > To solve this properly there needs to be some kind of semi-automatic > intelligence built in to whatever processes the keys. e.g. under Gnome > that would be gnome-settings-daemon, under KDE it's kmix etc. > > Really lots of things come into the equation. If you are playing a > movie, then maybe it's the top most window's sound you want to control. > If you are playing music then generally the app is not in the > foreground, so that logic fails etc. I wouldn't like per-stream changes. Maybe someone would, but I would oppose making this the default. > But some kind of virtual device for volume control could be useful. e.g. > a special API that changed the "most appropriate" volume, perhaps based > on the logic of: > > 1. Are any devices playing sound? If so, pick it. If multiple, use > $algorithm to pick the right one. > 2. If nothing is playing, use the default device. I think this logic would be a big improvement to the status quo. $algorithm = "adjust all active devices by the same percentage" (or maybe by the same dB amount, I don't know which would be better) > Now, this only applies when dealing with your keyboard or laptop volume > keys. When dealing with the keys from e.g. a USB or Bluetooth headset, > then the volume should control the device it's attached to, not follow a > generic algorithm. > > So as you can see things are much more involved than they may at first > seem. When dealing with policy like this it's really something you want > to build into PA, not just script from the command line. > > So really a proper proposal on how to intelligently pick which device to > control and somehow make this policy somewhat configurable (as you'll > certainly get people complaining that it doesn't fit their need) is > probably needed. My proposal: module-main-volume-by-active-device. There could be more module-main-volume-* variants in the future (all implementing the same client interface), but I'd start with the version that implements the logic that you described. -- Tanu
