Newbie: controlling volume through command line

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux