Re: [pulseaudio-discuss] module-device-restore: Volume save and restore for all ports?

2010-01-04 Thread Tanu Kaskinen
ma, 2010-01-04 kello 23:10 +0100, Lennart Poettering kirjoitti:
 On Fri, 01.01.10 05:52, Tanu Kaskinen (ta...@iki.fi) wrote:
  - Track port volume and mute individually. That is, whenever the active
  port is switched, the previous port's volume and mute state should be
  saved to a database and the new port's volume and mute state should be
  loaded from the database.
 
 Makes sense.
 
 An easy fix could be to reuse the current m-d-r database but always
 store two entries each time we want to save the device settings: one
 for $SINKNAME and one for $sinkn...@$portname or suchlike. And when
 reading from the database we'd first look for $sinkn...@$portname in
 the db and fall back to $SINKNAME if we dont find that.

Sounds good.

  - Don't treat the options as separate ports, but create a new concept
  for them: port options.
 
 Hmm, should those really be _port_ options? Not _device_ options?

At least the state should be saved per-port. That is, if I select an
option for some port, I possibly (and even probably) don't want to have
the option selected in all the other ports also. When writing the alsa
mixer config files, it may make sense to configure options in the
Mapping section, but even then I suspect that there are sound cards with
options that are not relevant with all ports, so I think we have two
acceptable design options: make the options configurable A) in the path
config only or B) both in the path and the mapping config.

  - Port options are things that you can switch on and off, or choose from
  an enumeration.
 
 This dangerously sounds like the complex ALSA mixer which I'd rather
 avoid. Before we approach this, could we get a more complete list of
 options that would be covered with this, in addition to the amplifier
 settings?

I'm not aware of any other sensible options that exist on real hardware.
I mentioned selectable EQ settings earlier, but I've not personally seen
or heard about any sound card actually having such options.

If you can't come up with other options either, maybe it's not worth the
effort to implement the port options just for the amplification switch
(UIs would have to be updated too). I still think that the concept makes
perfect sense, though.

  Lennart, any comments? Would you accept a patch that made these changes?
 
 Yes, but let's discuss this more first ;-)

Here's something more to discuss: saving stream volumes per physical
output (per sink and per port, that is). I'll make a separate thread.

-- 
Tanu Kaskinen

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] module-device-restore: Volume save and restore for all ports?

2010-01-02 Thread Tanu Kaskinen
la, 2010-01-02 kello 14:40 +, Colin Guthrie kirjoitti:
 'Twas brillig, and Tanu Kaskinen at 01/01/10 03:52 did gyre and gimble:
  Hi Colin,
  
  I got a bit confused about the term port in your mail. Apparently you
  used it to mean something else than pulseaudio's own device port
  concept. In this message I will use the word port only for the
  pulseaudio concept.
 
 It's certainly what I meant by port... /me worries that it wasn't clear.
 
  ke, 2009-12-30 kello 13:26 +, Colin Guthrie kirjoitti:
  As jack sensing will eventually be with us, it would make sense to save
  and restore the volume of all ports separately. Only saving the current
  port's volume would be a pain.
  
  I agree, although I don't really see how jack sensing is important here.
  AFAIK ports are currently only implemented by the alsa modules, and in
  that case separate ports are created for two different purposes:
  selecting the physical output or input, and selecting any options that
  the alsa mixer offers (for example, extra amplification switch).
  Regardless of jack sensing, volume should be saved and restored
  independently for each output/input.
 
 Well the reason I see jack sensing as important here is that the say the
 user is using the Speaker port and sets the volume to 99%. This volume
 is saved. Then later, they have headphones plugged in when PA starts and
 the port is automatically set to Headphones. In this case the volume
 could be restored to the 99% that was appropriate for Speaker but
 totally incorrect for Headphones and turn your brain into a mushy goo :p

Ok, I think I see. So the difference is that when switching to
Headphones, without jack sensing the user has the possibility
pre-emptively decrease the volume after plugging the headphones in. With
jack sensing the decreasing has to be done before plugging the
headphones in. That might not be a very big difference - I think mushy
goo is the probable outcome in both cases :)

  Now the second purpose of ports causes problems: the volume shouldn't be
  saved independently for the two cases of whether the extra amplification
  is on or off.
 
 Why not? With amplification you'd presumably set the volume lower... is
 it a massive problem that we would save those two volumes separately?

The option could be anything - the sound card might have selectable
equalization presets, for example... But no, I don't believe this would
be a massive problem in practice. Certainly just storing the volume
individually for each port would be a good start. But I still think that
the port option concept makes sense.

  I may have not thought this completely through, but nevertheless I
  propose the following:
  
  - Track port volume and mute individually. That is, whenever the active
  port is switched, the previous port's volume and mute state should be
  saved to a database and the new port's volume and mute state should be
  loaded from the database.
 
 Ahh, I thought about that (didn't say it in the original mail) but there
 is a problem here. It's maybe too niche, but if we only save it on port
 switch then a volume change to Headphones levels via alsa mixers will
 not be saved. This will affect users who currently are able to take
 advantage of hardware jacksensing. e.g. The user I spoke to didn't
 actually change the PA port when he plugged his headphones in (it's too
 much hassle which I can sympathise with). When he does this, the general
 volume control infrastructure doesn't work (as expected) and changing
 volume doesn't actually affect the volume of the headphones.
 
 So if we could detect and save the volume when it's changes, then the
 restoration would help this use case.
 
 Of course if we could just get jack sensing working it would bypass the
 need for this, so it's likely a better focus.

Well, I fully agree that it does make sense to store the volume whenever
it changes (except for automatic changes by the flat volume logic) -
just like it's done now.

Regarding the use case you mentioned - it would require some
modifications to the logic that handles mixer change events that are
caused eg. by fiddling with alsamixer. Currently whenever something
happens, the sink receives a generic callback that basically says
something happened and then the sink just updates the current volume
and mute state, using the currently active port. This use case would
require that each port would store the current volume and mute of the
relevant mixer elements, and the mixer change events would be handled by
the ports instead of (or in addition to) the sinks. Device-restore would
need to listen to port state change events, which do not currently
exist.

As you say, the need for this will probably evaporate with jack sensing
support. It's still useful to think whether using alsamixer (or
something like it) should be supported as well as possible - it would be
nice if moving the Headphones slider would affect the device-restore
database even when the headphones aren't 

Re: [pulseaudio-discuss] module-device-restore: Volume save and restore for all ports?

2009-12-31 Thread Tanu Kaskinen
Hi Colin,

I got a bit confused about the term port in your mail. Apparently you
used it to mean something else than pulseaudio's own device port
concept. In this message I will use the word port only for the
pulseaudio concept.

ke, 2009-12-30 kello 13:26 +, Colin Guthrie kirjoitti:
 As jack sensing will eventually be with us, it would make sense to save
 and restore the volume of all ports separately. Only saving the current
 port's volume would be a pain.

I agree, although I don't really see how jack sensing is important here.
AFAIK ports are currently only implemented by the alsa modules, and in
that case separate ports are created for two different purposes:
selecting the physical output or input, and selecting any options that
the alsa mixer offers (for example, extra amplification switch).
Regardless of jack sensing, volume should be saved and restored
independently for each output/input.

Now the second purpose of ports causes problems: the volume shouldn't be
saved independently for the two cases of whether the extra amplification
is on or off.

I may have not thought this completely through, but nevertheless I
propose the following:

- Track port volume and mute individually. That is, whenever the active
port is switched, the previous port's volume and mute state should be
saved to a database and the new port's volume and mute state should be
loaded from the database.
- Don't treat the options as separate ports, but create a new concept
for them: port options.
- Thereby a port equals a physical route (port might be renamed to
route, although I think port is a good enough name for the concept).
- Port options are things that you can switch on and off, or choose from
an enumeration.
- Obviously port options are specific to ports. module-device-restore
tracks the option states along with port volume and mute.

Lennart, any comments? Would you accept a patch that made these changes?
I'm not saying that I would definitely write the patch, but it's not
impossible either.

-- 
Tanu Kaskinen

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


[pulseaudio-discuss] module-device-restore: Volume save and restore for all ports?

2009-12-30 Thread Colin Guthrie
Hi,

I was chatting with Baughn on IRC last night and he mentioned something
that made me think about a deficiency in module-device-restore.

As jack sensing will eventually be with us, it would make sense to save
and restore the volume of all ports separately. Only saving the current
port's volume would be a pain.

At present, the jack sensing does not work too well, but some h/w (incl.
Baughn's) has internal jack sensing and thus when he plugs in his
headphones he adjusts the speaker volume (in a raw alsa mixer -
although the same problem would be present if he switched ports,
adjusted volume and then switched back).


After rebooting, his Speaker volume is not restored (unsurprisingly) as
module-device-restore will only save the volume for a single (i.e. the
active) port, not all ports.

When jack sensing comes in, I presume we would want to save the volume
of the speaker port separately from the volume of the amplifier port.
(is this a valid assumption?)

In which case, would it make sense to make module-device-restore
automatically save the volume of each port on shutdown and restore them
all on startup? This approach would mean that even if we use a raw alsa
mixer to adjust the speaker slider, the value would be saved when PA exists.

Does this seem valid or is there another approach here that should be used?

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss